Internet DRAFT - draft-floroiu-ike4mip


INTERNET DRAFT                                                J. Floroiu
Date: November 2002                                            FhG Fokus
Expires: May 2003

    Security Framework for the Access Control of MIPv6 Mobile Nodes


Status of This Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at
   any time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at

   The list of Internet-Draft Shadow Directories can be accessed at


   This draft proposes a few alterations to the Internet Key Exchange
   protocol (IKE) aimed at shortening the security associations and key
   management signaling. The resulting "IKE-like" exchange can easily be
   embedded into AAA/Mobile IP signaling, resulting in reduced
   registration and handover latencies. At the same time the premises
   for a secure access control and data traffic framework for the
   mobile nodes are created.


   In order to operate in a secure environment (especially when radio
   links are concerned) mobile nodes require a number of security
   associations to be setup between themselves and other entities that
   assist them during the roaming. In most cases the setup of such
   security associations must take place before any other signaling
   could proceed, making it a time critical operation.

   The AAA infrastructures have gained wide acceptance as instruments
   for handling the authentication and manage the access control of
   mobile nodes to visited networks.

   IKE along with a number of related protocols has been largely adopted
   for setting up secure communication channels between hosts.

Floroiu                                                         [Page 1]
INTERNET DRAFT                                             November 2002

   There has been a lot of experimentation in the area of "user plane"
   integration between Mobile IP and IPsec enabling the setup of "mobile
   VPNs" or the authentication (and possibly encryption over the public
   Internet) of Mobile IP tunnels. 

   This draft aims at achieving "control plane" integration between
   AAA/Mobile IP and IKE by reusing as much as possible from existing
   protocols. The proposed protocol is based on mechanisms defined in
   IKE and related protocols [1,2,3] (many notations have been adopted
   as well).

1. Terminology

   Mobile Node (MN)
        Mobile IP mobile node as defined in [4,5]

   Attendant (Att), AAAL (subsequently denoted as AAAF), AAAH
        As defined in [6]

   Authentication header (AH)
        As defined [7]

   Encryption header (ESP)
        As defined [8]

   Security association (SA)
        As defined in [9]

2. Assumptions

   Figure 1 depicts the signaling that takes place between a MN and the
   AAA infrastructure. The "router system" (as defined in [6]) has been
   assimilated to Att. The AAA request/answer exchange between AAAH and
   HA (not present in [6]) uses to setting up a security association
   between MN and HA (at a minimum Binding Updates need to be protected
   through AH).

     MN            Att            AAAF           AAAH            HA
     |              |              |              |              |
     |-- AAA Req -->|              |              |              |
     |              |-- AAA Req -->|              |              |
     |              |              |-- AAA Req -->|              |
     |              |              |              |-- AAA Req -->|
     |              |              |              |<-- AAA Ans --|
     |              |              |<-- AAA Ans --|
     |              |<-- AAA Ans --|
     |<-- AAA Ans --|

     AAA Req = AAA Request
     AAA Ans = AAA Answer

                   Figure 1: AAA Request-Answer exchange

Floroiu                                                         [Page 2]
INTERNET DRAFT                                             November 2002

   The following assumptions have been made:
   - Each pair Att-AAAF, AAAF-AAAH, AAAH-HA share a long term secret key
     which enables the two entities authenticate the AAA message
     exchange.  The way such keys are obtained is outside the scope of
     this draft, and any technique may be employed for this purpose:
     Diffie-Hellman certificates, message exchange over an apriori
     established TLS connection or IPsec channel, manual configuration;
   - MN and AAAH share a long term secret key which enables the two
     entities authenticate the AAA message exchange. For MNs such keys
     may be distributed on SIM cards, for instance.

3. Security requirements

   Roaming mobile nodes may visit foreign domains about which they have
   no previous knowledge, hence share no trust relationship with.  Not
   only need mobile nodes be able to establish such a relationship, but
   they also need to protect themselves against possible attacks which
   may be mounted by potential attackers visiting the foreign link.

   The foreign domain on the other hand needs to learn the mobile node's
   identity from a trusted party and ensure that no other node can pose
   as an authentic one.

   Therefore, the following objectives must be met:
   - Elimination of potential attacks based on MAC and IP address
     spoofing, by enabling MN establish an AH tunnel with Att;
   - Protection of the data traffic over the MN-Att segment by mean of
     an ESP tunnel.  Typically this segment is a wireless link (which
     makes it vulnerable to eavesdropping) and even layer II encryption
     is insufficient since all other MNs which are authorized to access
     the link, share the same layer II encryption key, regardless the
     domain they originate from;

   MN may derive a shared secret with AAAF in order to avoid contacting
   AAAH each time it moves to a new Att within the same visited domain,
   enabling AAAF act as a trusted third party for the MN as long as the
   current authentication session hasn't expired.  The way the AAA
   control messages exchanged between MN and the new Att are
   authenticated, is AAA specific, and it can be assimilated neither to
   a ISAKMP SA nor to a AH SA. A shared secret deriving from the
   SKEYID_d key negotiated by MN and AAAF (during phase 1) may however
   be appropriate for this purpose.

   Relevant to the interaction with the home agent, MN must at least
   establish an AH connection since at a minimum it must be able to
   protect the BU. Additionally, MN may want to also ensure the
   confidentiality of its data traffic, in which case an ESP tunnel must
   also be negotiated.

   Establishing security relationships with correspondent nodes may be
   achieved in a similar way. However setting up route optimization may
   be considered less time critical, therefore a MN may use reverse
   tunneling via HA until a standard IKE exchange with the CN completes.
   This draft does not address this case in detail.

Floroiu                                                         [Page 3]
INTERNET DRAFT                                             November 2002

   To conclude the discussion, figure 2 indicates the SAs a MN needs to
   establish in order to ensure a secure framework for access control
   and data traffic.

      MN          Attendant          AAAF          AAAH          HA
      |              |                |             |            |
      |<-- AH/ESP -->|                |             |            |
      |<------ Local Auth Key  ------>|             |            |
      |<--------------------------- AH/ESP --------------------->|

     Figure 2: SA protecting the MN's access control and data traffic

   The three sets of SAs can be established by performing three
   instances of the exchange described in the next section. The payloads
   can be merged into one jumbo control message so that the overall
   propagation delay is one MN-HA round trip (if, however, fragmentation
   is avoided).

4. The protocol

4.1. Notations

   A{K}(M)     Authentication of message M with symmetric key K. M is
               typically the preceding payload and therefore abbreviated 
               by "..."
   KE          Diffie-Hellman public key
   N           Nonces

   SA          Security association payload

   sa          Security association "pre-proposal" specifiying the
               protocols to be negotiated during phase 2. It is
               transmitted unprotected (unencrypted) and consists of a
               sequence of proposal payloads indicating only the 
               protocols (not the transforms), the SPI field may be set
               to 0
   IDc         Client identity
   1, 2        When follows KE, N, SA or sa indicates that the 
               corresponding parameter is relevant to ISAKMP phase 1, 
               respectively 2

   _i, _r      When used as suffixes indicate that the parameter is
               produced by the initiator, respectively by the responder

Floroiu                                                         [Page 4]
INTERNET DRAFT                                             November 2002

   HDR         ISAKMP header
   *           When follows HDR indicates ISAKMP encryption
   [   ]       Indicates optional fields

4.2. Message exchange

   The message exchange that takes place between peers, as depicted in
   figure 1, may be decomposed into a number of elementary exchanges
   like in figure 3, where I (initiator) is the MN, R (responder) is
   either Att, AAAF or HA and T (trusted third party) is AAAH.
              I                   R                   T
              |                   |                   |
              | --- Message_1 --> | --- Message_2 --> |
              | <-- Message_4 --- | <-- Message_3 --- |
              |                   |                   |

        Figure 3: Request/Answer exchange between I, R and T

   It was already assumed that I and T, as well as R and T share trust
   relationships that enable the two pairs authenticate the message
   exchange, typically by using pre-shared keys (SK_it and SK_rt,
   Message_X (X = 1..4) denote the control messages exchanged by I, R
   and T which are typically composed of a sequence of AVPs containing
   control information relevant to the AAA and Mobile IP protocols.  The
   set of existing AVPs is extended with a number of AVPs that
   encapsulate control information relevant to the SA and key management
   (a set of IKE payloads). The exchange of these latter AVPs is
   depicted in figure 4, each newly introduced AVP being delimited with
   angle brackets. All other AVPs are omitted for simplicity, therefore
   Msg_X should be considered as being embedded into Message_X (X =
   Msg_1: I->R  <HDR, SA1_i, KE1_i, N1_i, sa2_i>, A{SK_it}(...)
   Msg_2: R->T  <HDR, SA1_i, KE1_i, N1_i, sa2_i>, A{SK_it}(...),
                <HDR, SA1_r, KE1_r, N1_r>, A{SK_rt}(...)
   Msg_3: T->R  <HDR, SA1_r, KE1_r, N1_r>, A{SK_it}(...),
                <HDR, SA1_i, KE1_i, N1_i, sa2_i>, A{SK_rt}(...)
   Msg_4: R->I  <HDR, SA1_r, KE1_r, N1_r>, A{SK_it}(...),
                <HDR*, HASH(2), SA2_r, N2_r, [KE2_r], IDc_r, IDc_i>
   Msg_5: I->R  <HDR*, HASH(1), SA2_i, N2_i, [KE2_i], IDc_r, IDc_i>

                         Figure 4: The exchange

Floroiu                                                         [Page 5]
INTERNET DRAFT                                             November 2002

   The authentication of the messages corresponding to the IKE phase 1
   is delegated to the AAA infrastructure and it is done in a way
   consistent with the AAA specification, for instance by appending an
   AVP containing a HMAC computed over the protected fields. 
   Msg_1 contains the IKE header, the phase 1 SA proposal, initiator's
   nonce, public DH key and a phase 2 SA "pre-proposal". The phase 2 SA
   "pre-proposal" cannot be encrypted at this stage, the contained
   information is therefore limited to enumerating the protocols the MN
   wants to negotiate in phase 2.  The message is packed into one AVP
   which is authenticated using the pre-shared key known to I and T.
   Msg_2 is built by appending to Msg_1 a new AVP containing the
   response of R. This latter AVP is authenticated using the pre-shared
   key known to R and T.  At this moment R does not know yet whether the
   IKE message received from I is authentic or not, therefore the
   computations it performs must be reduced to a minimum. R does not
   need to generate a fresh public DH key, since the same key may be
   reused for a limited time or number of connections, and R does not
   compute yet the shared secret. However R needs to generate a coockie
   and a nonce N1_r.
   Msg_3 contains the same 2 AVPs as Msg_2, but T reverses them, so that
   both I and R can authenticate the message sent by the peer.
   As R receives Msg_3, the authenticity of the IKE message sent by I is
   proven, therefore R consumes it. Then R computes the SKEYID suite of
   shared keys and constructs the (authenticated and encrypted) phase 2
   message. The SA2_r proposal is compiled according to the MN's sa2_i
   "pre-proposal". Similar to IKE, PFS may be afforded by providing a
   new DH public key. 
   Peer identifiers ID_cr and ID_ci are needed in order to indicate the
   peer's IP addresses. This is particulary important because for the
   IPsec connection with  Att, MN uses the care-of address as the source
   address, while in home agent's SPD the peer's source address is the
   MN's home address. If the home address and the care-of address are
   dynamically allocated, they are assumed to be available at the moment
   Msg_4 is sent.

   Finally, I responds with Msg_5 indicating the accepted AH/ESP SA
   proposals. Upon reception of Msg_5, R derives the shared keys,
   installs the SAs and sets up the AH/ESP tunnels. I may immediately
   proceed with sending AH/ESP traffic.

   As soon as the initial SAs are in place, throughout the AAA
   authentication session's lifetime, and while connected through the
   same Att, the phase 2 SAs may be renegotiated periodically directly
   between I and R using a message exchange like the one below:

Floroiu                                                         [Page 6]
INTERNET DRAFT                                             November 2002  

   Msg_3: I->R  HDR*, HASH, sa2_i

   Msg_4: R->I  HDR*, HASH(2), SA2_r, N2_r, [KE2_r], ID_cr, ID_ci
   Msg_5: I->R  HDR*, HASH(1), SA2_i, N2_i, [KE2_i]

   SKEYID_a and SKEYID_e negotiated during phase 1 are used to
   authenticate and encrypt the exchange, which follows the
   same pattern as in figure 4.

   When moving to a new Att, MN and the new Att use AAAF as a trust
   party and follow the exchange described in figure 4.

5. Security Considerations

   The protocol aims at enhancing the security of MNs visiting foreign
   domains and relies on the security properties and trust model of the IKE
   protocol and AAA infrastructure.


   [1] Harkins, D. Carrel, D., "The Internet Key Exchange (IKE)", RFC 2409,
   November 1998
   [2] Maughhan, D., Schertler, M., Schneider, M., and J.  Turner,
   "Internet Security Association and Key Management Protocol (ISAKMP)",
   RFC 2408, November 1998
   [3] Piper, D., "The Internet IP Security Domain Of Interpretation for
   ISAKMP", RFC 2407, November 1998

   [4] Perkins, C., Editor, "IP Mobility Support for IPv4", RFC 3344,
   August 2002

   [5] Johnson, D., Perkins, C. Arkko, J. "Mobility Support in IPv6",
   draft-ietf-mobileip-ipv6-19.txt, work in progress

   [6] Perkins, C., Eklund, T., "AAA for IPv6 Network Access",
   draft-perkins-aaav6-06.txt, work in progress

   [7] Kent, S., Atkinson, R., "IP Authentication Header", RFC 2402,
   November 1998

   [8] Kent, S., Atkinson, R., "IP Encapsulating Security Payload (ESP)"
   RFC 2406, November 1998

   [9] Kent, S., Atkinson, R., "Security Architecture for the Internet
   Protocol", RFC2401, November 1998

Floroiu                                                         [Page 7]
INTERNET DRAFT                                             November 2002

Author's Address

   Questions about this memo can also be directed to:

     John Floroiu
     FhG Fokus
     31 Kaiserin-Augusta-Allee
     10589 Berlin, Germany
     Phone: +49 (0)30 3463 7144

Floroiu                                                         [Page 8]