Steven Bellovin writes: Anyway -- I'm also willing to give in on the MAY/SHOULD for IKE, if you'll add a few more caveats. In particular, I'd like some text saying that IKE SHOULD be used (or at least that implementors should give very serious thought to it) under certain circumstances, such as (a) very mobile nodes (a MIPv6 cell phone in a car -- the Narita Express uses a 3GPP cell phone to feed the onboard 802.11), (b) very large scale deployments, where communicating shared secrets to very many different parties is hard (think of a large ISP whose customers have MIPv6 accoutnts), (c) situations where there may be thrashing between access points (Russ can tell some gruesome stories about that, but you can literally have roaming more than once per second!. Additionally, given the warnings in the document about the home agent losing sequence number state, you should probably add a suggestion that such state be checkpointed to non-volatile storage if possible. These changes will resolve my objections to draft-ietf-mobileip-ipv6. --------------------- Jari Arkko responds to Steven Bellovin: Ok about additional caveats in principle, point b about the very large scale deployments, and sequence number state. But I do have a question about points a and c above. Since the MIPv6 architecture is end-to-end to a stable home agent, the frequency of movements does not appear to make the need for dynamic keying any different. That is, if you move your security associations still exist to the home agent and you can use it. We don't talk to the new access router in any MIPv6-specific manner, hence no MIPv6-specific security is required for that. Of course you might have things like 802.1X/EAP under these network attachments, but that's another layer and not our business. --------------------- Steven Bellovin responds to Jari Arkko: But might layer 3 roaming displace layer 2 roaming? If each access point is a foreign agent, there would be a binding update for each move, right? And that would consume sequence number space. Or am I missing something? --------------------- Jari Arkko responds to Steven Bellovin: Perhaps I now understand what you are aiming at. I agree that very high consumption of sequence numbers would be a reason to use IKE. (MIPv6 does not have foreign agents, and does not need to talk securely to the local routers. So the binding updates go always between the same two nodes. Just that there might be many binding updates, especially if there's back and forth movement between APs. And it is true that layer 3 mobility mechanisms may displace some of the layer 2 mobility mechanisms currently in use, leading to a situation where layer 2 movements are more likely to imply a layer 3 movement as well. And hence a potentially high sequence number consumption, and eventually a replay protection issue.) Anyway, I'll add points a through c as reasons to use IKE. --------------------- Steven Bellovin responds to Jari Arkko: Thanks. --------------------- Jari Arkko writes: Last week, we discussed about the key management issue, and your additional caveats. Please find suggested text below. The text is the new contents of the Section 15.3 and I have manually marked the changed lines with an asterisk. 15.3 Binding Updates to Home Agent Signaling between the mobile node and the home agent requires message integrity. This is necessary to assure the home agent that a Binding Update is from a legitimate mobile node. In addition, correct ordering and anti-replay protection are optionally needed. IPsec ESP protects the integrity of the Binding Updates and Binding Acknowledgements, by securing mobility messages between the mobile node and the home agent. IPsec can provide anti-replay protection only if dynamic keying is used (which may not always be the case). IPsec also does not guarantee correct ordering of packets, only that they have not been replayed. Because of this, sequence numbers within the Mobile IPv6 messages are used to ensure correct ordering (see Section 5.1). However, if the 16 bit Mobile IPv6 sequence number space is cycled through, or the home agent reboots and loses its state regarding the sequence numbers, replay and reordering attacks become possible. The use of dynamic keying, IPsec anti-replay protection, and the Mobile * IPv6 sequence numbers can together prevent such attacks. It is also * recommended that home agents consider the use of non-volatile storage * to avoid losing their state. A sliding window scheme is used for the sequence numbers. The protection against replays and reordering attacks without a key management mechanism works when the attacker remembers up to a maximum of 2**15 Binding Updates. The above mechanisms do not show that the care-of address given in the Binding Update is correct. This opens the possibility for Denial-of-Service attacks against third parties. However, since the mobile node and home agent have a security association, the home agent can always identify an ill-behaving mobile node. This allows the home agent operator to discontinue the mobile node's service, and possibly take further actions based on the business relationship with the mobile node's owner. Note that the use of a single pair of manually keyed security associations conflicts with the generation of a new home addresses [18] for the mobile node, or with the adoption of a new home subnet prefix. This is because IPsec security associations are bound to the used addresses. While certificate-based automatic keying alleviates this problem to an extent, it is still necessary to ensure that a given mobile node cannot send Binding Updates for the address of another mobile node. In general, this leads to the inclusion of home addresses in certificates in the Subject AltName field. This again limits the introduction of new addresses without either manual or automatic procedures to establish new certificates. Therefore, this specification restricts the generation of new home addresses (for any reason) to those situations where there already exists a security association or certificate for the new address. (Appendix B.4 lists the improvement of security for new addresses as one of the future developments for Mobile IPv6.) Support for IKE has been specified as optional. The following should be observed about the use of manual keying: o As discussed above, with manually keyed IPsec only a limited form of protection exists against replay and reordering attacks. A vulnerability exists if either the sequence number space is cycled through, or if the home agent reboots and forgets its sequence numbers (and uses volatile memory to store the sequence numbers). Assuming the mobile node moves continuously every 10 minutes, it takes roughly 455 days before the sequence number space has been * cycled through. Typical movement patterns rarely reach this high * frequency today. o A mobile node and its home agent belong to the same domain. If this were not the case, manual keying would not be possible [28], but in Mobile IPv6 only these two parties need to know the manually configured keys. Similarly, we note that Mobile IPv6 employs standard block ciphers in IPsec, and is not vulnerable to problems associated with stream ciphers and manual keying. o It is expected that the owner of the mobile node and the administrator of the home agent agree on the used keys and other parameters with some off-line mechanism. The use of IKEv1 with Mobile IPv6 is documented in more detail in [21]. The following should be observed from the use of IKEv1: o It is necessary to prevent a mobile node from claiming another mobile node's home address. The home agent must verify that the mobile node trying to negotiate the SA for a particular home address is authorized for that home address. This implies that even with the use of IKE, a policy entry needs to be configured for each home address served by the home agent. It may be possible to include home addresses in the Subject AltName field of certificate to avoid this. However, implementations are not guaranteed to support the use of a particular IP address (care-of address) while another address (home address) appears in the certificate. In any case, even this approach would require user-specific tasks in the certificate authority. o If preshared secret authentication is used, IKEv1 main mode cannot be used. Aggressive mode or group preshared secrets need to be used instead, with corresponding security implications. Note that like many other issues, this is a general IKEv1 issue related to the ability to use different IP addresses, and not specifically related to Mobile IPv6. For further information, see Section 4.4 in [21]. o Due to the problems outlined in Section 11.3.2, IKE phase 1 between the mobile node and its home agent is established using the mobile node's current care-of address. This implies that when the mobile node moves to a new location, it may have to re-establish phase 1. A Key Management Mobility Capability (K) flag is provided for implementations that can update the IKE phase 1 endpoints without re-establishing phase 1, but the support for this behavior is optional. o When certificates are used, IKE fragmentation can occur as discussed in Section 7 in [21]. o Nevertheless, even if per-mobile node configuration is required even with IKE, an important benefit of IKE is that it automates the negotiation of cryptographic parameters, including the SPIs, cryptographic algorithms, and so on. Thus less configuration information is needed. * o The frequency of movements in some link layers or deployment * scenarios may be high enough to make replay and reordering attacks * possible, if only manual keying is used. IKE SHOULD be used in * such cases. Potentially vulnerable scenarios involve continuous * movement through small cells, or uncontrolled alternation between * available network attachment points. * * o Similarly, in some deployment scenarios the number of mobile nodes * may be very large. In these cases it can be necessary to use * automatic mechanisms to reduce the management effort in the * administration of cryptographic parameters, even if some * per-mobile node configuration is always needed. IKE SHOULD also * be used in such cases. o Other automatic key management mechanisms exist beyond IKEv1, but this document does not address the issues related to them. We note, however, that most of the above discussion applies to IKEv2 [30] as well, at least as it is currently specified. --------------------- --------------------- --------------------- --------------------- --------------------- --------------------- --------------------- ---------------------