[Search] [pdf|bibtex] [Tracker] [Email] [Nits]

Versions: 00                                                            
INTERNET-DRAFT      Home Agent Cookies    Michael Thomas
                                          Dave Oran
                                          Cisco Systems
                                          July 12, 2001






                 Home Agent Cookies for Binding Updates

                draft-thomas-mobileip-ha-cookies-00.txt




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.

   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
   http://www.ietf.org/ietf/1id-abstracts.txt

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

Abstract

   This memo describes a means of performing authentication and
   authorization of Mobile IP V6 binding updates. It takes advantage of
   the pre-existing security relationship between the mobile node and
   its home agent to allow a correspondent node to decide wether or not
   it should believe a binding update, and to perform key distribution
   for authorizing future binding updates.

   The mechanism employs authenticated cookies created by the mobile
   node using a key which it shares with its home agent. The cookie is
   included in a binding update message to the correspondent node. The



Thomas          draft-thomas-mobileip-ha-cookies-00.txt         [Page 1]


INTERNET-DRAFT   Home Agent Cookies for Binding Updates     12 July 2001


   correspondent node extracts the cookie and sends it in a verification
   request sent toward the mobile node using the mobile node's home
   address. If routing tables have not been compromised, this message
   will visit the mobile node's home agent. The home agent intercepts
   the verification request and cryptographically determines whether the
   binding update was generated by one of its mobile nodes. Assuming it
   verifies correctly, the home agent can vouch for the mobile node
   thereby authorizing the binding update.  The home agent and mobile
   node may optionally generate a new (symmetric) key to be used by the
   correspondent node in subsequent binding updates. This is shipped
   back to the correspondent node in an acknowledgment message from the
   home agent so that the correspondent node can directly verify future
   binding updates.


1. Introduction

   The advent of Mobile IPv6 brings the protential elimination of
   triangular routing between a mobile node and its correspondent nodes.
   In standard Mobile IPv6, this is achieved through the use of Binding
   Update messages sent by the mobile node to the correspondent node to
   update the mobile node's current location -- it's care of address --
   in the correspondent node's binding cache. Binding Updates, however,
   introduce a security hazard.  In the absence of some means to
   authenticate and authorize Binding Updates, an unauthorized host
   could spoof a Binding Update to the correspondent node causing all
   further traffic send by the correspondent node to be routed to the
   care of address that the attacker chose. At the very least, this
   could lead to a trivial denial of service attack, an active man in
   the middle attack, or a passive snooping attack. For this reason,
   [MOBILEIPV6] requires that binding update destination options be
   protected by an IPsec security association using an authentication
   header to insure that there is end to end (i.e. MN->CN) integrity of
   the binding messages.

   There is a presumption made in [MOBILEIPV6] that the correspondent
   node will be able to authenticate and authorize binding updates. The
   object being authenticated is, in fact, the home IP address of the
   mobile node. Therefore, in order to deploy [MOBILEIPV6] widely, there
   is a presumption that there will exist a pervasive and well
   established global PKI for asserting the ownership and validity of IP
   addresses. This is what would allow any corresponent node to
   authenticate and authorize a binding updates from a mobile node based
   on its provable right to assert a particular home IP address. Such a
   PKI for IP addresses does not today exist, and it is not clear that
   such a system could be deployed quickly enough to meet the needs
   Mobile IP users and providers. There is a lot of compelling evidence
   that this, is either extremely difficult or even less charitably, a



Thomas          draft-thomas-mobileip-ha-cookies-00.txt         [Page 2]


INTERNET-DRAFT   Home Agent Cookies for Binding Updates     12 July 2001


   fantasy.

   We therefore agree with the general premise put forth in the
   Purpose-based Keys draft [PBK] that a solution which has weaker
   properties than provable rights to assert an IP address, but which
   foils easy attack on Binding Updates is vitally necessary to the
   successful deployment of Mobile IPv6.

   The proposal put forth in the [PKB] draft, as we understand it,
   enforces the following security property:

   o    If a mobile node successfully communicates with a correspondent
        node some moment in time (i.e. an attacker has not yet spoofed a
        binding update) then future communication cannot be subverted by
        a subsequent attack.

        This Home Agent Cookies proposal enforces a different property:

   o    If a correespondent node can successfully communicate with a
        Mobile node using mobile node's home IP address (i.e. neither
        routing via the home agent nor home IP address assignment has
        been subverted), then communicating directly with the mobile
        using its current care of address is no less secure.

        We offer the following observations to support our contention
        that this property is appropriate and the mechanism we propose
        to ensure it makes a reasonable tradeoff among security, proto-
        col complexity, and deployability.


   o    We observe that while it is difficult to deploy a global PKI,
        PKI's within more confined bounds are a reasonable expectation.

   o    To wit, we believe that the current method of doing binding
        updates between the mobile node and its home agent provides ade-
        quate protection against malicious subversion since the home
        agent can through local policy means determine whether a partic-
        ular mobile node is authorized to change its reachability for
        one of the subnets that the home agent subtends.

   o    We can use the property that the home agent has the responsibil-
        ity of the reachablity of the subnets it subtends to also act as
        an authority for other nodes which may need knowledge of a
        mobile node's current binding status.

   o    We can also use the property that correspondent nodes will, in
        the absence of a binding cache entry, send packets to the mobile
        node using it's home IP address.  We can use this routing



Thomas          draft-thomas-mobileip-ha-cookies-00.txt         [Page 3]


INTERNET-DRAFT   Home Agent Cookies for Binding Updates     12 July 2001


        property to discover which router contains the mobile node's
        current binding by simply sending a packet to the mobile node
        itself.

   o    We generally make the observation that the routing infrastruc-
        ture needs to be secure enough such that attacks based upon
        being able to subvert the routing infrastructure will be viewed
        as serious in their own right and countered. We also note that
        home agents which do not act toward the eventual goal of routing
        packets to their destination make little sense, especially in
        light of routers which route packets destined for subnets which
        have been delegated to their administrative realm.

        Given the above observations, this memo describes a means of
        performing authentication and authorization as well as key dis-
        tribution for binding updates which takes advantage of the pre-
        existing security relationship between the mobile node and its
        home agent. The mechanism employs authenticated cookies created
        by the mobile node using a key which it shares with its home
        agent. The cookie is included in a binding update message to the
        correspondent node. The correspondent node extracts the cookie
        and sends it in a verification request sent toward the mobile
        node using the mobile node's home address. If routing tables
        have not been compromised, this message will visit the mobile
        node's home agent. The home agent intercepts the verification
        request and cryptographically determines whether the binding
        update was generated by one of its mobile nodes. Assuming it
        verifies correctly, the home agent can vouch for the mobile node
        thereby authorizing the binding update.  The home agent and
        mobile node may optionally generate a new (symmetric) key to be
        used by the correspondent node in subsequent binding updates.
        This is shipped back to the correspondent node in an acknowledg-
        ment message from the home agent so that the correspondent node
        can directly verify future binding updates.


2. Message Flows














Thomas          draft-thomas-mobileip-ha-cookies-00.txt         [Page 4]


INTERNET-DRAFT   Home Agent Cookies for Binding Updates     12 July 2001



2.1 Message Flow from Mobile Node to  Correspondent Node


       MN                             CN                              HA
    ----------------------------------------------------------------------

    0  <===============================================================>
              normal HA/MN security association establishment

    1  -------------------------------->
         BU+cookie[mn,ha]+cookie[mn,cn]

    2                                                          ---------
   ----------------------->
                                          BU_QUERY+cookie[mn,ha]+PK[cn]

    3                                                         <---------
   -----------------------
                                          BU_QUERY_RESP+E(key[mn,cn],PK[cn])

    4  [ <-------------------------------- ]
       [  BU_ACK                           ]

    ~~~~~
    ~~~~~

    5  -------------------------------->
         BU+cookie[mn,ha]+cookie[mn,cn]

    6  <--------------------------------
         BU_ACK


Step_0  The mobile node and its home agent create a security associa-
        tion.  In addition to the keys generated for the base security
        association, another set of keys derived from the SA's keys are
        generated by both the mobile node and the home agent. In addi-
        tion, a session identifier is also devived by both the home
        agent and the mobile node. The derivation functions are
        described in section 4.


Step_1  When the mobile node discovers that it needs to send a binding
        update for which it cannot create a normal IPsec security asso-
        ciation, it creates two cookies to be placed in the binding
        update. Each cookie contains a keyed hash over the contents of
        the binding update described in section 5. The first cookie is



Thomas          draft-thomas-mobileip-ha-cookies-00.txt         [Page 5]


INTERNET-DRAFT   Home Agent Cookies for Binding Updates     12 July 2001


        generated for the home agent, the second cookie is generated for
        the correspondent node itself. The mechanism for generating the
        key for the correspondent node is described in section 4.


Step_2  The correspondent node receives the binding update and deter-
        mines that it does not currently have the ability to verify the
        update. It then takes the cookie destined for the home agent and
        creates a Binding Update Query option -- and places either in a
        stand alone message, or piggy backed on another message destined
        for the mobile node. The destination address of the binding
        update query is the mobile node itself. The Binding Update Query
        option is inserted into the IP header to alert all of the
        routers along the way. In this way, we make certain that the
        mobile node's Home Agent will have an opportunity to process the
        Binding Update Query.


Step_3  The Home Agent receives the packet destined for the mobile node
        and processes the Binding Update Query option. It does this by
        first examining the cookie and determines whether the integrity
        check and contents are valid and fresh. If the correspondent
        node placed its public key into the Binding Update Query mes-
        sage, the Home Agent will generate a key for the correspondent
        node and place it in the Binding Update Query Response message.
        The key is generated as described in lsection 4 and contents are
        encrypted and integrity protected per section 5.


Step_4  The correspondent node receives the Binding Update Query
        Response and performs a message integrity check over the message
        and decrypts the contents, including the key. The correspondent
        node SHOULD use the newly shipped key to verify the contents of
        the cookie destined for the correspondent node in the initial
        binding update. In this way, the correspondent node can cross
        check that the home agent which sent the BUQR shares a relation-
        ship with the mobile node.

        This key is subsequently used by the correspondent node to
        directly validate the correspondent node cookie signed by the
        mobile node.  The correspondent node now alters its binding
        cache and replies to the original binding update and the tran-
        saction is complete.

        As noted above in the flow diagrams, the correspondent node only
        sends a binding update acknowledgement if the mobile node
        requested one.




Thomas          draft-thomas-mobileip-ha-cookies-00.txt         [Page 6]


INTERNET-DRAFT   Home Agent Cookies for Binding Updates     12 July 2001


Step_5  On subsequent changes to its care of address, the mobile node
        behaves identically as in step 1, creating two cookies for use
        by the home agent and correspondent node.

Step_6  The correspondent node, since it received a key in step 4 now
        has a key which it can use to verify its cookie when it receives
        a Binding Update from the Mobile Node. Assuming the cookie veri-
        fies correctly, the correspondent node alters its binding cache
        and ackowledges the Binding Update.


2.2. A Lighter Weight Alternative

   The previous section describes a means of authenticating the original
   binding update as well as creating a shared secret so that subsequent
   binding updates can be directly verified by the correspondent node.
   There is an implicit presumption is that the cost of public key
   operations to encrypt the key payload at the home agent, and decrypt
   it at the correspondent node is not too onerous. There may, however,
   be situations where this cost is not acceptible.

   If this situation arises, the act of encrypting the key payload can
   be omitted. Either the correspondent node can request that the key
   payload not be encrypted by omitting the public key, or the home
   agent can refuse to create the encrypted payload. In this scenario,
   the correspondent node will need to repeat step 2 for each movement
   of the mobile node since it will not share a key. The correspondent
   node also loses the ability to cross verify the home agent's
   response, but this may be an acceptible tradeoff given the propertiy
   we are ensuring, since this property trusts the routing system to
   deliver packets correctly.

2.3 Some Attacks
   This section outlines some of the attacks that could be mounted by an
   adversary against this scheme. They should be considered in any
   scheme which attempts to solve the same problem.

2.3.1 Attacks by Listeners on the Mobile Network
   The network that the mobile node is attached to may be susceptible to
   eavesdropping in which case an attacker could capture an outgoing
   binding update. As such, the attacker could respond to the binding
   update with its own public key. If the mobile node is configured to
   operate in the home agentless mode, it could unwittingly reveal the
   secret to the attacker on its own network.  This could lead to the
   attacker forging binding updates to the unwitting correspondent node.

   For this reason, a mobile node operating in home agentless mode
   SHOULD NOT encrypt the key for the correspondent node cookie unless



Thomas          draft-thomas-mobileip-ha-cookies-00.txt         [Page 7]


INTERNET-DRAFT   Home Agent Cookies for Binding Updates     12 July 2001


   it has reasonable assurance that snooping attacks are not an issue on
   its current set of interfaces (ie, L2 mechanisms that provide ade-
   quate privacy).

    [there may also be ways to defend against
     this by correlating the return address with the
     key somehow. I think that that might run afoul
     of the NAT friendly stuff though, so for now I've not
     taken the time to work that out. /mat]



2.3.2 Attacks by Listeners on the Correspondent Node Network
   Likewise, the network that the correspondent node is attached to may
   be subject to attacks mounted by listeners. In this case, the
   attacker may capture both the initial Binding Update as well as the
   corresponent node's Binding Update Query. This leads to two possible
   attacks.


CapturingLike the attack on the mobile node's network above, an attacker
        could capture the Binding Update and send a binding update
        request to the home agent using its own public key. Likewise as
        above, if the Correspondent Node believes the ingress interface
        is not suitably secure given layer 2 protection, it SHOULD NOT
        request an encrypted key to validate subsequent binding updates.


SpoofingIn addition, an attacker could spoof a response to the
        correspondent node since it will know the transaction identifier
        of the query. If a correspondent node receives a response with a
        positive acknowledgement followed by a response with a negative
        acknowledgement, the correspondent node MUST accept the negative
        acknowledgement so long as it's within the replay window. The
        correspondent node MAY defer sending packets on the new binding
        in order to give the intended recipient an adequate amount of
        time to respond. This leads to a potential denial of service
        attack, but only leads to degraded service due to having to do
        triangular routing.

2.3.3 Attacks by Rogue Correspondent Nodes
   Since there is no direct authentication between the home agent and
   the correspondent node it may be possible for a rogue correspondent
   node to capture a legitimate signed and fresh cookie from the mobile
   node and either act as a man in the middle or just mount an active
   eavesdropping attack.  Such an attacker could in theory obtain the
   verification key and use that verification key to generate signed and
   fresh binding updates to the victim correspondent node. Note that the



Thomas          draft-thomas-mobileip-ha-cookies-00.txt         [Page 8]


INTERNET-DRAFT   Home Agent Cookies for Binding Updates     12 July 2001


   key used to generate cookies between the mobile node and its home
   agent is not at risk from this attack.

   This attack requires a fair degree of sophistication and can only be
   mounted by an attacker on the routing path between the mobile node at
   the correspondent node.  To be successful, an attacker would first
   need to be able to capture the fresh cookie from the mobile node's
   binding update and not only spoof the Binding Update Query to the
   home agent, but also receive the response. Only then could it create
   bogus cookies, and even then it would only allow it to create bogus
   cookies to the victimized correspondent node.


2.4 Message Flow from Mobile Node to Home Agent




       MN                             CN                              HA
    ----------------------------------------------------------------------

    0  <===============================================================>
              normal HA/MN security association establishment

    1  ---------------------------------------------------------------->
         BU+cookie[mn,ha]

    2  <----------------------------------------------------------------
         BU_ACK+cookie[ha,mn]




Step_0  The mobile node and its home agent create a security associa-
        tion.  In addition to the keys generated for the base security
        association, another set of keys derived from the SA's keys are
        generated by both the mobile node and the home agent. In addi-
        tion, a session identifier is also devived by both the home
        agent and the mobile node. The derivation functions are
        described in section 4.


Step_1  When the mobile node discovers that it needs to send a binding
        update to its Home Agent, it creates a cookie to be placed in
        the binding update. The cookie contains a keyed hash over the
        contents of the binding update described in section 5. The lone
        cookie in this case is generated for the home agent.  The
        mechanism for generating the key for the correspondent node is



Thomas          draft-thomas-mobileip-ha-cookies-00.txt         [Page 9]


INTERNET-DRAFT   Home Agent Cookies for Binding Updates     12 July 2001


        described in section 4.


Step_2  The Home Agent receives the binding update and verifies the
        cookie in the same manner as when it receives it in the binding
        update query message.  In response, the Home Agent places a
        cookie in the binding update acknowledgment created in the same
        manner as the mobile node. This is used by the mobile node to
        verify that the Home Agent produced the acknowledgment.


2.5. Home Agentless Operation

   It should be observed that the basic trust arrangement being enforced
   by this memo is the return routability.  While this property can be
   enforced by a mobile node's home agent and has some desirable charac-
   teristics such as the possibility of a disinterested third party in
   the verification process of a binding update, this property cannot be
   relied upon. The reason is simple: there may not be a Home Agent in
   the path between the a supposedly mobile node and the correspondent
   node. Also: since we are using a shared key between the home agent
   and mobile node and the correspondent node has no means to determine
   whether the home agent or correspondent node created the message in
   question. This is a direct consequence of not having strong third
   party authentication.

   However, this could be viewed as a feature. If a Home Agent is not
   willing or unable to authorize binding updates, we can still use the
   mobile node itself to provide the base level return routability. In
   fact, there are many schemes which provide this kind of test, so this
   memo is hardly unique in that respect. For completeness, this memo
   provides the protocol machinery which for that which was inevitable
   consequence of the protocol.

       MN                             CN
   HA
    ----------------------------------------------------------------------

    0  <===============================================================>
              normal HA/MN security association establishment

    1  -------------------------------->
         BU+cookie[mn,ha]+cookie[mn,cn]

    2 <---------------------------------
         BU_QUERY+cookie[mn,ha]+PK[cn]

    3 --------------------------------->



Thomas          draft-thomas-mobileip-ha-cookies-00.txt        [Page 10]


INTERNET-DRAFT   Home Agent Cookies for Binding Updates     12 July 2001


         BU_QUERY_RESP+E(key[mn,cn],PK[cn])

    4  [ <---------------------------- ]
       [  BU_ACK                       ]

    ~~~~~
    ~~~~~

    5  -------------------------------->
         BU+cookie[mn,ha]+cookie[mn,cn]

    6  <--------------------------------
         BU_ACK

   Note that this flow is identical to the flow in section 2.1 with the
   exception that the mobile node takes the place of the home agent. In
   fact, since the "home agent" functionality is discovered in the rout-
   ing path, there is no difference in implemenation on the correspon-
   dent node's part.  Also: the mobile node may, like the home agent,
   decide whether it wants to create a shared key with the correspondent
   node if it supplies its public key.

   In some sense, this memo is really just extends the base level return
   routability test to potentially involve a disinterested third party
   in the form of a real home agent. When the home agent is either miss-
   ing or not willing to perform verification requests the mobile node
   SHOULD expect that it will perform verification requests from time to
   time. If it is incapable or unwilling to receive verification
   requests, it MUST NOT send home agent cookies.


2.6. NAT Considerations


   To understand NAT considerations, we use the following diagram to
   describe the various possibilities of where NAT's may reside. Since
   NAT's must do stateful inspection, we consider that the gateway from
   which a message originates from behind a NAT is the same NAT that the
   response will traverse. It should be noted up front that as currently
   specified in [MOBILEIPV6], Binding Updates cannot traverse NAT's
   whatsover when they are protected by [AH] since [AH] includes the
   source address in its authenticator calculation. We also consider
   that basic issues with [MOBILEIPV6] with NAT's such as the Alterna-
   tive Care of Address binding update suboption are out of scope for
   this discussion since they have considerations for mobile IPv6 in
   general which need to be sorted out.





Thomas          draft-thomas-mobileip-ha-cookies-00.txt        [Page 11]


INTERNET-DRAFT   Home Agent Cookies for Binding Updates     12 July 2001



            +------+
            |      |
            |  HA  |
            |      |
            +------+
          -----N1------
                        |
                        |  +------+
                        |  |      |
                        N2 |  CN  |
                        |  |      |
                        |  +------+
                        |
          -----N3------
            +------+
            |      |
            |  MN  |
            |      |
            +------+


   In addition, we consider the special case where the Home Agent and
   Mobile Node are behind a single NAT; this will be denoted as N1+N3.

   To illustrate the interactions of Mobile IP with NAT's, we first
   declare as out of scope any situation which would produce a server
   behind a NAT since this is not a well defined property of NAT's. Thus
   the cases that seem important are:

    MN->HA: MN behind N3
    HA->MN: MN behind N3
    CN->MN: CN behind N2, MN server behind N1
    MN->CN: MN behind N1, CN server behind N2
    CN->HA: CN behind N2
    HA->CN: CN behind N2


MN      This situation may occur if a mobile node finds itself roamed
        into another network, but can only get a private address.  It is
        expected that NAT N3 will perform address translation on the
        binding update's IP headers to reflect the proper address both
        to the home agent and the correspondent nodes. This case poses
        no additional issues for the methods described in this memo.


MN      This case is probably the common case where a mobile device is
        behind the same NAT as its home agent. This situation would



Thomas          draft-thomas-mobileip-ha-cookies-00.txt        [Page 12]


INTERNET-DRAFT   Home Agent Cookies for Binding Updates     12 July 2001


        arise, for example, if a mobile device were roamed away from its
        home, but still behind a NAT'ing firewall of a corporation. This
        case poses no issues for the methods described in this memo.


CN      In this case, the correspondent node is the client initiating a
        conversation to the mobile node acting as a server. Since the
        key agreement function between HA and MN for subsequent keys
        which are given out to correspondent nodes is based in part on
        the correspondent's apparent IP address, an identifier similar
        to the session identifier is created so that the correspondent
        node can always use the correct key. The main motivation here is
        that the correspondent node might lose its NAT binding within
        the lifetime of the key, and reacquire a new binding unbeknownst
        to it. By using both the SessionID and CorrID to find the key,
        this situation can be avoided. The only other consideration here
        is that NAT N2 would need to translate and pass the Binding
        Update Query Response back from the home agent. This is similar
        to the considerations for ICMP ECHO REPLY messages.



MN      This mode violates the "no servers behind NAT".  We expect that
        this is reasonable for the general case because a NAT may reap
        any current address binding at any time unbeknownst to the
        mobile node thus it is unlikely that a stable binding could for
        the mobile node could be maintained.  If it could, this memo
        would not add any additional issues.


CN      While this strictly violates the "no servers behind NAT" dictum,
        there may be situations where this is actually a reasonable
        scenario.  Specifically, servers which are well known to the NAT
        where the NAT is performing a load balancing function seem plau-
        sible. This memo does not introduce any additional issues, how-
        ever.


2.7. Comparison to Purpose Built Key Draft

   Both this memo and draft-bradner-pbk-frame-00 are in agreement that
   depending on a pervasive PKI for IP-address addresses to secure
   Mobile IPv6 may be unwise, and that a  means of securing binding
   updates with weaker security properties should be considered. This
   section tries to outline the difference in the approaches and their
   different ramification without trying to draw any value judgements as
   to which is preferable.  For simplicity, the PBK draft will be
   refered to as PBK and this memo will be refered to as COOKIE.



Thomas          draft-thomas-mobileip-ha-cookies-00.txt        [Page 13]


INTERNET-DRAFT   Home Agent Cookies for Binding Updates     12 July 2001


o    PBK relies on the principle that authentication between two nodes
     for the purpose of binding updates is not as important as insurance
     that once a flow is initiated between two nodes, that it continue
     to flow across binding updates.

     COOKIE relies on a previously established security association
     between the mobile node and the mobile node's home agent.

     One ramification of PBK's approach is that there is an opportunity
     for a "first in" attack where a spoofed initial binding update
     could cause a denial of service attack for subsequent legitimate
     binding updates.


o    PBK does not rely on any third party infrastructure whatsoever. It
     accepts the man in the middle risk inherent in authentication-less
     schemes as an acceptible risk.

     COOKIE relies on third party authentication, namely that of the
     home agent. It uses the routing system provide a implicit means of
     delivery to the proper home agent as opposed to explicit naming
     mechanisms.


o    PBK as current proposed requires public key operations on the ini-
     tial binding and subsequent rebindings when the mobile node changes
     care of addresses. It seems feasible that PBK can be modified to
     remove the necessity for subsequent public key operations, however
     the initial public key operation is always necessary.

     COOKIE uses the security association between the home agent and the
     mobile node to create further symmetric keys. In its simplest form
     of operation, COOKIE does not require public key operations on
     either the initial or subsequent binding updates.  COOKIE does
     require a public key encryption to transfer a key to the correspon-
     dent node, but this is an explicit tradeoff of computation versus
     message efficiency that can be made by the home agent and
     correspondent node.


o    COOKIE specifically delegates the problem of updating care of
     addresses to the mobile node.  Since a mobile node may, in fact, be
     a mobile router it is important to consider the affect on the
     potentially non-mobile hosts behind the mobile router. COOKIE in
     particular does not require any special action on the part of non-
     mobile hosts behind a mobile router. It's action is similar in
     nature to any other router sending advice on the reachability of
     the subnets it subtends. The actual authorization for mobile



Thomas          draft-thomas-mobileip-ha-cookies-00.txt        [Page 14]


INTERNET-DRAFT   Home Agent Cookies for Binding Updates     12 July 2001


     subnets is implicit between the mobile router and its home agent,
     and as has been previously discussed, can be made into a local pol-
     icy matter.

     It is unclear how the PBK draft would view the mobile router issue.


o    [placeholder for futher comparisons............]


3. Home Agent Discovery

   [MOBILEIPV6] describes a means for a mobile node to discover its home
   agent. This is known as the Home Agent Discovery ICMP message and is
   sent to the Home Agents Anycast address. When the HAV bit is set in
   the home agent cookie, the correspondent node MUST form the home
   agent anycast address by appending the subnet prefix of the source
   address with the Home Agent Anycast address in [MOBILEIPV6].  The
   binding update verification request message is, in fact, Home Agent
   Discovery message with the home agent cookie appended. See section 6
   for details.

   3.1 Verification Without the Home Agent

   If the HAV bit is not set, the correspondent node may perform a
   verification directly with the mobile node. To do this, the
   correspondent node simply addresses the binding update verification
   request to the mobile node instead of the home agent anycast address.
   The mobile node MUST process the message in this case.


4. Key Derivation

   [this entire section needs more work. it should be
    viewed as a general means to arrive at shared
    keys. /mat]

   This scheme derives keys by employing the base keying material which
   was used to create a security association between the a mobile node
   and its home agent. We append identifying information as well as an
   iterator to generate enough keying material. The entire string is
   hashed using MD5 to create the new keying material.

   The keying material is generated as follows:

      iterator = 0;
      newkey [iterator] =
   MD5(key[mn,ha]+ip_addr[targ]+SessionID+iterator);



Thomas          draft-thomas-mobileip-ha-cookies-00.txt        [Page 15]


INTERNET-DRAFT   Home Agent Cookies for Binding Updates     12 July 2001


      iterator++;
      newkey [iterator] =
   MD5(key[mn,ha]+ip_addr[targ]+SessionID+iterator);
      [...]

   Where "targ" is the 128 bit IP address of the target of the cookie,
   and key[mn,ha] is the shared key between the mobile node and the home
   agent. "Interator" is a 32 bit integer, and "SessionID" is the Ses-
   sionID described below.

   The iteration function is performed as many times as is required to
   generate enough keying material to encrypt and sign the cookies. For
   128 bits of keying material for use with MD5, a single crank of the
   generating function is needed. If 256 bits of keying material is
   needed, two cranks of the generating function is necessary and so on.

   sp
4.1 Session and Correspondent Identifiers
   In order to work properly through NAT's and other situations where
   the home address may not be globally unique, a keyed hash of the home
   address is generated instead of using the IP address directly. This
   identifier is generated simultaneously by the Home Agent and the
   Mobile Node each time they establish a shared secret. The mechanism
   to generate the session identifier is:

      sessionID = MD5(key[mn,ha]+home_address[mn]);

   Where "key" is the key that will be used by the mobile node to gen-
   erate cookies to the home agent, and "home_address" the home address
   of the mobile node for this home agent. IPv4 addresses would use the
   IPv6 address range dedicated to IPv4 address as described in
   [ADDRARCH].

   In addition, to avoid missynchronization problems with key genera-
   tion, especially if the correspondent node loses a NAT binding, we
   creates a hash to identify the correspondent node for subsequent com-
   munication.

      corrID = MD5(key[mn,ha]+dest_address[cn]);

   The corr



4.2 Key Schedules
   It is necessary to allow keying material to be periodically
   refreshed. When the mobile node and the home agent rekey their secu-
   rity association, the mobile node MUST refresh the keying material



Thomas          draft-thomas-mobileip-ha-cookies-00.txt        [Page 16]


INTERNET-DRAFT   Home Agent Cookies for Binding Updates     12 July 2001


   used to create cookies, as well as creating a new session identifier.
   The mechanism used to refresh keying material is simply to start
   sending new cookies based upon a different session ID. Since the
   correspondent node will not have a binding for that session ID, it
   will as in normal operation send the Binding Update Query message
   toward the mobile node's home agent.

   To expediate generation of the keying material, the mobile node MAY
   proactively send a binding update with a cookie reflecting the new
   session ID.




5. Encryption, Authenticators, Replays and Conformance

   Cookies are actually keyed authenticators. This section describes how
   the checksums are generated and verified.  To generate a cookie
   authenticator, the hashing algorithm is run over the entire Binding
   Update except with all of the checksums in the cookie suboptions
   zeroed. The hashing algorithm is then run over the binding update and
   is then XOR'ed with the key this cookie is bound to. If the length of
   the autheticator is longer than the length of the key, the key should
   be XOR'ed with the subsequent parts of the authenticator interatively
   with the last fraction of the authentictor padded with zeros as
   necessary.

   [is this totally bogus? need to get out a crypto
    book to do this right. mainly trying to capture
    the needs of the unkeyed digest to the HA /mat]

   To verify a cookie, the same process is undertaken and the contents
   of the checksum for that cookie are compared. If they are equal, the
   verify operation succeeds. In the special case of the Binding Update
   Query, the correspondent node computes the hash of the binding update
   and places it in the Binding Update Query message.  The Home Agent
   removes the checksum, performs the key XOR as above, and completes
   the verification against the cookie's checksum.


5.1 Public Key Encryption

   [describe how the symmetric key is encrypted using the
    public key supplied in the BUQ]

   [In general, we may just want to use DH here to generate a shared
   secret between the HA and CN instead of doing public key encryption.
   Honestly, it's whichever is cheapest since there isn't any 3rd party



Thomas          draft-thomas-mobileip-ha-cookies-00.txt        [Page 17]


INTERNET-DRAFT   Home Agent Cookies for Binding Updates     12 July 2001


   authentication between HA and CN. There are legitimate questions of
   DoS attacks against HA's. Since we aren't requiring the HA to sign
   anything, it's not quite as bad as standard PK make-work DoS attacks
   since public key encryptions aren't as expensive
   signatures/decryptions. Also, we have the fact that the cookie must
   be verified successfully, and since this uses relatively cheap sym-
   metric key crypto, it would seemingly only open a DoS opportunity
   during the replay window which doesn't seem very credible.]


5.2 Crypto Conformance

   To insure interoperability, the following crypto algorithms MUST be
   supported:

   All: [MD5], [SHA-1]

   The following SHOULD be supported by the correspondent node and Home
   Agent:

   HA, CN: [RSA-1024]

   [should we specify ECC as a SHOULD too? it's a lot cheaper /mat]


5.3 Replay Attacks

   There are several notable replay attacks present in this memo. We
   will first describe the attacks, describe the method to detect
   replays, and then describe the method to counter the attacks.

   The first attack is between the mobile node and the correspondent
   node. If an attacker captures a Binding Update, it may at a later
   time replay the legitimate Binding Update causing the correspondent
   node to erroneously use a stale care of address.

   The next attack is a potential make-work attack against the home
   agent. If a legitimate Binding Update Query message is replayed --
   especially if the correspondent node has requested a key to be gen-
   erated -- the home agent may perform unnecessary public key opera-
   tions.

   The last attack is against the correspondent node.  If an attacker
   replays a binding update query response, it may needlessly perform
   expensive public key decryptions.

   5.3.1 Home Agent to Correspondent Node Attack




Thomas          draft-thomas-mobileip-ha-cookies-00.txt        [Page 18]


INTERNET-DRAFT   Home Agent Cookies for Binding Updates     12 July 2001


   This attack is easy to counter. The correspondent node places a
   unique XID in the Binding Update Query message and only accepts Bind-
   ing Update Query Responses for XID's for which it has not received a
   reply.

   5.3.2 Cookie Replay Detection

   Each cookie contains a sequence number. The mobile node generates an
   initial sequence number of its choice for each new key it generates.
   The destination (either Home Agent of Correspondent Node) MUST accept
   the initial sequence number when it see a new key, and it MUST store
   the current sequence number. The mobile node MUST insure that subse-
   quent cookies generated are monotonically incrementing and MUST NOT
   wrap around.  The receiver MUST first check the validity of the
   cookie and them MUST check its current sequence number.  It MUST NOT
   accept packets which are less than or equal to the current sequence
   number. If a sequence number jumps forward non-monotonically but is
   otherwise valid, the receiver MUST adjust its sequence number as well
   and reject any stale packets.

   5.3.3 Correspondent Node to Home Agent Attack

   If the Home Agent detects a replay, it may in fact just be a
   retransmission of a binding update query. Since the Correspondent
   Node cannot recreate the cookie itself, the Home Agent SHOULD keep a
   replay cache of Binding Update Query Responses to accommodate normal
   retransmissions.  The Home Agent prunes its replay cache by both a
   timer based method, as well as deleting cached responses for which a
   newer message sequence number has been detected.

   5.3.4 Mobile Node to Correspondent Node Attack

   For this type of replay, the Correspondent Node upon detection of a
   replay MUST ignore the binding update as it is likely an attack. The
   Mobile Node MUST NOT send cookies with the same sequence number.


6. Message Formats


6.1 Cookies

       0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                                                               |
    |                                                               |
    |                           SessionID                           |



Thomas          draft-thomas-mobileip-ha-cookies-00.txt        [Page 19]


INTERNET-DRAFT   Home Agent Cookies for Binding Updates     12 July 2001


    |                                                               |
    +-------------------------------+-------------------------------+
    |                                                               |
    |                                                               |
    |                             CoorID                            |
    |                                                               |
    +-------------------------------+-------------------------------+
    |                           Sequence                            |
    +---------------+---------------+-+-+-----------+---------------+
    |    CksumLen   |  CkAlgorithm  |H|A|          Resv             |
    +---------------+---------------+-+-+-----------+---------------+
    |                                                               |
    ~                             Cksum                             ~
    |                                                               |
    +-------------------------------+-------------------------------+

                     Figure 1: Cookie Format


SessionID The Session ID is genererated as in section 4.1

CorrID    The CorresponentID as genererated as in section 4.1 and is
          used by the correspondent node to select the proper key if it
          previously requested a key in a binding update query. To
          select the proper key, the correspondent node MUST select the
          key based on both the SessionID and the CorrID.

Sequence  A monotonically incrementing number whose initial sequence is
          set by the mobile node. See section 5.3

CksumLen  The length of the authenticator

CkAlgorithmThe hashing algorithm used to compute the checksum as speci-
          fied by [AH? IKE?].

H         H is the Home Agent flag. If the cookie is destined for the
          Home Agent, this flag is set, otherwise it is zero.

A         A is the Home Agent Anycast flag. When this flag is set, the
          correspondent node MUST send the binding update query to the
          home agent anycast address instead of directly to the mobile
          node.


Resv      Reserved for future use.

Cksum     The checksum over the entire binding update.




Thomas          draft-thomas-mobileip-ha-cookies-00.txt        [Page 20]


INTERNET-DRAFT   Home Agent Cookies for Binding Updates     12 July 2001


6.2 Cookie Suboption


   The Cookie Suboption is used for both binding updates as well as
   binding update acknowledgments when a home agent wants to send the
   mobile node a cookie.

       0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
                                    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                    |  <iana reg>   |   length      |
    +---------------+---------------+---------------+---------------+
    |                                                               |
    ~                           Cookie                              ~
    |                                                               |
    +-------------------------------+-------------------------------+

                     Figure 2: Binding Update Cookie Suboption


Cookie    The cookie destined for the home agent that the correspondent
          node received from the mobile node


6.3 Binding Update Query


   The binding update query is in the home agent discovery ICMP message
   as described in [MOBILEIPV6] with the addition of the cookies, etc
   for the query. When used as a discovery message and cookies are not
   present, the cookie, checksum and public key lengths must be set to
   zero.

   [mat: I've extended Identifier to 32 bits here? is that bogus
         in ICMP? It would be better to have more to make guessing
         attacks harder]

       0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |     Type      |     Code      |            Checksum           |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                           Identifier                          |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                                                               |
    +                            Reserved                           +
    |                                                               |



Thomas          draft-thomas-mobileip-ha-cookies-00.txt        [Page 21]


INTERNET-DRAFT   Home Agent Cookies for Binding Updates     12 July 2001


    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                                                               |
    +                                                               +
    |                                                               |
    +                          Home Address                         +
    |                                                               |
    +                                                               +
    |                                                               |
    +---------------+---------------+---------------+---------------+
    |    CookieLen  |    CkSumLen   |  PKAlgorithm  |    PKlen      |
    +---------------+---------------+---------------+---------------+
    |                                                               |
    ~                             Cookie                            ~
    |                                                               |
    +-------------------------------+-------------------------------+
    |                                                               |
    ~                             CkSum                             ~
    |                                                               |
    +-------------------------------+-------------------------------+
    |                                                               |
    ~                           PublicKey                           ~
    |                                                               |
    +-------------------------------+-------------------------------+

                     Figure 3: Binding Update Query


Type      <To Be Assigned by IANA>

Code      0

Checksum  The ICMP checksum [5].

IdentifierAn identifier to aid in matching Binding Update Query Reply
          messages to this Binding Update Query message.

Resv      Reserved bits

CookieLen The length in octets of the cookie.

CkSumLen  The length in octets of the checksum.

PKAlgorithmThe Public Key encryption algorithm used. [reference
          ISAKMP/IKE IANA numbers /mat]

PKlen     The length in octets of the public key.

Cookie    The cookie destined for the home agent that the correspondent



Thomas          draft-thomas-mobileip-ha-cookies-00.txt        [Page 22]


INTERNET-DRAFT   Home Agent Cookies for Binding Updates     12 July 2001


          node received from the mobile node

CkSum     The checksum is generated by the correspondent node by running
          the hashing algorithm specified in the cookie. This is not a
          keyed hash. The home agent verifies this hash against the
          checksum in the cookie as described in section 5.  [this is in
          lieu of sending the whole BU /mat]

PublicKey The public key that the correspondent node desires to have the
          key encrypted with.


6.4 Binding Update Query Response



    0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |     Type      |     Code      |            Checksum           |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                          Identifier                           |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |         AddressLen            |            Reserved           |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                            Reserved                           |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                                                               |
    +                                                               +
    .                                                               .
    .                      Home Agent Addresses                     .
    .                                                               .
    +                                                               +
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |          ResponseCode         |  EAlgorithm  |    Elen        |
    +---------------+---------------+---------------+---------------+
    |                                                               |
    ~                           Encrypted Key                       ~
    |                                                               |
    +-------------------------------+-------------------------------+

                     Figure 4: Binding Update Query Response


Type      <To Be Assigned by IANA>

Code      0



Thomas          draft-thomas-mobileip-ha-cookies-00.txt        [Page 23]


INTERNET-DRAFT   Home Agent Cookies for Binding Updates     12 July 2001


Checksum  The ICMP checksum [5].

IdentifierAn identifier to aid in matching Binding Update Query Reply
          messages to this Binding Update Query message.

Resv      Reserved bits

AddressLenThe length in bytes of the home agent addresses that follow.

Home      A list of addresses of home agents on the home link for the
          mobile node.

ResponseCode
          The response for the BindingUpdateQuery. Currently defined
          responses are:


VALID:
The cookie was valid

INVALID:
 The cookie was invalid for some reason

EXPIREDSID:
  The session id has expired [what does the CN do??? /mat]

EAlgorithmThe public key encryption algorithm used as defined in [IKE]
          for the keying material supplied.

Elen      The length in octets of the encrypted key.

EncryptedKey
          The symmetric key that the correspondent node should use to
          authenticate subsequent binding update messages with
          correspondent node cookies in them.


7. Processing Considerations

   To minimize work, the following section describes some of the con-
   siderations that should be taken into account when implementing this
   memo.


8. Security Considerations

   This entire memo is aimed at fulfilling the security considerations
   of [MOBILEIPV6]. There are a few other considerations which bear



Thomas          draft-thomas-mobileip-ha-cookies-00.txt        [Page 24]


INTERNET-DRAFT   Home Agent Cookies for Binding Updates     12 July 2001


   mentioning.  Because of the desire to traverse NAT's, strong one-way
   hashes are performed to create identifiers which are used instead of
   directly using IP addresses.  While these identifiers ought to be
   unique in practice, it is remotely possible that the same identifier
   created by one mobile node is collides with another mobile node on
   the same correspondent node. We note that the same considerations
   apply to [PBK]. The net result of such a collision is that a verify
   operation -- either locally at the correspondent node, or at the home
   agent will fail for the new mobile node requesting a binding cache
   update. This will only result in the second mobile node not being
   able to create a binding cache entry which will result in triangular
   routing for the losing mobile node.  Given the remoteness of the pos-
   sibility, this does not seem to be a large problem.

References

[MOBILEIPV6]
     Mobile IP Working Group, D. Johnson, C. Perkins, "Mobility Support
     in IPv6" draft-ietf-mobileip-ipv6-03.txt

[IPSEC]
     The IPsec Working Group, S. Kent, R. Atkinson, "Security Architec-
     ture for the Internet Protocol", RFC 2401, November 1998

[IKE]The IPsec Working Group, D. Harkins, D. Carrel, "The Internet Key
     Exchange", RFC 2409, November 1998

[PBK]Mobile IP Working Group, Bradner, Mankin, Schiller, "A Frameworks
     for Purpose Built Keys (PBK)" draft-bradner-pbk-frame-00.txt


Author's Address

          Michael Thomas
          Cisco Systems
          375 E Tasman Rd
          San Jose, Ca, 95134, USA
          Tel: +1 408-525-5386
          email: mat@cisco.com

          Dave Oran
          Cisco Systems
          375 E Tasman Rd
          San Jose, Ca, 95134, USA
          email: oran@cisco.com






Thomas          draft-thomas-mobileip-ha-cookies-00.txt        [Page 25]


INTERNET-DRAFT   Home Agent Cookies for Binding Updates     12 July 2001





















































Thomas          draft-thomas-mobileip-ha-cookies-00.txt        [Page 26]