Re: [IPsec] CAFR -01 comments
Hi Yoav, Yaron, Sorry, I disagree. This notification is concerned with both "old" IKE SA (as Child SAs "sponsor") and "new" IKE SA (as "acceptor"). So, to remain in concent with RFC5996 and to be logically consistent, I'd suggest to make SPI field empty (and Protocol ID zero) and to move SPI for "new" IKE SA to Notification Data. No new values for Protocol ID is needed. Regards, Valery. So we can creatively interpret "the IKE SA" to be different from "an IKE SA", or we can ask IANA to add a new value with meaning "other IKE SA". Agree it's a corner case. > Hi Yoav, > > Regarding the notification syntax, it is actually a bit worse than that. > This is a corner case in the RFC, but if you read Sec. 3.10 literally, > there are exactly 2 allowed values for the Protocol ID field (or 3 > values, if you read RFC 4306). > There is no extensibility defined, and no IANA registry either. So a > responder would be correct if it replied with an INVALID_SYNTAX rather > than ignoring your > notification, if it doesn't recognize it. > > And the value you are using (1) comes from RFC 2407 and has never > existed in IKEv2. Ugh. ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] CAFR -01 comments
Ugly but safe. Yaron On 2013-08-25 13:12, Yoav Nir wrote: I guess, but it's still using one notification to announce another notification. On Aug 25, 2013, at 1:08 PM, Yaron Sheffer wrote: And this would imply support for Childless, too? Thanks, Yaron On 2013-08-25 13:01, Yoav Nir wrote: Or do my other favorite thing with a "support_cafr" notification in the Initial exchange, so that support indicates that you understand protocol=1 and SPI size=16. If we ever do an IKEv3, we need a "Features" payload, where optional capabilities be listed in compact form. That and replacing "Next Payload" with "This Payload" Yoav ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] CAFR -01 comments
I guess, but it's still using one notification to announce another notification. On Aug 25, 2013, at 1:08 PM, Yaron Sheffer wrote: > And this would imply support for Childless, too? > > Thanks, > Yaron > > On 2013-08-25 13:01, Yoav Nir wrote: >> Or do my other favorite thing with a "support_cafr" notification in the >> Initial exchange, so that support indicates that you understand protocol=1 >> and SPI size=16. >> >> If we ever do an IKEv3, we need a "Features" payload, where optional >> capabilities be listed in compact form. That and replacing "Next Payload" >> with "This Payload" >> >> Yoav >> >> On Aug 25, 2013, at 12:07 PM, Yaron Sheffer wrote: >> >>> Thanks for pointing me to the registry! >>> >>> I'm not worried about creative interpretations. More about existing >>> implementations doing the wrong thing. So yes, maybe we should register a >>> new value. >>> >>> Thanks, >>> Yaron >>> >>> On 2013-08-25 11:47, Yoav Nir wrote: I read section 3.10 in RFC 4306, and it says this: o Protocol ID (1 octet) - If this notification concerns an existing SA, this field indicates the type of that SA. For IKE_SA notifications, this field MUST be one (1). For notifications concerning IPsec SAs this field MUST contain either (2) to indicate AH or (3) to indicate ESP. For notifications that do not relate to an existing SA, this field MUST be sent as zero and MUST be ignored on receipt. All other values for this field are reserved to IANA for future assignment. o SPI Size (1 octet) - Length in octets of the SPI as defined by the IPsec protocol ID or zero if no SPI is applicable. For a notification concerning the IKE SA, the SPI Size MUST be zero and the field must be empty. Sure there is a registry: http://www.iana.org/assignments/ikev2-parameters/ikev2-parameters.xhtml#ikev2-parameters-18 . There are even values #4 and #5. But I see that bit about SPI size having to be zero, because it is assumed that notification about IKE SA only relate to *this* IKE SA. So we can creatively interpret "the IKE SA" to be different from "an IKE SA", or we can ask IANA to add a new value with meaning "other IKE SA". Agree it's a corner case. -Original Message- From: Yaron Sheffer [mailto:yaronf.i...@gmail.com] Sent: Sunday, August 25, 2013 11:12 AM To: Yoav Nir Cc: IPsecme WG Subject: Re: [IPsec] CAFR -01 comments Hi Yoav, Regarding the notification syntax, it is actually a bit worse than that. This is a corner case in the RFC, but if you read Sec. 3.10 literally, there are exactly 2 allowed values for the Protocol ID field (or 3 values, if you read RFC 4306). There is no extensibility defined, and no IANA registry either. So a responder would be correct if it replied with an INVALID_SYNTAX rather than ignoring your notification, if it doesn't recognize it. And the value you are using (1) comes from RFC 2407 and has never existed in IKEv2. Ugh. Thanks, Yaron On 2013-08-25 10:53, Yoav Nir wrote: > > On Aug 25, 2013, at 9:45 AM, Yaron Sheffer wrote: > >> Hi Yoav, >> >> I started by reading -01, then went back to -00. And I think the two can >> be merged to create a better solution. >> >> Including the notification as soon as the peers know they want a >> handover is cleaner. So IKE_AUTH (of the new SA) is better than DELETE, >> and in fact IKE_SA_INIT would be even more useful because then you can >> define that all such IKE SAs are implicitly childless, and avoid the >> need for the RFC 6023 notification. >> >> CAFR -01 says a peer is allowed to hand over the Child SAs if it >> successfully authenticates to the other peer and has the same >> authenticated identity. Seems to me this is symmetric, i.e. it doesn't >> matter if the exchange is run over the "old" or the "new" IKE SA. And so >> this could apply just as well to -00, and the POP stuff is not needed. >> >> I'm not sure about the race discussion in -00, because it only applies >> in failure cases. Can't an attacker "swallow" a few DELETE messages or >> their responses and cause a similar database mismatch? > > I hope they can't. Informationals with DELETEs are just like any other > IKEv2 exchange. If at active attacker swallows DELETEs or their > responses, eventually at least one side loses the IKE SA. > > But with regular initial IKE, there is an asymmetry. The Responder > verifies the IKE_AUTH request, generates the Response, sends it, and > believes that everything is just fine. Then the Initiator gets the > IKE_AUTH response, and decides that
Re: [IPsec] CAFR -01 comments
And this would imply support for Childless, too? Thanks, Yaron On 2013-08-25 13:01, Yoav Nir wrote: Or do my other favorite thing with a "support_cafr" notification in the Initial exchange, so that support indicates that you understand protocol=1 and SPI size=16. If we ever do an IKEv3, we need a "Features" payload, where optional capabilities be listed in compact form. That and replacing "Next Payload" with "This Payload" Yoav On Aug 25, 2013, at 12:07 PM, Yaron Sheffer wrote: Thanks for pointing me to the registry! I'm not worried about creative interpretations. More about existing implementations doing the wrong thing. So yes, maybe we should register a new value. Thanks, Yaron On 2013-08-25 11:47, Yoav Nir wrote: I read section 3.10 in RFC 4306, and it says this: o Protocol ID (1 octet) - If this notification concerns an existing SA, this field indicates the type of that SA. For IKE_SA notifications, this field MUST be one (1). For notifications concerning IPsec SAs this field MUST contain either (2) to indicate AH or (3) to indicate ESP. For notifications that do not relate to an existing SA, this field MUST be sent as zero and MUST be ignored on receipt. All other values for this field are reserved to IANA for future assignment. o SPI Size (1 octet) - Length in octets of the SPI as defined by the IPsec protocol ID or zero if no SPI is applicable. For a notification concerning the IKE SA, the SPI Size MUST be zero and the field must be empty. Sure there is a registry: http://www.iana.org/assignments/ikev2-parameters/ikev2-parameters.xhtml#ikev2-parameters-18 . There are even values #4 and #5. But I see that bit about SPI size having to be zero, because it is assumed that notification about IKE SA only relate to *this* IKE SA. So we can creatively interpret "the IKE SA" to be different from "an IKE SA", or we can ask IANA to add a new value with meaning "other IKE SA". Agree it's a corner case. -Original Message- From: Yaron Sheffer [mailto:yaronf.i...@gmail.com] Sent: Sunday, August 25, 2013 11:12 AM To: Yoav Nir Cc: IPsecme WG Subject: Re: [IPsec] CAFR -01 comments Hi Yoav, Regarding the notification syntax, it is actually a bit worse than that. This is a corner case in the RFC, but if you read Sec. 3.10 literally, there are exactly 2 allowed values for the Protocol ID field (or 3 values, if you read RFC 4306). There is no extensibility defined, and no IANA registry either. So a responder would be correct if it replied with an INVALID_SYNTAX rather than ignoring your notification, if it doesn't recognize it. And the value you are using (1) comes from RFC 2407 and has never existed in IKEv2. Ugh. Thanks, Yaron On 2013-08-25 10:53, Yoav Nir wrote: On Aug 25, 2013, at 9:45 AM, Yaron Sheffer wrote: Hi Yoav, I started by reading -01, then went back to -00. And I think the two can be merged to create a better solution. Including the notification as soon as the peers know they want a handover is cleaner. So IKE_AUTH (of the new SA) is better than DELETE, and in fact IKE_SA_INIT would be even more useful because then you can define that all such IKE SAs are implicitly childless, and avoid the need for the RFC 6023 notification. CAFR -01 says a peer is allowed to hand over the Child SAs if it successfully authenticates to the other peer and has the same authenticated identity. Seems to me this is symmetric, i.e. it doesn't matter if the exchange is run over the "old" or the "new" IKE SA. And so this could apply just as well to -00, and the POP stuff is not needed. I'm not sure about the race discussion in -00, because it only applies in failure cases. Can't an attacker "swallow" a few DELETE messages or their responses and cause a similar database mismatch? I hope they can't. Informationals with DELETEs are just like any other IKEv2 exchange. If at active attacker swallows DELETEs or their responses, eventually at least one side loses the IKE SA. But with regular initial IKE, there is an asymmetry. The Responder verifies the IKE_AUTH request, generates the Response, sends it, and believes that everything is just fine. Then the Initiator gets the IKE_AUTH response, and decides that something is wrong. Maybe the certificate has just expired, or the OCSP server is unreachable, or the new certificate does not have the proper extended key usage. So we have an asymmetry, where the Responder believes that IKE_AUTH succeeded, while the Initiator believes that it failed. The Initiator quickly rectifies this with a DELETE, but that takes some time (milliseconds, but still - time). So if we tie some action on the part of both parties to the IKE_AUTH success, we get cases where the Responder performs the action, while the Initiator does not. In this case, the Responder transfers the child SAs to the new IKE SA, and the Initiator do
Re: [IPsec] CAFR -01 comments
Or do my other favorite thing with a "support_cafr" notification in the Initial exchange, so that support indicates that you understand protocol=1 and SPI size=16. If we ever do an IKEv3, we need a "Features" payload, where optional capabilities be listed in compact form. That and replacing "Next Payload" with "This Payload" Yoav On Aug 25, 2013, at 12:07 PM, Yaron Sheffer wrote: > Thanks for pointing me to the registry! > > I'm not worried about creative interpretations. More about existing > implementations doing the wrong thing. So yes, maybe we should register a new > value. > > Thanks, > Yaron > > On 2013-08-25 11:47, Yoav Nir wrote: >> I read section 3.10 in RFC 4306, and it says this: >> >>o Protocol ID (1 octet) - If this notification concerns an existing >> SA, this field indicates the type of that SA. For IKE_SA >> notifications, this field MUST be one (1). For notifications >> concerning IPsec SAs this field MUST contain either (2) to >> indicate AH or (3) to indicate ESP. For notifications that do not >> relate to an existing SA, this field MUST be sent as zero and MUST >> be ignored on receipt. All other values for this field are >> reserved to IANA for future assignment. >> >>o SPI Size (1 octet) - Length in octets of the SPI as defined by the >> IPsec protocol ID or zero if no SPI is applicable. For a >> notification concerning the IKE SA, the SPI Size MUST be zero and >> the field must be empty. >> >> Sure there is a registry: >> http://www.iana.org/assignments/ikev2-parameters/ikev2-parameters.xhtml#ikev2-parameters-18 >> . There are even values #4 and #5. But I see that bit about SPI size having >> to be zero, because it is assumed that notification about IKE SA only relate >> to *this* IKE SA. >> >> So we can creatively interpret "the IKE SA" to be different from "an IKE >> SA", or we can ask IANA to add a new value with meaning "other IKE SA". >> Agree it's a corner case. >> >> -Original Message- >> From: Yaron Sheffer [mailto:yaronf.i...@gmail.com] >> Sent: Sunday, August 25, 2013 11:12 AM >> To: Yoav Nir >> Cc: IPsecme WG >> Subject: Re: [IPsec] CAFR -01 comments >> >> Hi Yoav, >> >> Regarding the notification syntax, it is actually a bit worse than that. >> This is a corner case in the RFC, but if you read Sec. 3.10 literally, there >> are exactly 2 allowed values for the Protocol ID field (or 3 values, if you >> read RFC 4306). There is no extensibility defined, and no IANA registry >> either. So a responder would be correct if it replied with an INVALID_SYNTAX >> rather than ignoring your notification, if it doesn't recognize it. >> >> And the value you are using (1) comes from RFC 2407 and has never existed in >> IKEv2. Ugh. >> >> Thanks, >> Yaron >> >> On 2013-08-25 10:53, Yoav Nir wrote: >>> >>> On Aug 25, 2013, at 9:45 AM, Yaron Sheffer wrote: >>> Hi Yoav, I started by reading -01, then went back to -00. And I think the two can be merged to create a better solution. Including the notification as soon as the peers know they want a handover is cleaner. So IKE_AUTH (of the new SA) is better than DELETE, and in fact IKE_SA_INIT would be even more useful because then you can define that all such IKE SAs are implicitly childless, and avoid the need for the RFC 6023 notification. CAFR -01 says a peer is allowed to hand over the Child SAs if it successfully authenticates to the other peer and has the same authenticated identity. Seems to me this is symmetric, i.e. it doesn't matter if the exchange is run over the "old" or the "new" IKE SA. And so this could apply just as well to -00, and the POP stuff is not needed. I'm not sure about the race discussion in -00, because it only applies in failure cases. Can't an attacker "swallow" a few DELETE messages or their responses and cause a similar database mismatch? >>> >>> I hope they can't. Informationals with DELETEs are just like any other >>> IKEv2 exchange. If at active attacker swallows DELETEs or their responses, >>> eventually at least one side loses the IKE SA. >>> >>> But with regular initial IKE, there is an asymmetry. The Responder verifies >>> the IKE_AUTH request, generates the Response, sends it, and believes that >>> everything is just fine. Then the Initiator gets the IKE_AUTH response, and >>> decides that something is wrong. Maybe the certificate has just expired, or >>> the OCSP server is unreachable, or the new certificate does not have the >>> proper extended key usage. So we have an asymmetry, where the Responder >>> believes that IKE_AUTH succeeded, while the Initiator believes that it >>> failed. The Initiator quickly rectifies this with a DELETE, but that takes >>> some time (milliseconds, but still - time). >>> >>> So if we tie some action on the part of bot
Re: [IPsec] CAFR -01 comments
Thanks for pointing me to the registry! I'm not worried about creative interpretations. More about existing implementations doing the wrong thing. So yes, maybe we should register a new value. Thanks, Yaron On 2013-08-25 11:47, Yoav Nir wrote: I read section 3.10 in RFC 4306, and it says this: o Protocol ID (1 octet) - If this notification concerns an existing SA, this field indicates the type of that SA. For IKE_SA notifications, this field MUST be one (1). For notifications concerning IPsec SAs this field MUST contain either (2) to indicate AH or (3) to indicate ESP. For notifications that do not relate to an existing SA, this field MUST be sent as zero and MUST be ignored on receipt. All other values for this field are reserved to IANA for future assignment. o SPI Size (1 octet) - Length in octets of the SPI as defined by the IPsec protocol ID or zero if no SPI is applicable. For a notification concerning the IKE SA, the SPI Size MUST be zero and the field must be empty. Sure there is a registry: http://www.iana.org/assignments/ikev2-parameters/ikev2-parameters.xhtml#ikev2-parameters-18 . There are even values #4 and #5. But I see that bit about SPI size having to be zero, because it is assumed that notification about IKE SA only relate to *this* IKE SA. So we can creatively interpret "the IKE SA" to be different from "an IKE SA", or we can ask IANA to add a new value with meaning "other IKE SA". Agree it's a corner case. -Original Message- From: Yaron Sheffer [mailto:yaronf.i...@gmail.com] Sent: Sunday, August 25, 2013 11:12 AM To: Yoav Nir Cc: IPsecme WG Subject: Re: [IPsec] CAFR -01 comments Hi Yoav, Regarding the notification syntax, it is actually a bit worse than that. This is a corner case in the RFC, but if you read Sec. 3.10 literally, there are exactly 2 allowed values for the Protocol ID field (or 3 values, if you read RFC 4306). There is no extensibility defined, and no IANA registry either. So a responder would be correct if it replied with an INVALID_SYNTAX rather than ignoring your notification, if it doesn't recognize it. And the value you are using (1) comes from RFC 2407 and has never existed in IKEv2. Ugh. Thanks, Yaron On 2013-08-25 10:53, Yoav Nir wrote: On Aug 25, 2013, at 9:45 AM, Yaron Sheffer wrote: Hi Yoav, I started by reading -01, then went back to -00. And I think the two can be merged to create a better solution. Including the notification as soon as the peers know they want a handover is cleaner. So IKE_AUTH (of the new SA) is better than DELETE, and in fact IKE_SA_INIT would be even more useful because then you can define that all such IKE SAs are implicitly childless, and avoid the need for the RFC 6023 notification. CAFR -01 says a peer is allowed to hand over the Child SAs if it successfully authenticates to the other peer and has the same authenticated identity. Seems to me this is symmetric, i.e. it doesn't matter if the exchange is run over the "old" or the "new" IKE SA. And so this could apply just as well to -00, and the POP stuff is not needed. I'm not sure about the race discussion in -00, because it only applies in failure cases. Can't an attacker "swallow" a few DELETE messages or their responses and cause a similar database mismatch? I hope they can't. Informationals with DELETEs are just like any other IKEv2 exchange. If at active attacker swallows DELETEs or their responses, eventually at least one side loses the IKE SA. But with regular initial IKE, there is an asymmetry. The Responder verifies the IKE_AUTH request, generates the Response, sends it, and believes that everything is just fine. Then the Initiator gets the IKE_AUTH response, and decides that something is wrong. Maybe the certificate has just expired, or the OCSP server is unreachable, or the new certificate does not have the proper extended key usage. So we have an asymmetry, where the Responder believes that IKE_AUTH succeeded, while the Initiator believes that it failed. The Initiator quickly rectifies this with a DELETE, but that takes some time (milliseconds, but still - time). So if we tie some action on the part of both parties to the IKE_AUTH success, we get cases where the Responder performs the action, while the Initiator does not. In this case, the Responder transfers the child SAs to the new IKE SA, and the Initiator doesn't. The subsequent DELETE for the new IKE SA sent by the Initiator deletes all those Child SAs on the Responder, while they remain alive and active on the Initiator. You could use some heuristic, like if the DELETE comes within x seconds of the IKE_AUTH, you transfer the child SAs back. But that is some weird code that we should not require people to make. Making the transfer follow the IKE_AUTH makes it all cleaner. Whether it's done with the old or new IKE SA depends on whether you are
Re: [IPsec] CAFR -01 comments
I read section 3.10 in RFC 4306, and it says this: o Protocol ID (1 octet) - If this notification concerns an existing SA, this field indicates the type of that SA. For IKE_SA notifications, this field MUST be one (1). For notifications concerning IPsec SAs this field MUST contain either (2) to indicate AH or (3) to indicate ESP. For notifications that do not relate to an existing SA, this field MUST be sent as zero and MUST be ignored on receipt. All other values for this field are reserved to IANA for future assignment. o SPI Size (1 octet) - Length in octets of the SPI as defined by the IPsec protocol ID or zero if no SPI is applicable. For a notification concerning the IKE SA, the SPI Size MUST be zero and the field must be empty. Sure there is a registry: http://www.iana.org/assignments/ikev2-parameters/ikev2-parameters.xhtml#ikev2-parameters-18 . There are even values #4 and #5. But I see that bit about SPI size having to be zero, because it is assumed that notification about IKE SA only relate to *this* IKE SA. So we can creatively interpret "the IKE SA" to be different from "an IKE SA", or we can ask IANA to add a new value with meaning "other IKE SA". Agree it's a corner case. -Original Message- From: Yaron Sheffer [mailto:yaronf.i...@gmail.com] Sent: Sunday, August 25, 2013 11:12 AM To: Yoav Nir Cc: IPsecme WG Subject: Re: [IPsec] CAFR -01 comments Hi Yoav, Regarding the notification syntax, it is actually a bit worse than that. This is a corner case in the RFC, but if you read Sec. 3.10 literally, there are exactly 2 allowed values for the Protocol ID field (or 3 values, if you read RFC 4306). There is no extensibility defined, and no IANA registry either. So a responder would be correct if it replied with an INVALID_SYNTAX rather than ignoring your notification, if it doesn't recognize it. And the value you are using (1) comes from RFC 2407 and has never existed in IKEv2. Ugh. Thanks, Yaron On 2013-08-25 10:53, Yoav Nir wrote: > > On Aug 25, 2013, at 9:45 AM, Yaron Sheffer wrote: > >> Hi Yoav, >> >> I started by reading -01, then went back to -00. And I think the two can be >> merged to create a better solution. >> >> Including the notification as soon as the peers know they want a handover is >> cleaner. So IKE_AUTH (of the new SA) is better than DELETE, and in fact >> IKE_SA_INIT would be even more useful because then you can define that all >> such IKE SAs are implicitly childless, and avoid the need for the RFC 6023 >> notification. >> >> CAFR -01 says a peer is allowed to hand over the Child SAs if it >> successfully authenticates to the other peer and has the same authenticated >> identity. Seems to me this is symmetric, i.e. it doesn't matter if the >> exchange is run over the "old" or the "new" IKE SA. And so this could apply >> just as well to -00, and the POP stuff is not needed. >> >> I'm not sure about the race discussion in -00, because it only applies in >> failure cases. Can't an attacker "swallow" a few DELETE messages or their >> responses and cause a similar database mismatch? > > I hope they can't. Informationals with DELETEs are just like any other IKEv2 > exchange. If at active attacker swallows DELETEs or their responses, > eventually at least one side loses the IKE SA. > > But with regular initial IKE, there is an asymmetry. The Responder verifies > the IKE_AUTH request, generates the Response, sends it, and believes that > everything is just fine. Then the Initiator gets the IKE_AUTH response, and > decides that something is wrong. Maybe the certificate has just expired, or > the OCSP server is unreachable, or the new certificate does not have the > proper extended key usage. So we have an asymmetry, where the Responder > believes that IKE_AUTH succeeded, while the Initiator believes that it > failed. The Initiator quickly rectifies this with a DELETE, but that takes > some time (milliseconds, but still - time). > > So if we tie some action on the part of both parties to the IKE_AUTH success, > we get cases where the Responder performs the action, while the Initiator > does not. In this case, the Responder transfers the child SAs to the new IKE > SA, and the Initiator doesn't. The subsequent DELETE for the new IKE SA sent > by the Initiator deletes all those Child SAs on the Responder, while they > remain alive and active on the Initiator. You could use some heuristic, like > if the DELETE comes within x seconds of the IKE_AUTH, you transfer the child > SAs back. But that is some weird code that we should not require people to > make. > > Making the transfer follow the IKE_AUTH makes it all cleaner. Whether it's > done with the old or new IKE SA depends on whether you are worried about > childless IKE SAs kidnapping the children of other IKE SAs (sorry, couldn't > resist). We are not likely to require sameness of IP address, an
Re: [IPsec] CAFR -01 comments
Hi Yoav, Regarding the notification syntax, it is actually a bit worse than that. This is a corner case in the RFC, but if you read Sec. 3.10 literally, there are exactly 2 allowed values for the Protocol ID field (or 3 values, if you read RFC 4306). There is no extensibility defined, and no IANA registry either. So a responder would be correct if it replied with an INVALID_SYNTAX rather than ignoring your notification, if it doesn't recognize it. And the value you are using (1) comes from RFC 2407 and has never existed in IKEv2. Ugh. Thanks, Yaron On 2013-08-25 10:53, Yoav Nir wrote: On Aug 25, 2013, at 9:45 AM, Yaron Sheffer wrote: Hi Yoav, I started by reading -01, then went back to -00. And I think the two can be merged to create a better solution. Including the notification as soon as the peers know they want a handover is cleaner. So IKE_AUTH (of the new SA) is better than DELETE, and in fact IKE_SA_INIT would be even more useful because then you can define that all such IKE SAs are implicitly childless, and avoid the need for the RFC 6023 notification. CAFR -01 says a peer is allowed to hand over the Child SAs if it successfully authenticates to the other peer and has the same authenticated identity. Seems to me this is symmetric, i.e. it doesn't matter if the exchange is run over the "old" or the "new" IKE SA. And so this could apply just as well to -00, and the POP stuff is not needed. I'm not sure about the race discussion in -00, because it only applies in failure cases. Can't an attacker "swallow" a few DELETE messages or their responses and cause a similar database mismatch? I hope they can't. Informationals with DELETEs are just like any other IKEv2 exchange. If at active attacker swallows DELETEs or their responses, eventually at least one side loses the IKE SA. But with regular initial IKE, there is an asymmetry. The Responder verifies the IKE_AUTH request, generates the Response, sends it, and believes that everything is just fine. Then the Initiator gets the IKE_AUTH response, and decides that something is wrong. Maybe the certificate has just expired, or the OCSP server is unreachable, or the new certificate does not have the proper extended key usage. So we have an asymmetry, where the Responder believes that IKE_AUTH succeeded, while the Initiator believes that it failed. The Initiator quickly rectifies this with a DELETE, but that takes some time (milliseconds, but still - time). So if we tie some action on the part of both parties to the IKE_AUTH success, we get cases where the Responder performs the action, while the Initiator does not. In this case, the Responder transfers the child SAs to the new IKE SA, and the Initiator doesn't. The subsequent DELETE for the new IKE SA sent by the Initiator deletes all those Child SAs on the Responder, while they remain alive and active on the Initiator. You could use some heuristic, like if the DELETE comes within x seconds of the IKE_AUTH, you transfer the child SAs back. But that is some weird code that we should not require people to make. Making the transfer follow the IKE_AUTH makes it all cleaner. Whether it's done with the old or new IKE SA depends on whether you are worried about childless IKE SAs kidnapping the children of other IKE SAs (sorry, couldn't resist). We are not likely to require sameness of IP address, and I am worried about the reliability of code comparing to IKE SAs for sameness of authenticated identity. All L2TP over IPsec clients tend to have the same identity (with user authentication being done at the PPP layer). Do we allow them to claim each other's child SAs? I think not, and then if we take the "pull" approach - using the new IKE SA - we need some PoP. With a "push" approach - using the old IKE SA - we don't. Also note that the notification syntax is in conflict with both RFC 5996 and RFC 4306. RFC 5996 removes the option of Protocol ID=1, while RFC 4306 assumes that we are talking about the *current* IKE SA, and so mandates that the SPI field should be empty in this case. Practically speaking, we will have to fix 5996 before this can document move forward. Luckily we're doing just that with Tero's bis draft. Good timing! Yoav ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] CAFR -01 comments
On Aug 25, 2013, at 9:45 AM, Yaron Sheffer wrote: > Hi Yoav, > > I started by reading -01, then went back to -00. And I think the two can be > merged to create a better solution. > > Including the notification as soon as the peers know they want a handover is > cleaner. So IKE_AUTH (of the new SA) is better than DELETE, and in fact > IKE_SA_INIT would be even more useful because then you can define that all > such IKE SAs are implicitly childless, and avoid the need for the RFC 6023 > notification. > > CAFR -01 says a peer is allowed to hand over the Child SAs if it successfully > authenticates to the other peer and has the same authenticated identity. > Seems to me this is symmetric, i.e. it doesn't matter if the exchange is run > over the "old" or the "new" IKE SA. And so this could apply just as well to > -00, and the POP stuff is not needed. > > I'm not sure about the race discussion in -00, because it only applies in > failure cases. Can't an attacker "swallow" a few DELETE messages or their > responses and cause a similar database mismatch? I hope they can't. Informationals with DELETEs are just like any other IKEv2 exchange. If at active attacker swallows DELETEs or their responses, eventually at least one side loses the IKE SA. But with regular initial IKE, there is an asymmetry. The Responder verifies the IKE_AUTH request, generates the Response, sends it, and believes that everything is just fine. Then the Initiator gets the IKE_AUTH response, and decides that something is wrong. Maybe the certificate has just expired, or the OCSP server is unreachable, or the new certificate does not have the proper extended key usage. So we have an asymmetry, where the Responder believes that IKE_AUTH succeeded, while the Initiator believes that it failed. The Initiator quickly rectifies this with a DELETE, but that takes some time (milliseconds, but still - time). So if we tie some action on the part of both parties to the IKE_AUTH success, we get cases where the Responder performs the action, while the Initiator does not. In this case, the Responder transfers the child SAs to the new IKE SA, and the Initiator doesn't. The subsequent DELETE for the new IKE SA sent by the Initiator deletes all those Child SAs on the Responder, while they remain alive and active on the Initiator. You could use some heuristic, like if the DELETE comes within x seconds of the IKE_AUTH, you transfer the child SAs back. But that is some weird code that we should not require people to make. Making the transfer follow the IKE_AUTH makes it all cleaner. Whether it's done with the old or new IKE SA depends on whether you are worried about childless IKE SAs kidnapping the children of other IKE SAs (sorry, couldn't resist). We are not likely to require sameness of IP address, and I am worried about the reliability of code comparing to IKE SAs for sameness of authenticated identity. All L2TP over IPsec clients tend to have the same identity (with user authentication being done at the PPP layer). Do we allow them to claim each other's child SAs? I think not, and then if we take the "pull" approach - using the new IKE SA - we need some PoP. With a "push" approach - using the old IKE SA - we don't. > Also note that the notification syntax is in conflict with both RFC 5996 and > RFC 4306. RFC 5996 removes the option of Protocol ID=1, while RFC 4306 > assumes that we are talking about the *current* IKE SA, and so mandates that > the SPI field should be empty in this case. Practically speaking, we will > have to fix 5996 before this can document move forward. Luckily we're doing > just that with Tero's bis draft. Good timing! Yoav ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
