Steven Bellovin (IESG) writes: For a spec of this length, complexity, and security sensitivity, I'm remarkably happy with it. I have some issues, but I suspect that most can be resolved pretty easily. It was a delight to be able to delete some of my notes as I progressed through the document. Furthermore, given the length and complexity of the spec, I could easily be wrong about many of these points. I'd be delighted if that were the case. - 5.1 In my opinion, IKE support should be a SHOULD, not a MAY. I have problems with the replay protection (see below). - 9.5.1 If there's no IPsec-level replay protection, this sequence number just won't do the trick. A wireless mobile node could very easily generate enough binding updates per day that an enemy could replay old ones that appeared to be in the window. (The full IESG review is available at https://www1.ietf.org/IESG/EVALUATIONS/draft-ietf-mobileip-ipv6.bal, but note that there are still comments coming in.) ----------------- Jari Arkko responds to IESG: And then some initial responses to some of the other issues raised by IESG: o IKE SHOULD vs. MAY. There's some pushback from implementors on this. I don't think anyone wants to consider a fight about this worth significant delays, however. So I think we could arrive at either keyword and move forward. However, perhaps now is the time to write that document that I promised earlier on this issue. The short story is that for the typical MIPv6 signaling use, key refresh is unlikely to be an issue. IKE would make interoperability easier, though, as algorithms etc could be negotiated and not configured. Worth the 50.000 .. 300.000 lines of code needed for the varying level of IKE and optional certificate support? Hmm... IKE would also give better replay attack support. ----------------- Gabriel Montenegro responds to Jari Arkko: > o IKE SHOULD vs. MAY. There's some pushback from implementors on > this. I don't think anyone wants to consider a fight about this > worth significant delays, however. So I think we could arrive > at either keyword and move forward. However, perhaps now is the > time to write that document that I promised earlier on this > issue. The short story is that for the typical MIPv6 signaling > use, key refresh is unlikely to be an issue. IKE would make > interoperability easier, though, as algorithms etc could be > negotiated and not configured. Worth the 50.000 .. 300.000 lines > of code needed for the varying level of IKE and optional certificate > support? Hmm... > > IKE would also give better replay attack support. It strikes me that this short summary of the tradeoffs around IKE support should be added as a section in the security considerations section of the base draft. ----------------- Jari Arkko writes: Meeting results: The following comments were made regarding the IKE issue: - (Jari Arkko) Proposal is that we write a tradeoffs document as a new part of the security considerations section. - (Thomas Narten) Security community wants to understand the tradeoffs, and in most cases they have in the past said that the replay protection advantage far outweighs the possible disadvantages. - (Michael Thomas) Its ok to mandate keying, but should it be IKEv1, IKEv2, or KINK? Should leave the actual protocol open. - (Charlie Perkins) MIPv6 has some replay protection mechanisms already, timing studies show that this is not an issue for years of using the same keys. (Jari Arkko) Yes, need to take this in account in the tradeoffs description. - (Bernard Aboba) IKEv1 does not work well, main mode can't be used with preshared secrets, aggressive mode might worry you, and certificates don't work well because fragmentation isn't well handled in IKEv1. If you think IKEv2 solves the problem, you should read the document. ----------------- Official IETF-56 meeting minutes: Issue 281 IESG Technical comments: Technical: different issues, no problem here. Issue 281 IESG Security comments: IKE should be a SHOULD; some work required. TN: needs to be a discussion, security people need to describe _why_ it should be a SHOULD. MT: Should not be mandatory on IKE, but on some flavor of key mgmt (there's others besides IKE like kink). Not necessary to single out IKE. BA: IKE will only work with IKEv1 cuz only aggressive mode could be used (main mode), and then the handling of fragmented packets won't work, ikev2 won't fix this, you end up with 1/8 of a key mgmt CP: sequence number already does replay protection for several years (potentially) using preconfigured keys. ----------------- Thomas Narten writes: This document has bearing on the MIPv6 spec: draft-bellovin-mandate-keymgmt-00.txt. ----------------- Jari Arkko writes on the SAAG about draft-bellovin-mandate-keymgmt-00.txt: I have some comments on Steven's key management draft. The comments are embedded in the draft itself at the URL http://www.piuha.net/~jarkko/publications/ipsec/mandate_keymgmt_review.txt ----------------- Jari Arkko writes: Russ, Steve, and Steve K have all earlier filed complaints that our documents draft-ietf-mobileip-ipv6-21.txt and draft-ietf-mobileip-mipv6-ha-ipsec-04.txt have had some confusion regarding replay vs. reordering protection. Steve also questioned the current keyword for IKE. In the discussion that followed, we agreed that there were problems in the text regarding replay protection, and that at least the implications of using or not using IKE need to be documented better. In this e-mail Vijay and I attempt to provide corrected text and a more accurate description of the implications. * In the base draft, the following discussion has been added to Section 15.3 (security considerations for ha-mn communications): 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. 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 today are unlikely to reach this high frequency. However, if it is expected that this may happen in a particular deployment scenario, the use of automated key management is RECOMMENDED. 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 imples 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 Nevertheless, even if per-mobile node configuration is required even with IKE, an important benifit 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 If preshared secret authentication is used, IKEv1 main mode can not 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 behaviour is optional. o When certificates are used, IKE fragmentation can occur as discussed in Section 7 in [21]. 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. * As required by Russ and Steve K, we have changed Text in Section 1 in ha-ipsec to make clear the difference between replay and reordering protection, and that IPsec only provides the former: The control traffic between the mobile node and the home agent requires message authentication, integrity, correct ordering and replay protection. The mobile node and the home agent must have a security association to protect this traffic. In addition, Mobile IPv6 messages assist in ensuring correct ordering, as IPsec can only provide protection against replayed messages. Full protection against replay and ordering attacks is possible only when IKE is used, however. * Similarly, in Section 4.4 we changed the anti-replay text to the following: If anti-replay protection is required, dynamic keying MUST be used. 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. 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. I have NOT changed the current keyword (MAY), since my first priority has been the accurate description of the implications, whatever the implementations do. Due to the issues discussed above, in this case the use of automatic keying is not quite as scalable and easy as might perhaps be expected (I'd like to quote Bernard Aboba from IETF-56: "You only get 1/8 of a key management protocol.") However, if the IESG feels the keyword change is necessary we can do that as well: a potentially good compromise would be to require (SHOULD) dynamic keying support from home agents, but leave them optional for mobile nodes (MAY). ----------------- Russ Housley responds to Jari Arkko: I like the revised text. Are you planning to post the draft? ----------------- -----------------