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]