INTERNET-DRAFT Binding Update Security Michael Thomas
Cisco Systems
2 Nov 2001
Binding Updates Security
draft-thomas-mobileip-bu-sec-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 provides a mechanism for mobile IPv6 nodes to use standard
[IPSEC] mechanisms (both [AH] and [ESP]) to authenticate and
authorize mobile IP route optmization messages which provide strong
crypotographic authentication as well as protection from man in the
middle attacks. This protection can be used both between home agents,
and correspondent nodes. Given the lack of a universal authentication
and authorization infrastructure, this memo also provides a weaker
alternative to strong cryptographic based authentication. This
mechanism trades off protection from some attacks, such as the man in
the middle attack, on the observation that the routing system
inherently provides a man in the middle opportunity. Thus it it is
acceptible to provide routing optimization mechanisms so long as they
Thomas draft-thomas-mobileip-bu-sec-00.txt [Page 1]
INTERNET-DRAFT Binding Update Security November 2001
are no less secure than the underlying infrastructure. This memo uses
a simple return routability test to provide that weak mechanism.
1. Introduction
Previous drafts of [MOBILEIPV6] recommended use of [IPSEC] and [AH]
to secure binding updates, both to the mobile node's home agent as
well as to correspondent nodes. Two major problems were found with
this recommendation:
o An assumption was made that the authentication domain for bind-
ing updates would be the same as the underlying packet's authen-
tication domain. This is not necessarily the case, and the
current [IPSEC] selector mechanisms do not provide sufficient
flexibility to support two different authentication domains
within a single packet.
o An assumption was made that IPsec security association would
scale not only to the domain of home agent/mobile nodes, but to
the any-to-any nature of mobile node/correspondent node communi-
cation. This presupposes that there is a global PKI, and more
specifically a global PKI which authenticates and authorizes
nodes to change their global routability. These assumptions are
infeasible and unattractive respectively.
Thus mobile IP requires both a strong authentication and author-
ization mechanism where it is appropriate, and a weaker variety
where it is not. This memo provides those two mechanisms in two
ways:
o Strong authentication is provided by using IPsec, but by modify-
ing [MOBILEIPV6]'s mechanisms to fit within the selector mechan-
isms defined in [IPSEC]. This memo also provides a means of
using both transport [AH] as well as [ESP].
o Weaker authentication is provided using a basic return routabil-
ity test. That is, if a node can respond to a challenge at the
home address it claims to be at, it is either very likely to be
the node in question, or another node which could have attacked
it by virtue of the fact that strong authentication wasn't used
to eliminate man in the middle attacks.
Both of these methods provide a means for the nodes receiving
binding updates and home address options to determine whether
they should accept the new binding or substitute the home
Thomas draft-thomas-mobileip-bu-sec-00.txt [Page 2]
INTERNET-DRAFT Binding Update Security November 2001
address for the source address in the IP header. If neither of
these methods are available, the node MUST NOT accept the new
binding, or purported home address.
2. Use of IPsec for Strong Authentiction and Authorization
The selector mechanism of [IPSEC] is not prepared to deal with dif-
ferent security policies within a single IP packet. Therefore, the
current mechanism of piggybacking binding messages is incompatible
with [IPSEC]. This memo deprecates that mechanism and instead uses a
separate UDP based protocol on well known port [XXX -- get from
IANA]. Thus, standard IPsec ID selctors may be used to select dif-
ferent traffic flows or aggregate them together depending on a site's
particular security policy as with standard [IPSEC].
In addition, this memo relaxes the restriction of [AH] only by expli-
citly including the home address into the binding update message.
This allows [ESP] to also be used which is advantageous in situations
where there is a common security policy for binding updates and other
traffic between the nodes, but privacy is also desired. See section 5
for the new binding update format.
2.1. IPsec Applicability
It is expected that keying within the limited scope of mobile nodes
and nodes acting as home agents is feasible with standard key distri-
bution mechanism such as [IKE], [KINK] and even pre-shared keys. Thus
IPsec MUST be used between mobile nodes and any node acting as a home
agent on the mobile node's behalf. The ability to use IPSEC between
mobile nodes and correspondent nodes MUST be implemented by the
mobile node, and SHOULD be implemented by correspondent nodes.
3. Weak Authentication and Authorization
Given the tradeoff of PKI scalability vs man in the middle attacks,
it was deemed that authentication and authorization of route optimi-
zation which is no worse than the inherent in the current Internet
was acceptible so long as the threats are not appreciably worse than
current Internet nodes which do not use strong authentication.
The current Internet relies on transitive trust in the routing system
and explicitly discounts the man in the middle attack against the
routing system. As such, it is take as a given that if a packet is
destined toward a given location on the net, the routing system --
Thomas draft-thomas-mobileip-bu-sec-00.txt [Page 3]
INTERNET-DRAFT Binding Update Security November 2001
modulo configuration errors and other failures -- will make a best
effort to forward the packet to its destination given the current
topology of the net.
Mobile IP can take advantage of that fact to enforce the property
that if a datagram from an unknown node desiring route optmization
can demonstrate that it exists at the topologically correct address
(as determined by the current state of the routing system), there is
reasonable assurance that it is, in fact, the rightful owner of that
IP address at that point in time. The astute reader will no doubt
point out that attacks can come from not only middle of the network,
but also at the edges as well. This is true, however, the question is
whether those attacks are unique to mobility, or whether they exist
in non-mobile environments as well. As far as can be determined, they
are not; things like ARP hijacking, etc are still avenues of attack,
and shared media present many, many more opportunities than just
hijacking of route optimization messages. Thus we can relegate these
attacks to the general list of protocols and best common practices
required when deploying a given access media.
3.1. Return Routability Test
Thus the primary threat of route optimization hijacking can be miti-
gated by a simple return routability test. The return routability
test at its heart is a challenge by the correspondent node to the
mobile node to echo a large, hard to guess number. This memo recom-
mends a 32 bit number which is in line with [TCP] and its initial
segment sequence for ACK and SEQ which is also protected weakly using
this mechanism. Thus, the test is performed as follows:
Thomas draft-thomas-mobileip-bu-sec-00.txt [Page 4]
INTERNET-DRAFT Binding Update Security November 2001
MN HA CN
1) BU+Nm------------------------------------>
The mobile node sends a binding update. Nonce
Nc MUST be set to zero.
2) <----------------------<----------BR+Nc+Nm
Since Nc is set to zero, the correspondent
node challenges it with a nonce, Nc; note
that the challenge MUST be sent to the home
address of the mobile node.
3) BU+Nc+Nm--------------------------------->
The mobile node creates a new binding update with
the nonce Nc in it; the CN can now process the binding
update upon verification of nonce Nc.
[ 4) <---------------------------------BA+Nc+Nm ]
[ ]
[ The correspondent node sends a binding acknowledgement ]
[ to the mobile node with its nonce Nm repeated. ]
Operation for a correspondent node initated binding request follows
similar rules, except that the mobile node MUST process a binding
request with a zero Nc.
3.2. Stateless Operation
As with [TCP], there is a potential denial of service attack if a
malicious node floods the correspondent node with forged binding
updates, the correspondent node may consume resources, potentially
exhausting state or resulting in the eviction of legitimate binding
cache entries. In addition to the need of a nonce for binding
updates, mobile nodes may want the correspondent node to send a bind-
ing acknowledgment. To verify incoming binding acknowledgments, the
mobile node must also supply a nonce.
To prevent these attacks, a slightly modified version of [SYN-
COOKIES] is used. In fact this text is a slightly modified and refor-
mated version of [SYN-COOKIES].
The implementation MUST maintain two (constant) secret keys, sec1 and
sec2 which are generated at boot time and not divulged. It also MUST
Thomas draft-thomas-mobileip-bu-sec-00.txt [Page 5]
INTERNET-DRAFT Binding Update Security November 2001
maintain a counter that increases slowly over time and never repeats,
such as ``number of seconds since 1970, shifted right 6 bits.'' It
MUST also keep track of when the last time it generated a binding
message. To create a MN-SEQ or CN-SEQ, it obtains its source
address and source port, and the destination address and port, and
zero's its (MN|CN)-SEQ and computes the following:
z = MD5(sec1|saddr|sport|haddr|daddr|dport|sec1)
+ (MN-SEQ|CN-SEQ)
+ (counter << 27)
+ (MD5(sec2|counter|saddr|sport|haddr|daddr|dport|sec2)
% (1 << 27))
and sets ``last overflow time'' to the current time.
To process an incoming sequence number the node MUST:
1) If the ``last overflow time'' is earlier than a few minutes ago,
drop the packet.
2) The node MUST then recompute z as above, for each of the
counters that could have been used in the last few minutes (say,
the last four counters), and then compare the results to the the
sequence number in the packet. If there is a match, the binding
message can be accepted as legitimate. If none of match, the
node MUST drop the packet.
4. Selecting Weak/Strong Authentication
A mobile node MUST be prepared to accept either strong or weak
authentication from a correspondent node. It MUST NOT accept binding
operations with weak authentication requests from a home agent, and
SHOULD silent discard the request. Even when a security association
between the mobile node and correspondent node exists, the mobile
node MUST prepare the weak authentication fields as well. Correspon-
dent nodes SHOULD accept binding updates if the exchange was pro-
tected by IPsec with either an explicit policy selector, or a wild-
carded policy selector. This behavior MAY be overridden by by policy
of the correspondent node, in which case the weak authentication test
will also take place.
Even if a mobile node can authenticate to an IPsec peer, IPsec policy
may not be sufficiently fine to authorize the rebinding of home
addresses claimed by the mobile node. This is not a problem for home
agents which actually subtends the home prefix, but correspondent
nodes and possibly remote foreign agents such as [HMIP], may not have
Thomas draft-thomas-mobileip-bu-sec-00.txt [Page 6]
INTERNET-DRAFT Binding Update Security November 2001
the same implicit knowledge of any relationship between the presented
credentials and the home address that the mobile node is trying to
rebind. While this information may be available due to configured
policy, or authorization attributes in the credentials exchanged in
the key distribution protocol, correspondent nodes or nodes acting as
a home agent MUST NOT accept bindings based solely on the existence
of an IPsec security association. Thus, the security policy executed
during the establishment of the security MUST explicitly have author-
ization for the Home Address that the mobile node is trying to
rebind. If explicit authorization is not available, correspondent
nodes MUST perform the weak test, albeit protected by IPsec, to
determine whether the node is authorized to change the binding for a
given binding unless the credentials or pre-configuration explicitly
authorize a node to change the binding of a given home address. Also:
nodes acting as home agents MUST reject any binding updates for which
they cannot positively correlate the home address being rebound and
the security policy which instantiated the security association.
5. Message Formats
The following are the new definitions of the binding messages. Note:
unless otherwise noted out, the fields with the same name in
[MOBILEIPV6] have identical functionality.
Thomas draft-thomas-mobileip-bu-sec-00.txt [Page 7]
INTERNET-DRAFT Binding Update Security November 2001
5.1. Binding Update Message
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option Type | Option Length |A|H|R|D| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Home Address +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MN-Seq |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CN-Seq |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sub-Options...
+-+-+-+-+-+-+-+-+-+-+-+-
Options
Home-Address
The home address of the mobile node.
MN-SEQ
The hashed sequence number which is generated by the mobile
node.
CN-SEQ
The hashed sequence number which is generated by the
correspondent node.
Thomas draft-thomas-mobileip-bu-sec-00.txt [Page 8]
INTERNET-DRAFT Binding Update Security November 2001
5.2. Binding Acknowledgment Message
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option Type | Option Length | Status | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Refresh |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MN-Seq |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CN-Seq |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sub-Options...
+-+-+-+-+-+-+-+-+-+-+-+-
MN-SEQ
The hashed sequence number which is generated by the mobile
node.
CN-SEQ
The hashed sequence number which is generated by the
correspondent node.
Thomas draft-thomas-mobileip-bu-sec-00.txt [Page 9]
INTERNET-DRAFT Binding Update Security November 2001
5.3. Binding Request Message
The Binding Request option is encoded in type-length-value (TLV)
format as follows:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option Type | Option Length | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MN-Seq |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CN-Seq |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sub-Options...
+-+-+-+-+-+-+-+-+-+-+-+-
MN-SEQ
The hashed sequence number which is generated by the mobile
node.
CN-SEQ
The hashed sequence number which is generated by the
correspondent node.
6. Future Optimizations
This memo purposefully omits any optimization of the weak keying
mechanism's three way handshake. Several optimizations have been pro-
posed, and this section details how this memo could interoperate with
future standards which wanted to allow for optimization.
6.1. Two Message Weak Exchanges
This memo recommends two mechanisms for authenticating and authoriz-
ing binding updates: strong authentication using IPsec, and a weaker
version relying on return routability. Depending on emperical evi-
dence, it may be desirable to optimize the three way handshake on
subsequent binding updates. This could be achieved in at least two
ways:
1) Use public key cryptography to create a shared secret between
Thomas draft-thomas-mobileip-bu-sec-00.txt [Page 10]
INTERNET-DRAFT Binding Update Security November 2001
the mobile and correspondent nodes, and sign each subsequent
binding message with that symmetric key. Addition of this
feature could be accomplished by adding a new sub-option(s) to
carry the Diffie Hellman exchange, as well as the signature of
the binding mechanism.
2) Create and maintain state after the initial handshake by using a
TCP-like scheme with the sequence numbers in this draft. The
current mechanism could be extended to use the initial exchange
in an analogous way as TCP's ISS, and subsequent exchanges could
monitonically increment the sequence numbers.
Both have their plusses and minuses: (1) is somewhat safer, but
is prone to attacks and adds a fair amount of CPU complexity.
(2) is more straightforward and certainly well known given TCP,
but doesn't provide the security property that [PBK] proposes.
6.2. Proxying
[COOKIES] proposes leveraging the necessary home agent security asso-
ciation to allow the home agent to act as a proxy for the mobile
node. This memo doesn't appear to prevent that possibility as use of
anycast addressing would still be possible.
6.3. Mobile Prefix Route Optimization
There is some interest in securing not only mobile hosts, but mobile
routers. A likely avenue to secure the weak variety is to send the
binding request to the anycast address of the router which summarizes
the prefix for which the mobile node is trying to change the binding.
This memo, again, does not preclude this.
7. Security Considerations
This memo outlines many of the security considerations surrounding
the appropriate authentication and authorization of binding updates.
In particular this memo's use of weak authentication is subject to
potential snooping and active man in the middle attacks due to its
compromise of strong authentication for scalability. This memo also
uses [SYN-COOKIES] in a nearly unchanged form. It should be discussed
further whether the guessing space is, in fact, too small as [SYN-
COOKIES] alludes to. Thus the suggestion of a 32 bit guessing space
is intended to be an initial suggestion for the ultimate solution.
Another area of concern is lousy random number generators. This prob-
lem is obviously of concern for many other things including TCP's ISS
creation, so is not unique to this memo.
Thomas draft-thomas-mobileip-bu-sec-00.txt [Page 11]
INTERNET-DRAFT Binding Update Security November 2001
References
[MOBILEIPV6]
Mobile IP Working Group, D. Johnson, C. Perkins, "Mobility Sup-
port in IPv6" draft-ietf-mobileip-ipv6-15.txt
[IPSEC]
The IPsec Working Group, S. Kent, R. Atkinson, "Security Archi-
tecture 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
[ISAKMP]
Maughhan, D., Schertler, M., Schneider, M., and J. Turner,
"Internet Security Association and Key Management Protocol
(ISAKMP)", RFC 2408, November 1998.
[IPDOI]
Piper, D., "The Internet IP Security Domain Of Interpretation
for ISAKMP", RFC 2407, November 1998.
[ESP]S. Kent, R. Atkinson, "IP Encapsulating Security Payload (ESP)",
RFC 2406, November 1998
[AH] S. Kent, R. Atkinson, "IP Authentication Header", RFC 2402,
November 1998
[IPV6]S. Deering, R. Hinden, "Internet Protocol, Version 6 (IPv6)
Specification", RFC 2460, December 1998
[SYN-COOKIES]
Bernstein, D.J., Schenk, E. "SYN Cookies",
http://cr.yp.to/syncookies.html
[HMIP]Mobile IP Working Group, H. Soliman, C. Castelluccia, K. El-
Malki, L. Bellier, "Hierarchical MIPv6 mobility management
(HMIPv6)", <draft-ietf-mobileip-hmipv6-04.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
Thomas draft-thomas-mobileip-bu-sec-00.txt [Page 12]
INTERNET-DRAFT Binding Update Security November 2001
Thomas draft-thomas-mobileip-bu-sec-00.txt [Page 13]