Subject: [mobile-ip] response to IESG concern on replay/reorder, IKE keyword

From: Jari Arkko <[email-masked]>
Date: Sun, 18 May 2003 23:29:36 +0300

FYI: This is a response that I have sent to IESG regarding the
comments we have gotten on some errors in the replay/reordering
protection text and the IKE keyword.

--Jari

* 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).