[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits] [IPR]
Versions: 00 01 02
IETF Mobile IP Working Group
INTERNET DRAFT
M. Roe
T. Aura
G. O'Shea
Microsoft
J. Arkko
Ericsson
February 2002
Expires: 1 August 2002
Authentication of Mobile IPv6 Binding Updates and Acknowledgments
<draft-roe-mobileip-updateauth-02.txt>
Status of this Memo
This document is an Internet-Draft and is subject to 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
[1]http://www.ietf.org/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at
[2]http://www.ietf.org/shadow.html
Abstract
This memo describes three protocols that may be used for
authenticating binding updates in mobile IPv6. These protocols have
the following goals:
* To prevent malicious nodes from forging binding updates for other
nodes;
* To protect other nodes on the Internet from denial of service
attacks in which a correspondent is tricked into sending them a
large amount of data that they do not want;
* To make it difficult for an attacker to exhaust a node's resource
by causing it to process large numbers of binding updates;
* To prevent binding updates being replayed for any of the above
purposes.
The three protocols differ in the amount of computation that they
require and the assumptions made about the environment in which they
are used. The symmetric key method is efficient, but can only be used
if the mobile and the correspondent have previously agreed a long-term
Roe [Page 1]
INTERNET DRAFT Authentication of Binding Updates February 2001
secret. The BAKE/2 method is also efficient, but only works if some of
the messages in the protocol take a route which is protected from
attack by means outside the protocol. The CAM-DH protocol needs more
processing power, because it involves asymmetric cryptography, but it
can be used in situations where the other two protocols cannot.
1. Threats addressed by the protocols in this memo
We have identified the following threats to the mobile IPv6 protocol:
1. A malicious mobile node might lie about its home address.
A malicious mobile node might send a correspondent node binding
updates in which the home address is set to the address of another
node ("the victim"). If the correspondent node accepted this
forged binding update, then communications between the
correspondent node and the victim would be disrupted, because
packets that the correspondent node intended to send to the victim
would be sent to the wrong care-of address.
This is a threat to confidentiality as well as availability,
because an attacker might redirect packets meant for another node
to itself in order to learn the content of those packets.
2. A malicious mobile node might lie about its care-of address.
A malicious mobile node might send a correspondent node binding
updates in which the care-of address is set to the address of
another node ("the victim node") or an address within another
network ("the victim network"). If the correspondent node accepted
this forged binding update, then the malicious mobile could trick
the correspondent into sending data to the victim node or the
victim network; the correspondent's replies to messages sent by
the malicious mobile will be sent to the victim host or network.
This could be used to cause a distributed denial of service
attack; the malicious mobile could trick a large number of servers
so that they all send a large amount of data to the same victim
node or network.
There are several variations of this threat:
+ A malicious mobile might start off by sending the
correspondent node binding updates containing its true care
of address, and then later (once its initial home and care of
addresses had been authenticated) send binding updates
containing the victim's care of address.
+ A malicious mobile might start of by sending the
correspondent node binding updates contains its true care of
address, and then continue to send binding updates containing
that care-of address even after that care of address had been
reallocated to a different node (the victim). This variation
of the threat might be regarded as less serious than the
previous two, because the attacker's choice of victim is
restricted to nodes that are currently using a care of
address that the attacker has used in the past.
3. A malicious node might send a large number of invalid binding
updates to a victim correspondent node.
If each invalid binding update took a significant amount of
resources (such as CPU) to process before it could be recognized
as invalid, then it might be possible to cause a denial of service
Roe [Page 2]
INTERNET DRAFT Authentication of Binding Updates February 2001
attack by sending the correspondent so may invalid binding updates
that it has no resources left for other tasks.
4. An attacker might reply an old binding update.
An attacker might attempt to disrupt a mobile node's
communications by replaying a binding update that the node had
sent earlier. If the old binding update was accepted, packets
destined for the mobile node would be sent to its old location and
not its current location.
All of the above threats are concerned with denial of service. The
first threat is the denial of service caused when the correspondent's
state (its binding cache) contains incorrect information derived from
forged messages. The second threat is the denial of service caused to
a third party when the correspondent is tricked into consuming network
resources. The third threat is the denial of service caused when the
correspondent must consume a significant amount of resource such as
CPU and memory to distinguish genuine updates from forged ones.
2. Abstract Protocols
2.1 Notation
This memo uses the following notation:
MN A mobile node
CN A correspondent node
A -> B Node A sends a message to B
A -> B(HoA) Node A sends a message to B at its home address
A -> B(CoA) Node A sends a message to B at its care-of address
HoA Mobile node's home address
CoA Mobile node's care-of address
MAC[K](m) A message authentication code computed on message m with key
K
H(m) A hash of message m
2.2 The Shared Key Protocol
Properties of the Protocol
The shared key protocol is used to authenticate binding updates
between a mobile node and a correspondent node that share a symmetric
key (K[h]). There are several different ways in which a correspondent
and a mobile can agree on a shared key for use with this protocol;
these will be described later.
The protocol has the following properties:
* A node needs to know the shared secret (K[h]) in order to create a
binding update that will be accepted by the correspondent. This
prevents a malicious mobile from forging binding updates
containing another node's home address; the malicious mobile will
not know the correct key.
* To create a binding update for a care-of address that is not equal
to its home address, a mobile node needs to be able to receive
Roe [Page 3]
INTERNET DRAFT Authentication of Binding Updates February 2001
messages sent to that care-of address.
* To create a binding update that deletes a binding cache entry, a
mobile node needs to know the secret K[h] but does not need to be
able to receive messages sent to a particular address.
Walkthrough
Each correspondent node has a secret key, K[CN]. This key does not
need to be shared with any other entity, so no key distribution
mechanism is needed for it. Each correspondent node also generates a
nonce, N[j], at regular intervals, for example every few minutes. A
correspondent node uses the same K[CN] and N[j] with all the mobiles
it is in communication with, so that it does not need to generate and
store a new N[j] when a new mobile contacts it. Each value of N[j] is
identified by the subscript j. j is communicated in the protocol, so
that if N[j] is replaced by N[j+1] part way through a run of a
protocol, the correspondent can distinguish messages that should be
checked against the old nonce from messages that should be checked
against the new nonce. Correspondent nodes keep both the current value
of N[j] and the previous value N[j-1]. Older values can be discarded,
as messages using them will in any case be rejected as replays. K[CN]
can be either a fixed value or regularly updated. An update of K[CN]
can be done at the same time as an update of N[j], so that j
identifies both the nonce and the key. A correspondent node can
generate a fresh K[CN] each time that it boots to avoid the need for
secure persistent storage for K[CN].
1. MN -> CN : HoA, CoA
In step 1, the mobile node informs the correspondent node that it
is mobile, and gives both the mobile's home address and its
care-of address.
2. CN -> MN(CoA) : r[c], j
r[c] = MAC[K[CN]](CoA | N[j] | 1)
In step 2, the correspondent node sends a binding request to the
mobile node. The binding request contains a challenge (r[c]), and
a serial number (j) that indicates which version of N[j] was used
to generate the challenge. The challenge is generated from N[j] so
that the correspondent does not need to store state to remember
which challenges it has sent to which mobiles --- r[c] can be
recomputed from N[j] as it is needed.
3. MN -> CN : T[0], HoA, CoA, i, MAC[K[BU]] (T[0] | HoA | CoA | i), j
K[BU] = H(K[h] | r[c])
In step 3, the mobile node hashes together the shared secret and
the challenge to form a session key (K[BU]), and then uses this
session key to authenticate a binding update. The binding update
contains j, so that the correspondent knows which value of N[j] to
use to recompute the session key. Once it has verified the MAC,
the correspondent can create a binding cache entry for the mobile.
This message contains a tag (T[0]) so that it can be distinguished
from message 1 of the variant version of the protocol (described
below). The binding update also contains a sequence number (i) so
that if more than one binding update is sent within the lifetime
of a single value of N[j], it is possible to determine their
relative ordering.
Roe [Page 4]
INTERNET DRAFT Authentication of Binding Updates February 2001
When the correspondent's binding cache entry for the mobile node
expires, the correspondent can refresh it by running the above
protocol again, starting at step 2. The message sent in step 2 of this
new run of the protocol will usually use a different value of the
challenge from message that was sent in step 2 of the previous run
with the same mobile, because the value of N[j] has changed.
If the mobile changes its care-of address, but is still able to
receive messages sent to the old care-of address, then it runs the
above protocol again using its new care-of address.
If the mobile changes its care-of address, and is unable to receive
messages sent to the old address, then it uses a variant of the
protocol to give the correspondent an earlier notification that the
old address is no longer valid:
1. MN -> CN : T[1], HoA, CoA', i', MAC[K[BU]] (T[1] | HoA | CoA',
i'), j
In step 1, the mobile node sends a binding update authenticated
using the key K[BU] derived from the key that was sent to the
mobile's old care-of address, CoA. (At this point in the protocol,
the mobile has not yet received a challenge sent to its new
care-of address, CoA). This message contains a tag (T[1]) so that
it can be distinguished from the binding update sent in message 3
of the previous protocol.
If the correspondent has a binding cache entry for the mobile, and
it is able to verify the MAC correctly, then it should mark the
binding cache entry as invalid. Note that the correspondent will
only be able to verify the MAC if it has an existing binding cache
entry for the mobile, because it will need to know the old
care-old address to reconstruct the key K[BU]. If the
correspondent does not have an existing binding cache entry for
the mobile node, then it does not need to verify the MAC because
the binding cache entry has already been deleted.
2. CN -> MN(CoA') : r'[c], j'
r'[c] = MAC[K[CN]](CoA' | N[j'] | 1)
In step 2, the correspondent sends a new challenge to the new
care-of address. It should send this challenge even if it was
unable to verify the MAC on message 1. The reason for doing this
is that it allows the protocol to resynchronise after messages
have been lost or nodes have lost their state.
3. MN -> CN : T[0], HoA, CoA', i'', MAC[K'[BU]] (T[0] | HoA | CoA',
i''), j'
K'[BU] = H(K[h] | r'[c])
The third step if this protocol is the same as the third step of
the previous protocol. Once the correspondent has verified the
MAC, it can create a new binding cache entry for the mobile (or
update the existing one).
Optimizations
1. It is not necessary to encode all the bits of j in the protocol
messages; just the least significant bit is sufficient for the
Roe [Page 5]
INTERNET DRAFT Authentication of Binding Updates February 2001
correspondent to tell whether to use N[j] or N[j-1].
2. The values of N[j] should be non-repeating, but do not need to be
unpredictable. This means that N[j] can be implemented as a
counter. The secret K[CN] should be changed if the counter wraps
or is reset (e.g. after a reboot)
3. It is not necessary to encode all the bits of the sequence number
i. It is sufficient to encode enough of the lower bits of i so
that it is possible to determine the relative ordering of binding
updates sent within the lifetime of a single N[j].
Manually Configured Keys
This protocol can be used with a shared secret K[h] that has been
configured manually. This option might be appropriate for use between
a mobile node and its home agent; the home agent can maintain a
database of the keys that have been issued to the mobile nodes that it
serves.
Use with a PKI
This protocol can also be used with a shared secret K[h] that has been
agreed using a certificate-based key agreement protocol. The
certificates should associate a node's public key with its home
address. That is, the public key infrastructure should be used to
authenticate the node's homes address rather than its care-of address.
2.3 BAKE/2
Properties of the Protocol
The "Bake/2" protocol extends the shared key protocol of section 2.2
by providing a means to establish the shared secret dynamically.
This protocol is only suitable for use in an environment where
communication from the correspondent through the home agent to the
mobile node, and between the home agent and the mobile node are
protected from eavesdropping by means outside of this protocol.
Examples of ways in which this protection could be provided include
the use of IPSEC Encapsulating Security Payload, or a physically
protected network.
An example of a situation where it would be appropriate to use this
protocol is when the home agent and the correspondent node are both on
a physically protected corporate intranet, the mobile node is
connected via a public wireless network, and the mobile node has an
encrypted tunnel between itself and the home agent.
This protocol may also provide a low level of protection when the
correspondent node is (for example) a web server connected to the
public Internet by a wired connection and the mobile node is connected
via a wireless network. The protocol can be broken by an attacker on
the route between the home agent and the correspondent node, but not
by attackers on the wireless network or elsewhere on the Internet.
Roe [Page 6]
INTERNET DRAFT Authentication of Binding Updates February 2001
Walkthrough
1. MN -> CN : HoA, CoA
In the first message, the mobile node contacts the correspondent
node, giving both the mobile's home address and its care of
address.
2. CN -> MN(HoA) : K[h], j
K[h] = MAC[K[CN]](HoA | N[j] | 0)
In the second step, the correspondent generates a value (K[h])
that will be used as a shared secret between the mobile and the
correspondent. This shared secret is sent to the mobile node via
its home agent; it is an assumption of the protocol that this
route is secure. K[h] also acts as a challenge to test that the
mobile can receive messages sent to its home address.
3. CN -> MN(CoA) : r[c], j
r[c] = MAC[K[CN]](CoA | N[j] | 1)
The correspondent also sends a challenge to the mobile's care-of
address. This step is the same as step 2 of the shared key
protocol described in section 2.2.
4. MN -> CN : T[0], HoA, CoA, i, MAC[K[BU]](T[0] | HoA | CoA | i), j
K[BU] = H(K[h] | r[c])
In the third step, the mobile sends an authenticated binding
update.
2.4 CAM-DH
Properties of the Protocol
The "CAM-DH" protocol combines the BAKE/2 protocol with a digitally
signed Diffie-Hellman key exchange. In CAM-DH, each mobile node's home
address is generated from its public signature key. The use of
cryptographically-generated addresses (CGA) avoids the need for X.509
certificates or similar mechanisms that associate keys with addresses
[5]. The mobile node uses its private signature key to sign a
Diffie-Hellman exponent which is then used to negotiate a session key.
The underlying BAKE/2 protocol provides the correspondent node with
protection against denial of service attacks - the correspondent will
not perform any asymmetric cryptographic operations until it knows it
is talking to a mobile which has been authenticated with BAKE/2 -
while the signature mechanism provides a higher level of security than
would be available with BAKE/2 used on its own.
This protocol could have been simplified by deriving mobile's home
address from the Diffie-Hellman exponent, rather than deriving it from
the public key that verifies the signature on the Diffie-Hellman
exponent. However, the extra level of indirection allows the signature
key to be used to sign messages that are used with other protocols. We
anticipate that there will be other protocols that would like to use
cryptographically generated addresses. Our approach allows a node to
use several such protocols simultaneously. Each signed key is
accompanied by a tag that indicates the protocol it is used for, to
prevent attacks based on interactions between protocols.
Walkthrough
Roe [Page 7]
INTERNET DRAFT Authentication of Binding Updates February 2001
1. MN -> CN : HoA, CoA
In the first message, the mobile node contacts the correspondent
node, giving the mobile's home and care-of addresses.
2. CN -> MN(HoA) : r[h], j, gy
r[h] = MAC[K[CN]](HoA | N[j] | 0)
In the second and third messages, the correspondent node sends the
mobile node two challenges, one to the care-of address and one to
the home address. The correspondent also sends the mobile a
Diffie-Hellman exponent. The correspondent can use the same
exponent with all mobiles it is communicating with, so there is no
need to generate a new exponent for each protocol run. Like K[CN],
y can be constant (this reduces by one the number of modular
exponentiations that the correspondent needs) or periodically
updated. If y is changed, the subscript j indicates which version
of y to use (as well as which K[CN] and N[j]).
3. CN -> MN(CoA) : r[c], j
r[c] = MAC[K[CN]](CoA | N[j] | 1)
4. MN -> CN : T[0], HoA, CoA, i, MAC[K[BU]](T[0] | HoA | CoA | i),
gx, S[PK](TypeTag | gx | HoA), PK, MAC[K[3]](...), j
K[3] = h(r[h] | r[c])
K[h] = h(gxy | r[h])
K[BU] = h(K[h] | r[c])
When it has received the two challenges, the mobile hashes them
together to form a key (K[3]), and then uses this key to compute a
message authentication code on its public key and signed
Diffie-Hellman parameter. The purpose of this MAC is to convince
the correspondent that the risk of the message being a forgery is
low enough that it is worthwhile expending computational resources
on checking the signature and calculating the Diffie-Hellman
exponent gxy. The mobile also uses Diffie-Hellman key agreement to
calculate a session key that can be used to authenticate binding
updates. The fourth message consists of a binding update, a
message authentication code on the binding update computed using
K[BU], the mobile's public signature key, the mobile's
Diffie-Hellman exponent signed with its private signature key, and
a message authentication code on all of the aforementioned data,
computed using a key derived from the two challenges.
When the correspondent receives the fourth message, it should
check the outer MAC with K[3] first. It should only attempt to
compute K[BU] and verify the inner MAC with it if the outer MAC
verifies correctly. This protects the correspondent against denial
of service attacks in which it is flooded with many bogus fourth
messages. If both MACs verify correctly, the correspondent should
store state related to the mobile, including the key K[h].
5. CN -> MN : r'[c], j'
When the correspondent node's binding cache entry is about to
expire, the correspondent sends the mobile node a binding request
containing a fresh challenge. (Typically, N[j] will have changed
since the last time a challenge was sent to the mobile).
6. MN -> CN : T[0], HoA, CoA, i, MAC[K'[BU]](T[0] | HoA | CoA | i),
j'
K[h] = h(gxy | r[h])
K'[BU] = h(K[h] | r'[c])
Roe [Page 8]
INTERNET DRAFT Authentication of Binding Updates February 2001
The mobile node hashes the old value of K[h] together with the new
challenge to compute a new key K'[BU], and sends a binding update
authenticated using this key.
Optimizations
1. All of the asymmetric cryptographic operations that the mobile
carries out can be performed instead by the home agent, provided
that the home agent is given access to the appropriate keys. An
example of a situation where the optimisation might be useful is a
low-power wireless mobile device that does not have enough
computational power for asymmetric cryptography. If this
optimisation is used, the home agent intercepts the second message
(which is routed via the home agent) and performs certain
processing on in before forwarding it on to the mobile node.
That is, the second message is replaced with the following:
CN -> HA : r[h], j, gy
HA -> MN : CN's address, K[h], j
K[h] = h(gxy | r[h])
To use this optimization, communications between the home agent
and the mobile node must be protected against eavesdropping (e.g.
by using IPSEC ESP).
2. In the case when the correspondent node is also a mobile node, all
of the asymmetric cryptographic operations that the correspondent
performs can instead be performed by the correspondent's home
agent. To enable this optimisation, the second message of the
protocol contains a flag that indicates to the mobile node whether
the correspondent is using this optimisation. When this flag is
set in the second message, the mobile should send the fourth
message to the correspondent's home address, rather than its
care-of address. That is, the mobile should disable route
optimisation when sending the third message.
3. New IPv6 Sub-option Types
This memo defines the following IPv6 destination option sub-option
types:
3.1 Care-of Address Challenge
Alignment requirement: none
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+---------------+
| TBA | Length | Serial | Protocol |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Algorithm | Challenge (variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Care-of Address Key Challenge sub-option is valid in a Binding
Request destination sub-option. The Serial field contains the variable
j in the BAKE/2 and CAM-DH protocols. The Algorithm field indicates
which cryptographic algorithm should be used to compute the
Roe [Page 9]
INTERNET DRAFT Authentication of Binding Updates February 2001
authentication information field in the Binding Update that is sent in
response to this option. The Challenge field contains the challenge
r[c] in the shared key, BAKE/2 and CAM-DH protocols; it is the second
of two components which are to be concatenated and hashed to form a
key which is then used to authenticate binding updates.
The Protocol field indicates which authentication protocol the
correspondent requires. The following values are defined:
1 The shared key protocol
2 BAKE/2
3 CAM-DH
The Algorithm field indicates which cryptographic algorithms are to be
used in the authentication protocol. The following values are defined:
1 HMAC-SHA1
The Challenge field is of variable length. It is recommended that this
field be 4 bytes long.
3.2 Response to Challenge
Alignment requirement: none
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TBA | Length | Serial | Protocol |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|K| RFU | Authenticator (variable length) |
+---------------------------------------------------------------+
The Response to Challenge sub-option is valid in a Binding Update
destination option.
The Serial field contains the variable j in the shared key, BAKE/2 and
CAM-DH protocols. That is, it tells the correspondent node that
receives the suboption which of the challenge values (N[j]) are to be
used to authenticate the binding update.
The Protocol field indicates which protocol (shared key, BAKE/2 or
CAM-DH) was used to construct the authenticator. The value of this
field is the same as the value of the Protocol field in the Challenge
sub-option.
The K bit corresponds to the tags T[0] and T[1] in the shared key
protocol. It is set to zero if the MAC on the binding update is to be
verified using the challenge that was sent to the mobile node's
current care-of address, and is set to 1 if the binding update is
authenticated using the challenge that was sent to the mobile node's
previous care-of address.
The RFU bits are reserved for future use and shall be set to zero. The
Roe [Page 10]
INTERNET DRAFT Authentication of Binding Updates February 2001
Authenticator field is computed by applying HMAC-SHA1-80 to the
following data:
AHSD, Reserved 3 bytes
Sequence Number 1 byte
Lifetime 4 bytes
Home Address 16 bytes
Care-of Address 16 bytes
K, RFU 1 byte
The A, H, S, D, Reserved, Sequence Number and Lifetime fields show
above have the same value as the corresponding fields in the Binding
Update. The Home Address field contains the Home Address from the Home
Address option earlier in the packet. The Care-Of Address field
contains the IP source address of the packet. The K and RFU fields
shown above have the same value as the corresponding fields in the
Response To Challenge sub-option.
4. Other Message Formats
4.1 DHChallenge
HomeAddressChallenge ::=
[0] SEQUENCE
{
serial INTEGER,
CHOICE
{
bake2 [0] SEQUENCE
{
key BIT STRING
}
camDH [1] SEQUENCE
{
challenge BIT STRING,
exponential INTEGER,
disableRouteOptimization BOOLEAN
}
}
}
The serial field contains the value of j. The key field contains K[h].
The challenge field contains r[h]. The exponential field contains gy.
If the disableRouteOptimization field is set to TRUE, then the
response to this message should be sent to the correspondent's home
address, not its care-of address.
4.2 DHResponse
DHResponse ::=
[1] SEQUENCE
{
serial INTEGER,
signedExponential SIGNED SEQUENCE
Roe [Page 11]
INTERNET DRAFT Authentication of Binding Updates February 2001
{
tag OBJECT IDENTIFIER,
homeAddress BIT STRING,
exponential INTEGER
}
publicKey PublicKey,
innerMAC BIT STRING,
outerMAC BIT STRING
}
The serial field contains the value of j. The exponential field
contains the value of gx. The innerMAC field contains a MAC computed
using K[BU] with HMAC-SHA1-80. The outerMAC field contains a MAC
computed using K[3] with HMAC-SHA1-80.
The value of the tag field is to be assigned.
5. Assigned Numbers
5.1 Ports
UDP_PORT_CAM to be assigned
5.2 Object Identifiers
SignedExponent to be assigned
5.3 Binding Acknowledgement Status Values
AUTHENTICATION_REQUIRED to be assigned
6. Realisation of the Abstract Protocols
6.1 The Shared Key Protocol
1. The mobile sends the correspondent a packet containing a Binding
Update destination option.
2. The correspondent sends the mobile a packet containing a Binding
Acknowledgment destination option, with the status field set to
AUTHENTICATION_REQUIRED. The Binding Acknowledgment contains a
Care-Of Address Challenge sub-option.
3. The mobile sends the correspondent a packet containing a Binding
Update destination option, which in turn contains a Response to
Challenge sub-option. The Flags field of this sub-option will be
set to 0. The Serial field of this sub-option will be the same as
the Serial field of the Care-Of Address Challenge sub-option in
the previous step. The other fields are computed as described in
section 3.2.
4. The correspondent sends the mobile a Binding Acknowledgement, with
the status field set to indicate success.
5. When the correspondent's Binding Cache Entry is about to expire,
the correspondent sends the mobile a Binding Request containing a
Care-Of Address Challenge sub-option.
6. The mobile replies to the request by sending a Binding Update
Roe [Page 12]
INTERNET DRAFT Authentication of Binding Updates February 2001
containing a Response to Challenge sub-option.
7. When the mobile's Binding Entry is about to expire, it sends the
correspondent a Binding Update containing a Response to Challenge
sub-option.
8. The correspondent replies with a Binding Acknowledgment.
+ If the value of the Serial field in the Binding Update is the
one which the correspondent is currently using, the status
field of the Binding Acknowledgement is set to indicate
success.
+ If the value of the Serial field in the Binding Update is not
the most recent one, but is recent enough to be acceptable to
the correspondent, then the Binding Acknowledgment's status
field is set to indicate success and the Binding
Acknowledgment contains a Care-Of Address Challenge
sub-option with the most recent value in the Serial field.
+ If the value of the Serial field in the Binding Update is too
old to be acceptable, the status field of the Binding
Acknowledgment is set to indicate failure and the Binding
Acknowledgment contains a Care-Of Address Challenge
sub-option with the most recent value in the Serial field.
In this case, the mobile will reply with another Binding
Update containing a Response to Challenge sub-option.
6.2 BAKE/2
1. The mobile sends the correspondent a packet containing a Binding
Update destination option.
2. The correspondent sends a UDP packet of format
HomeAddressChallenge to the mobile at the port UDP_PORT_CAM. The
optional exponential field is not present in this packet.
3. The correspondent sends to the mobile (at its care-of address) a
packet containing a Binding Acknowledgement destination option
with the status field set to AUTHENTICATION_REQUIRED. The Binding
Acknowledgment contains a Care-Of Address Challenge sub-option.
4. The mobile sends the correspondent a packet containing a Binding
Update destination option, which in turn contains a Response to
Challenge sub-option. The Authenticator field of this sub-option
is computed as described in section 3.2.
5. The correspondent sends the mobile a packet containing a Binding
Acknowledgment, with the status field set to indicate success.
The procedures taken when the correspondent's Binding Cache Entry is
about to expire, and when the mobile's Binding Entry is about to
expire, are the same as for the shared key protocol.
6.3 CAM-DH
1. The mobile sends the correspondent a packet containing a Binding
Update destination option.
2. The correspondent sends a UDP packet of format
HomeAddressChallenge to the mobile's home address at port
PORT_UDP_CAM.
3. The correspondent sends the mobile (at its care-of address) a
packet containing a Binding Acknowledgment destination option with
Roe [Page 13]
INTERNET DRAFT Authentication of Binding Updates February 2001
its status field set to AUTHENTICATION_REQUIRED. The Binding
Acknowledgment contains a Care-Of Address Challenge sub-option.
4. The mobile sends a UDP packet of format DHResponse to the
correspondent at port PORT_UDP_CAM.
5. The correspondent sends the mobile (at its care-of address) a
packet containing a Binding Request destination option, which in
turn contains a Care-Of Address Challenge sub-option.
6. The mobile sends the correspondent a packet containing a Binding
Update destination option, which in turn contains a Challenge
Serial Number sub-option.
7. Finite State Machines
7.1 The Shared Key Protocol
Mobile Node
* Event: Mobile receives a Binding Request
Action: Add the correspondent to the Binding Entry List, if it
isn't already on it. Send a Binding Update. If the Binding Request
contained a Care-of Address Challenge sub-option, include a
Response to Challenge sub-option in the Binding Update, and store
the value of the challenge in the Binding Entry List.
* Event: Mobile's Care-Of Address changes
Action: Send a Binding Update to all correspondents in the Binding
Entry List. If it is no longer possible to receive packets sent to
the old care-of address, set the T[1] tag in the binding update,
and compute the authentication field based on the challenge that
was sent to the old care-of address. If it is still possible to
receive packets sent to the old care-of address, send a binding
update without authentication.
* Event: Mobile's Binding Entry about to expire
Action: Send a Binding Update containing a Response to Challenge
sub-option to the correspondent.
* Event: Mobile receives a packet from the correspondent routed via
its home agent
Action: Check the Binding Entry List to see if a binding update
has been sent to this correspondent recently. If a binding update
has not been sent recently, send one. If the Binding Entry List
contains a recent challenge from the correspondent, use that to
construct a Response to Challenge sub-option that is included in
the Binding Update; otherwise, do not include a Response to
Challenge sub-option.
* Event: Mobile receives a Binding Acknowledgment
If the Binding Acknowledgment contains a Care-Of Address Challenge
sub-option, then the mobile stores the value of the challenge in
its binding entry list. If the Binding Acknowledgment contains a
Care-Of Address Challenge sub-option and the status field is set
to indicate failure, then the mobile sends a Binding Update
containing a Response to Challenge sub-option.
Correspondent Node
* Event: Binding Cache Entry about to expire
Roe [Page 14]
INTERNET DRAFT Authentication of Binding Updates February 2001
Action: Send the mobile a Binding Request containing a Care-of
Address Challenge sub-option
* Event: Receive a Binding Update
Action: If the Binding Update contains a Response to Challenge
sub-option, and the Serial field is sufficiently recent, and the
Authenticator field contains the right value, then update the
Binding Cache and send a Binding Acknowledgment with the status
field set to indicate success. If the value in the Serial field
was not the most recent one, include a Challenge sub-option in the
Binding Acknowledgment.
Otherwise, send a Binding Acknowledgment with the status field set
to indicate failure and containing a Care-of Address Challenge
sub-option.
8. Background to the Protocol Designs
8.1 IP Addresses derived from Cryptographic Keys
In the CAM-DH protocol, a node uses a home address that is derived
from the node's public key. The idea behind this is that if the
address is the same as the public key, nodes can work out which key
corresponds to an address without needing to use a secure key
distribution mechanism such as X.509 certificates. Such key
distribution mechanisms typically need to be configured manually, and
this conflicts with the design goal of IPv6 that it should be possible
to configure hosts automatically. However, it is not possible to set
the IP address equal to the public key, because they will normally be
of different length, and the network part of the address must be set
to the right value for the packet to be routed correctly. Instead, we
use a more complex relationship between the address and the key, in
which the last 64 bits of the address (the "Interface ID") are defined
as follows:
InterfaceId = First64(SHA1(Route Prefix | M | RFU | Public Key))
& 0xfcffffffffffffff
The field "RFU" is reserved for future use, and shall be set to zero.
The field "M" is a modifier, which is used in the following way. A
node generates a private/public key pair, and then attempts duplicate
address detection for an address generated using the above equation
with M set to zero. It is very unlikely that a collision will occur
except as a result of an attack on the protocol. However, if a
collision is detected the host MAY attempt duplicate address detection
again with a different address, generated using the same public key
and with M equal to one. If necessary, this process may be repeated
with M equal to 2 and M equal to 3. Nodes MUST NOT use values of M
greater than three. Four collisions in a row are very, very unlikely
to occur by chance, and are almost certainly the result of either an
attack on the protocol or an error in the implementation.
Bit 6 of the host part of the address is the universal/local bit [3].
It is set to zero to indicate that the address generated is not
guaranteed to be globally unique. This ensures that it will not
collide with an IP address derived from an ethernet address. It is
Roe [Page 15]
INTERNET DRAFT Authentication of Binding Updates February 2001
important to avoid such collisions, because hosts that use their MAC
address to derive their IP address will not expect such collisions,
and they might not have a means to recover from them when they occur.
Bit 7 of the host part of the address is the individual/group bit [3].
It is set to zero to indicate that it is the address of an individual
node, not a group of nodes.
The route prefix is included in the input to the hash function to
prevent an attack in which the attacker expends a very large initial
set-up cost, but is then able to attack many different nodes at a
relatively low cost per node. If the route prefix was not included, an
attacker could, at great expense, compute a lookup table that contains
a suitable key pair for each of the 2^62 possible values of the
InterfaceId. Such a lookup table could then be used to masquerade as
any mobile node. Including the route prefix makes this attack not
economically viable (from the point of view of the attacker), because
it means that such a look-up table can only be used to masquerade as
nodes which have the same route prefix. Typically, there will not be
enough nodes with the same route prefix to justify the expense of
constructing the lookup table.
8.2 Resource Exhaustion and other Denial of Service Attacks
When designing these protocols, we found it useful to distinguish
between two different types of denial of service attack. Resource
exhaustion attacks are attacks in which the victim has only a limited
amount of some resource (such as network bandwidth or CPU cycles), and
the attack consumes some of this resource, leaving the victim with not
enough of it left to carry out the other work it needs to do. There
are denial of service attacks that are not resource exhaustion
attacks. For example, forged binding updates can lead to denial of
service, because packets will be sent to the wrong care-of address.
This is not an example of resource exhaustion; a host with an
unlimited supply of network bandwidth and CPU would still be
vulnerable to denial of service attacks based on forged binding
updates. This attack works by corrupting a host's state (its binding
cache), not by running it out of resources. That is, a failure of
integrity and authentication then leads to denial of service.
The binding updates that are used in mobile IPv6 are only an
optimisation. A mobile node can communicate with a correspondent node
even if the correspondent refuses to accept any of its binding
updates. However, performance will suffer because packets from the
correspondent to the mobile will be routed via the mobile's home agent
rather than a more direct route. A correspondent can protect itself
against some of the resource exhaustion attacks by stopping processing
binding updates when it is flooded with a large number of binding
updates that fail the cryptographic integrity checks. If a
correspondent finds that it is spending more resources on checking
bogus binding updates than it is likely to save by accepting genuine
binding updates, then it can decide to reject all binding updates
without performing any cryptographic operations.
Nodes that are willing to expend significant resources responding to
Roe [Page 16]
INTERNET DRAFT Authentication of Binding Updates February 2001
anyone, no matter who they are, will often be vulnerable to resource
exhaustion attacks. The DoS protection mechanisms described in this
memo will only be useful if each node has some means of deciding
whether it should expend resources on behalf of a particular peer.
This information needed to make this decision will usually originate
in layers above IP. For example, TCP knows if the node has a queue of
data that it is trying to send to a peer. It is possible to produce a
conforming implementation of the protocols in this memo without making
use of information from higher protocol layers, but implementations
may be able to manage resources more effectively by making use of such
information.
In general, a node will be willing to devote resources to a run of an
authentication protocol for one of two reasons. In the first case, the
node itself is trying to carry out some work, and knows that
completing the authentication protocol run is necessary (or helpful)
in getting that work done. In the second case, the node's peer is
trying to carry out some work for which the authentication protocol
run is necessary or helpful. In this case, the node does not know
directly that the protocol run is worthwhile, but may be prepared to
expend resources on behalf of certain peers when they ask it to. There
is a problem with this case that is specific to authentication
protocols, and does not occur with other types of protocol. The node
will only know that it is worthwhile expending resources on a protocol
run when it knows that the run has been initiated by a peer that is
willing to devote resources to. However, it will only know this when
the peer has been successfully authenticated, that is when protocol
run has been completed and the resources have already been spent. One
way in which this situation may be improved is to divide the
authentication protocol in to two phases. The first phase consumes
very little resources, but does not provide a very high level of
security. The second phase provides a higher level of security, but
requires more resources to provide this level of security. The second
phase is only started if the first phase completes successfully. In
this way, only attackers who can break the security of the first phase
can cause a resource exhaustion attack using the second phase. We have
used this approach in the protocols described in this memo.
8.3 Piggybacking and Jitter
The mobile IPv6 specification allows for "piggybacking". That is,
control messages such as binding updates may be combined with other
messages. Piggybacking will delay these other messages in two ways.
Firstly, it will make them larger, and larger messages usually take
longer to transmit. Secondly, it will increase the amount of
processing that is needed to send and receive the messages because the
mobility information in the message will need to be processed as well.
When the control messages are authenticated with asymmetric
cryptography, they will add a large amount of jitter, because digital
signatures require many bytes to represent and take many CPU cycles to
compute or verify. Some applications, for example real-time voice, are
very sensitive to jitter.
Some networks have "quality of service" facilities whereby an
Roe [Page 17]
INTERNET DRAFT Authentication of Binding Updates February 2001
application can reserve a particular amount of bandwidth. Piggybacking
can interfere with these facilities, because when packets are made
bigger by adding mobility headers they may exceed the size that has
been reserved, and this may cause them to be discarded or severely
delayed by the network.
Accordingly, we recommend that piggybacking should not be used when
quality of service facilities are in use (e.g. the IPv6 flow id is
nonzero) and should not be used when asymmetric cryptography is being
used to protect the mobility control portion of the message. This
recommendation has affected the design of the protocols described in
this memo; digital signatures are carried in UDP messages, not IPv6
destination options. UDP messages cannot be piggybacked, but this is
not a serious problem as we recommend that these messages should not
be piggybacked.
8.4 Length of Suboptions
The IPv6 option length limits the amount of data that may be passed in
a destination option or as a suboption within a destination option.
The maximum length of a suboption is 255 bytes, or 2040 bits excluding
any other data in the protocol. Since both a public key and a
Diffie-Hellman value needs to be passed in the CAM-DH protocol,
passing these in a suboption would limit the key size to 1020 bits.
These values are just about enough for current security needs, but
seem low in view of future developments. They also preclude the use of
the same long key for both MIPv6 and other purposes. Therefore, we
have chosen to run the authentication protocol as an independent
protocol on top of UDP.
8.5 Rationale for BAKE/2
Our motivation for designing BAKE/2 was that we wanted to add support
for mobile IP without creating major new security problems. We wanted
a protocol that would protect against the new vulnerabilities that
were introduced by IP mobility. It was not our goal to protect against
attacks that were already possible before the introduction of IP
mobility. This protocol does not defend against an attacker who can
monitor the home agent to correspondent node route. Our justification
for this is that if such an attacker exists, they are able to attack
the system before IP mobility is enabled, because they can mount an
active attack against the mobile node when it is at its home location.
Prevention of such attacks is outside the scope of this protocol. The
possibility of such attacks is not an impediment to the deployment of
mobile IP, because these attacks are possible irrespective of whether
mobile IP is in use or not.
Some of our earlier protocols for authenticating binding updates, such
as CAM [5], ran the complete protocol for each binding update. The
protocol described here establishes a session key which can then be
used for many binding updates between the same nodes without running
the whole protocol again. This can result in an efficiency saving,
because binding updates are resent at regular intervals. This
efficiency saving will usually be realised when a mobile node
Roe [Page 18]
INTERNET DRAFT Authentication of Binding Updates February 2001
communicates with the same correspondent node for an extended period
of time. If the mobile node communicates with a correspondent briefly
and then never talks to it again, then the establishment of a session
key does not result in efficiency savings.
This protocol protects the correspondent node against denial of
service attacks in which the correspondent is flooded with many bogus
messages. The correspondent does not have to store state or consume a
large amount of processing time handling messages from a source which
has not yet been authenticated. The protocol does not protect the
mobile against these attacks. This means that this protocol is
suitable for use when a client on a mobile node accesses a server on a
non-mobile node, but may not be suitable for use when accessing a
server on a mobile node. It is an assumption of the protocol that at
the start of a run the mobile node already has stored state about the
correspondent (perhaps at a level above IP, such as TCP or the
application), and knows that it is worthwhile expending resources on
the run. There is a clear need for a protocol for the opposite case,
where the correspondent has pre-existing stored state about the mobile
and knows that it is worthwhile expending resources on the protocol
run. This is a matter for further study.
This protocol also protects against denial of service attacks in which
the attacker pretends to be a mobile, but uses the victim's address as
the care of address, and so causes the correspondent to send the
victim traffic that it does not want. For example, suppose that the
correspondent is a news site that will send a high-bandwidth stream of
video to anyone who asks for it. Note that the use of flow-control
protocols such as TCP does not necessarily defend against this type of
attack, because the attacker can fake the acknowledgements. Even
keeping TCP initial sequence numbers secret doesn't help, because the
attacker can receive the first few segments (including the ISN) at its
own address, and then redirect the stream to the victim's address.
This protocol defends against these attacks by only completing if
packets sent by the correspondent to the care of address are received
and processed by an entity that is willing to participate in the
protocol. Normally, this will be the mobile node.
9. Intellectual Property Rights Notice
The CAM-DH variant of our protocols uses public keys and hashes to
prove address ownership [4,5]. In case there would be any Ericsson IPR
on such methods, the Ericsson policy on IPR issues can be checked from
the Ericsson General IPR statement for IETF,
[3]http://www.ietf.org/ietf/IPR/ERICSSON-General. Microsoft's IPR
statement concerning this memo is available at
[4]http://www.ietf.org/ietf/IPR/MICROSOFT-MOBILEIP-UPDATEAUTH.txt.
10. Security Considerations
10.1 Risks of unauthenticated binding updates
If a node accepts binding updates without authentication, then it is
vulnerable to several attacks in which an attacker sends forged
Roe [Page 19]
INTERNET DRAFT Authentication of Binding Updates February 2001
binding updates for other nodes. These include a denial of service
attack in which the attacker sends the victim a forged binding update
for a service that the victim relies on (e.g. the domain name
service), and sets this service's care of address to a non-existent
address. The victim will be unable to contact the service at the
falsified care of address, and henceforth will be unable to make use
of the service. A variation on this attack with consequences beyond
denial of service is when the attacker sets the service's care of
address to the attackers own address, and the attacker then provides a
maliciously modified version of the service.
For this reason, it is recommended that nodes on the Internet SHOULD
use some form of authentication for binding updates. Nodes on private
intranets that use other means to exclude potential attackers MAY
accept binding updates without authentication.
10.2 Risks of unauthenticated binding acknowledgements
The consequences of forged binding acknowledgements are, in general,
less serious that those of forged binding updates. The usual
consequence of forging a binding acknowledgement is that the victim's
correspondent will fail to obtain an up-to-date binding for the
victim, the correspondent's previous binding for the victim will
expire, and the correspond will revert to sending packets via the
victim's home agent. Communications between the victim and its
correspondent will still work, but may suffer degraded performance. In
some circumstances this degradation of performance will be
sufficiently severe to constitute a denial of service attack.
Forged binding acknowledgements that appear to come from the victim's
home agent have more serious consequences than forged acknowledgements
that appear to come from other correspondent nodes. If a mobile node
is away from home, and its home agent does not have a valid binding
for it, then the mobile node will become uncontactable. As a result,
it is possible to carry out a denial of service attack on a mobile
node by blocking the binding updates it sends to its home agent and
forging the acknowledgements. Even if the attacker cannot prevent
packets getting through, they may still be able to use forged
acknowledgements to cause denial of service some of the time; if a
binding update is lost for normal reasons (not as a result of the
attack), then the forged acknowledgements will prevent it from being
retransmitted.
This attack might also make it possible to intercept packets destined
for a mobile node. Suppose that a particular network does not allow
two nodes to have the same address at the same time, but will allow
one node to take over another's address when the original user of the
address has left the network. (This assumption does not hold with many
network technologies). Then the attacker waits for a mobile node to
leave the network, takes over its old care-of address, and uses forged
binding acknowledgements and/or blocks the binding updates so that the
mobile's home agent never learns that mobile's care-of address has
changed. Packets sent to the mobile's home address will continue to be
forwarded to the old care-of address, which is now under the control
Roe [Page 20]
INTERNET DRAFT Authentication of Binding Updates February 2001
of the attacker.
One possible security policy that takes into account these
considerations is to require authenticated binding acknowledgments
from a home agent, but to accept unauthenticated binding
acknowledgments from other correspondents.
10.3 Risks of not verifying the care-of address
The BAKE/2 and CAM-DH protocols described in this memo verify that
packets sent to a mobile node's claimed care-of address reach an
entity that is willing to participate in the protocol. If this check
was not performed, a malicious mobile node could perform a denial of
service attack by asking a correspondent node to send it a high volume
stream of data, and then sending the correspondent a binding update
that redirects the stream of data to the victim of the denial of
service attack. The acknowledgements and initial sequence number of
TCP do not protect against this attack. A malicious mobile node can
send the acknowledgements for the stream of data even if it is not
actually receiving it. Unpredictable initial sequence numbers do not
prevent a malicious mobile forging acknowledgements because the mobile
sees the beginning of the stream of data (including the initial
sequence number) before it redirects it to the victim.
The BAKE/2 and CAM-DH do not authenticate the care-of address. An
attacker who can intercept packets sent to the care-of address can
complete the protocol and cause the care-of address to be flooded with
data, even if the host that actually owns the care-of address is not
willing to participate in the protocol.
An alternative method of authenticating the care-of address would have
been to derive the care-of address (as well as the home address) from
the node's public key. We did not adopt this approach, because some
subnetworks may impose constraints on the care-of addresses that can
be used.
10.4 Risks of Not Authenticating Home Agents
If a mobile node is willing to allow anyone to act as its home agent
(for example. suppose that it uses multicast to locate a suitable home
agent) then it is vulnerable to a number of attacks in which the
attacker pretends to be a home agent. For example, by acting as a
node's home agent the attack can intercept packets sent to the node (a
threat to confidentiality), and can cause denial of service. We
observe that if an attacker is in a position to carry out these
attacks, then it is also in a position to carry out other attacks of
equal or greater seriousness, for example pretending to be a router.
In environments where this is a concern, the mobile should
authenticate its home agent (and the next hop router, and many other
services it relies on). In this case, it is not sufficient to check
that the home agent's address is statistically unique; it is also
necessary to check that the address corresponds to a "good" home
agent, i.e. one that will behave in a particular way. This means that
Roe [Page 21]
INTERNET DRAFT Authentication of Binding Updates February 2001
the technique of deriving addresses from public keys is not sufficient
for authenticating the home agent to the mobile, because it only
guarantees that the address is almost certainly not being used by
anyone else. An IPSEC security association established using
certificate-based key management may not be sufficient either; it is
not enough to know that some authority has associated a particular key
with a particular IP address, as this on its own does not provide
assurance that the node at that address is a good home agent.
10.5 Denial of Service Attacks against Home Agents
Home agents are vulnerable to denial of service attacks carried out by
mobile nodes for which they are the home agent. For example, a
malicious mobile node that has two different home addresses from two
different home agents can create a routing loop by sending the first
home agent a binding update with the mobile's second home address as a
care-of address, and sending the second home agent a binding update
with the mobile's first home address as a care-of address. Packets
caught in this routing loop will eventually time out, but there is a
considerable degree of traffic amplification: for each packet that the
attacker sends into the routing loop, the home agents will have to
send and receive many packets.
Home agents can defend against these attacks in several ways. A home
agent that will only act as home agent for mobile nodes that it knows
to be trustworthy will not be vulnerable to these attacks.
References
1. Information processing systems - Open Systems Interconnection -
Specification of Basic Encoding Rules for Abstract Syntax Notation
One (ASN.1). ISO 8825, International Organization for
Standardization, 1987.
2. Secure hash standard. FIPS PUB 180-1, NIST, April 1995.
3. R. Hinden and S. Deering. IP Version 6 Addressing Architecture.
RFC 2373, July 1998.
4. P. Nikander. A Scaleable Architecture for IPv6 Address Ownership.
Internet draft, March 2001.
5. Greg O'Shea and Michael Roe. Child-proof authentication for MIPv6
(CAM). Computer Communications Review, April 2001.
11. Author's Addresses
Michael Roe
Microsoft Research Limited
7 J J Thomson Avenue
Cambridge CB3 0FB
UK
Email: mroe@microsoft.com
Tuomas Aura
Microsoft Research Limited
7 J J Thomson Avenue
Cambridge CB3 0FB
Roe [Page 22]
INTERNET DRAFT Authentication of Binding Updates February 2001
UK
Email: tuomaura@microsoft.com
Greg O'Shea
Microsoft Research Limited
7 J J Thomson Avenue
Cambridge CB3 0FB
UK
Email: gregos@microsoft.com
Jari Arkko
Oy LM Ericsson Ab
02420 Jorvas
Finland
Phone: +358 40 5079256
EMail: jari.arkko@ericsson.com
Html markup produced by rfcmarkup 1.129c, available from
https://tools.ietf.org/tools/rfcmarkup/