Hi Pasi, I spent about three days thinking about this, but still couldn't conclude on anything. I am cc'ing Jari, since I thought he would interested in this topic and have some comments.
As you observed, Mobile IPv6 does allows the mobile node to discover a Home Agent dynamically (See RFC 5026, RFC 4877 and draft-ietf-mip6-bootstrapping-integrated-dhc) and then create the corresponding PAD and SPD entries. We obviously do not convey what sort of authentication mechanism should be used with the gateway. It is assumed that the mobile node knows which authentication mechanism to use (based on the deployment) and store this information in the newly created PAD entry. The use of DNS and DHCPv6 is allowed for discovering a home agent's address/FQDN. The discovery mechanisms based on DNS and DHCPv6 can be secured, but the secure form of these mechanisms might not be used always. So it is possible that you do end up with an insecure discovery mechanism creating new PAD and SPD entries on the mobile node. I never considered this a big deal, since the mobile node does authenticate the newly discovered home agent anyway. I also think the policy on the mobile node should be such that this discovery of a home agent should not modify existing PAD/SPD entries created using manual configuration, or some other configuration that results in persistent config state on the mobile node. I don't agree with the restriction that the original gateway and the new gateway should have the same IDr. That is too restrictive. For example, it should be possible for gw1 to redirect the client to gw2, with the two gateways having two distinct FQDNs. It is okay with me to recommend similar authentication mechanisms for the original and new gateways. But I would prefer not use a 'MUST' here. There could be scenarios where a different gateway means a different authentication mechanism. We should of course add some text in the security considerations section warning about REDIRECTs resulting in lower security with the new gateway. Note that gateway-initiated redirect (section 5) is protected by the IKEv2 SA. It is not the same as the REDIRECT message that the client receives in the IKE_SA_INIT response. So we can't say that all REDIRECT messages are insecure. I will not be able to resolve this in the version I am going to be submitting in the next couple of hours. I hope we can resolve this in the next few days. I will post another temporary version of the draft once we conclude on this issue. Regards, Vijay > -----Original Message----- > From: ipsec-boun...@ietf.org [mailto:ipsec-boun...@ietf.org] > On Behalf Of pasi.ero...@nokia.com > Sent: Monday, March 02, 2009 12:04 PM > To: ipsec@ietf.org > Subject: Re: [IPsec] WG Last Call: > draft-ietf-ipsecme-ikev2-redirect-04 > > <not wearing any hats> > > I have one somewhat substantial concern with the document: it needs to > be much clearer about what information is updated by the received > REDIRECT messages, and what is not. > > While selecting the right peer when a new ESP/AH SA needs to be > created is not specified in RFC 4301 (see RFC 4555 Appendix A.2 for > some discussion), PAD definitely is in scope, and redirect could > interact with PAD in multiple ways. > > For example, suppose the client decides that the right peer for the > ESP/AH SA is gw1.example.com. If after doing a DNS lookup and > contacting gw1.example.com it receives IDr/CERT payloads for > gw2.foobar.example, the client would report error and abort (at least > unless "the right peer for the SA" is actually a set of possible > peers, and gw2 happens to be in that set). > > Now, suppose contacting gw1.example.com results in REDIRECT to > gw2.foobar.example (GW Identity Type=FQDN). When the client contacts > gw2, and receives IDr/CERT for gw2.foobar.example, does it accept it? > > One possible answer would be that REDIRECT is interpreted just as data > received from DNS, so all the gateways (redirecting among each other) > would send same IDr value. > > Another possible answer would be that if gw2.foobar.example is already > in client's local "set of right peers for this SA", then it would be > accepted (and the client would have accepted IDr/CERT with > gw2.foobar.example also in the beginning, before it got the redirect), > otherwise not. (And the client will also accept IDr/CERT > gw1.example.com even after the redirect, when contacting gw2 ---that > would be the sensible behavior if the redirect was with GW Identity > Type=IPv4/6.) > > (Other answers than these two might be possible, too -- I have > not explored this in detail.) > > Now, it's quite obvious the intent was to do redirect securely, but we > need to spell out what the correct behavior is: do all the gateways > have a single identity (IDr), or do they have distinct PAD entries? > > (In the latter case, IKE_SA creation (with or without redirects) > succeeds only if the IDr has an entry in the PAD, and the peer is > successfully authenticated as required by the PAD. If the client > accepts IDr/CERT gw2.foobar.example, it would have also accepted it in > the first place (when trying to contact the IP address found by doing > DNS lookup for gw1.example.com, before it got any redirects). However, > in general there's no guarantee that the CHILD_SA authorization data > for the PAD entries "gw1.example.com" and "gw2.foobar.example" is > exactly the same, so although setting up the IKE_SA succeeds, creating > CHILD_SA with the intended selectors might not -- so by sending a > redirect, the gateway really assumes that the client has identical > CHILD_SA authorization data for the target.) > > The situation gets tricker when we consider Mobile IPv6, though, > because we're also updating some data outside IPsec. What exactly is > being updated by the received REDIRECT, and is this secure? Also, the > SPD entries in RFC 4877 contain the HA address -- are we updating SPD > entries based on unauthenticated REDIRECT? > > It seems some of this problem is already present in current MIP6 > bootstrapping documents (if we e.g. discover Home Agent IPv6 address > by DNS query, somehow the SPD entries must get there, based on usually > unauthenticated DNS response), and it's possible we could refer to > that work. But "treat REDIRECT just as it would have come from DNS" > is not without security issues, since MN might not use DNS to get the > HA address (we could be overwriting manually configured data known > to be secure), the DNS reply could have been protected by DNSSEC, or > the attacker might be on MN<->GW1 path (and can spoof redirects) but > not on MN/DNS server paths (so can't spoof the DNS reply). _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
