Internet DRAFT - draft-kempf-mobopts-handover-key
draft-kempf-mobopts-handover-key
James Kempf
Internet Draft DoCoMo Labs USA
Document: draft-kempf-mobopts-handover-key-01.txt Rajeev Koodli
Nokia Research
Center
Expires: January, 2006 July, 2005
Bootstrapping a Symmetric IPv6 Handover Key from SEND
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.
Copyright Notice
Copyright (C) The Internet Society (2005). All Rights Reserved.
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
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
This Internet-Draft will expire on November 16, 2005.
Copyright Notice
Copyright (C) The Internet Society (2005). All Rights Reserved.
Abstract
Multiple IPv6 handover optimization protocols (for example, Fast Mobile
IPv6 and Context Transfer Protocol) require an Access Router to verify
that signaling received to perform an IP handover operation originated
from a Mobile Node having authorization to claim a particular address
on the Access Router's wireless subnet. In this document, a method for
securing such signaling is defined. The method utilizes a secret key
sent from the Access Router to the Mobile Node prior to handover,
encrypted with an RSA public key that the Mobile Node used to generate
its Cryptographically Generated Address. The ability of the Mobile Node
to decrypt the secret key verifies its possession of the private key
corresponding to the public key used to generate the address. This
allows the Mobile Node to use the secret key to sign and authorize
signaling causing changes affecting traffic to and from that address.
The use of symmetric cryptography avoids the time consuming public key
operation associated with using the RSA key directly during
performance-sensitive IP subnet handover.
Table of Contents
Kempf Expires January, 2006 [Page 1]
Internet Draft FMIP Security July, 2005
1.0 Introduction.....................................................2
2.0 IP Handover Signaling Protocols Requiring Authorization..........2
3.0 Brief Review of SEND.............................................3
4.0 Handover Key Generation and Use..................................4
5.0 Handover Key Option..............................................6
6.0 Security Considerations..........................................6
7.0 IANA Considerations..............................................6
8.0 Normative References.............................................6
9.0 Informative References...........................................7
10.0 Author Information...............................................7
11.0 Full Copyright Statement.........................................7
12.0 Intellectual Property............................................8
13.0 Acknowledgement..................................................8
1.0 Introduction
In IPv6 handover optimization, certain operations to a Mobile Node's
(MN's) previous Access Router (AR) during IPv6 subnet handover require
signaling from the MN undergoing handover. The signaling requests that
the AR perform operations affecting traffic to and from the MN's
previous address on the AR's wireless subnet. These operations are done
to ensure that the MN's traffic continues to be delivered while the MN
is changing its Mobile IP home address. In order to avoid masquerading
attacks, such signaling needs to be secured so that the AR can verify
the authorization of the sender to perform operations affecting the
address.
In this document, a lightweight mechanism is defined by which such
operations can be secured. The mechanism utilizes a shared handover key
sent from the AR to the MN prior to handover, encrypted with the public
key utilized by the MN to generate a Cryptographically Generated
Address (CGA) (called here the CGA public key) in the SEND protocol
[SEND]. In SEND, the CGA key is used to authorize possession of an
address, and, thereby, to perform operations associated with the
address. The connection between the address and the CGA public/private
key pair is called the key pair's CGA property. The shared handover key
derives its authorization potential from the ability of the MN to
decrypt the handover key using the CGA private key.
Handover keys are an instantiation of the purpose built key
architectural principle [PBK].
2.0 IP Handover Signaling Protocols Requiring Authorization
2.1 FMIPv6
The FMIPv6 protocol [FMIP] defines a message, called Fast Binding
Update (FBU), by which a MN can quickly signal its new care-of address
to its previous AR before or after a handover between IPv6 subnets. The
previous AR then constructs a tunnel to the new care-of address, so
that traffic packets for the MN delivered to the old care-of address
Kempf Expires January 2006 [Page 2]
Internet Draft FMIP Security July, 2005
flow to the new care-of address while the MN changes its home address
to care-of address binding at the Home Agent, and while the MN performs
route optimization with Correspondent Nodes, both time consuming
operations. Use of FMIPv6 reduces the number of packets dropped during
IP subnet handover.
In Section 8 of [FMIP], security threats to FMIPv6 signaling are
identified. Unless the previous AR can authenticate that the FBU comes
from a MN authorized to change the routing for the old care-of address,
it is possible for an attacker to redirect a victim MN's traffic, for
purposes of denial of service or to steal the victim's traffic. Section
8 of [FMIP] specifies no mechanism by which the threat can be
countered, leaving the mechanism open for further study.
2.2 CTP
The Seamoby Context Transfer Protocol (CTP) [CTP] defines a message,
called Context Transfer Activate Request (CTAR) which a MN sends to its
new AR (and can send to its previous AR) to start context transfer from
the previous AR to the new AR. Context transfers are used to speed
establishing routing treatments (such as QoS) that were originally
established on the previous AR, and therefore involve routing
properties associated with a particular address.
The CTAR message contains an authorization token field that is
calculated using a shared key between the MN and AR. Section 2.5.1 of
[CTP] describes how to calculate the authorization token, but the CTP
document does not specify how to establish the shared key.
3.0 Brief Review of SEND
While the extent of its ultimate deployment is as yet unclear, it seems
likely that the SEND protocol [SEND] may ultimately be widely deployed
on mobile, wireless IPv6 networks. SEND protects against a variety of
threats to local link address resolution (also known as Neighbor
Discovery) and last hop router (AR) discovery in IPv6 [RFC3756]. These
threats are not exclusive to wireless networks, but they generally are
easier to mount on wireless networks because the link between the
access point and MN can't be physically secured.
SEND utilizes CGAs in order to secure Neighbor Discovery signaling
[CGA]. Briefly, a CGA is formed by taking the IPv6 subnet prefix for a
node's subnet and combining it with an interface identifier suffix
formed as the hash of the node's public key. The public key is used to
sign a Neighbor Advertisement message sent to resolve the link layer
address to the IPv6 address. The combination of the CGA and the
signature on the Neighbor Advertisement proves to a receiving node the
sender's authorization to claim the address. The node may
opportunistically generate one or several keys specifically for SEND,
or it may use a certified key that it distributes more widely. In any
case, this document refers to the public key/private key pair used for
CGA generation as the CGA key pair, and the authorization to claim a
CGA as the key's CGA property.
Kempf Expires January 2006 [Page 3]
Internet Draft FMIP Security July, 2005
4.0 Handover Key Generation and Use
4.1 Mobile Node Considerations
At some time prior to handover, the MN sends an IPv6 Router
Solicitation (RS) [RFC2461] exactly as specified for IPv6 Router
Discovery. The CGA for the MN is the source address on the packet, and
the MN includes the SEND CGA Option and SEND Signature Option with the
packet, as specified in [SEND]. Receiving routers reply directly to the
CGA with a Router Advertisement (RA) and include a Handover Key Option
(defined here in Section 5.0) containing the encrypted, shared handover
key. The MN chooses an AR, decrypts the handover key with its CGA
private key, and stores the associated handover key for later use.
The lifetime and size of the handover key depend on the lifetime of the
address and the application. The handover key lifetime depends on the
lifetime of the CGA key [CGA], which, in turn, is determined by the
lifetime of the address. The CGA key and handover key should be renewed
when the preferred lifetime of the address expires and must be renewed
if the valid lifetime of the address expires [RFC2462]. The lifetime
also depends on the strength of the key. For MIPv6 (and thus FMIPv6),
the usual length of Kbm for return routability purposes is 20 octets
[MIP6]. For CTP, the key length is variable [CTP], but should also be
on the order of 16 to 20 octets, to prevent guessing attacks.
When a handover occurs or is about to occur and the MN needs to signal
the previous AR, the MN generates a message authentication code using
the handover key. Exactly how the message authentication code is
generated depends on the protocol. For the specific examples given in
Section 2.0:
o For FMIPv6, the message authentication code is generated as a
Binding Authorization Data Mobility Option for the FBU, as
described in Section 6.2.7 of [MIP6], with the handover key used
as Kbm. The MN includes an IP Address Mobility Option with the
previous care-of CGA, to identify the key.
o For CTP, the authorization token is generated using the handover
key as Key in the token calculation algorithm described in Section
2.5.1 of [CTP].
4.2 Access Router Considerations
When an AR capable of handover optimization receives a RS from a MN
including a CGA Option and a Signature Option, and the source address
is an IPv6 global unicast address, the AR verifies the signature and
CGA as described in [SEND]. If the signature and CGA verify, the AR
then constructs a shared handover key and encrypts the handover key
with the MN's CGA public key. The AR inserts the encrypted handover key
into a Handover Key Option and attaches the Handover Key Option to the
Router Advertisement (RA), which is then unicast back to the CGA. The
handover key is stored by the AR, indexed by the CGA, for future use.
Unless the MN renews the key with another RS, the AR discards the
handover key when the CGA's valid lifetime expires.
Kempf Expires January 2006 [Page 4]
Internet Draft FMIP Security July, 2005
When the AR receives an IPv6 handover optimization signaling message
associated with a particular address on the wireless link and
containing a message authentication code, the AR looks up the handover
key using the address. If a match is found, the AR utilizes the
handover key to verify the message authentication code. For the
specific examples given in Section 2.0:
o For FMIPv6, the Binding Authorization Data Mobility Option for the
FBU contains the message authentication code, as described in
Section 6.2.7 of [MIP6]. The AR obtains the CGA for the MN's
previous care-of address from the IP Address Mobility Option in
the FBU, and uses that address to look up the handover key. The AR
utilizes the handover key as Kbm to verify the message
authentication code.
o For CTP, the previous AR includes the handover key associated with
the MN's previous IP address when it sends a Predictive Context
Transfer Data message (PCTD), described in Section 2.5.3 of [CTP].
Both the previous AR and new AR additionally use the handover key
to verify the authorization token included in a CTAR from the MN
or CT-Req message from the new AR.
4.3 Possible Alternatives and Their Drawbacks
One alternative mechanism is to use the CGA key directly, by signing
the optimization protocol messages with an RSA-generated signature
using the CGA key. This mechanism has a technical drawback when applied
to the handover optimization protocols. Because RSA is a public key
algorithm, verification of the signature is more time consuming than
for a shared key signature. Since the handover optimization protocols
are primarily for performance optimization, it seems appropriate to
design the security mechanism in a way that minimizes the amount of
time required for processing during handover.
Additionally, the handover optimization protocols typically define
their verification signatures as message authentication codes using
shared keys. Use of a public key signature would require addition of
new verification algorithms to the handover optimization protocols,
rather than simply using the existing algorithms, so a shared key has a
higher degree of backwards compatibility.
An alternative mechanism that uses shared keys but a different key
provisioning mechanism is Diffie-Hellman key agreement [RFC2631]. The
drawback of Diffie-Hellman key agreement is that it is subject to man-
in-the-middle attacks in the absence of certified keys. Provisioning
end hosts with certificates is a difficult deployment challenge that
has yet to become widespread. In contrast, the CGA key, on which the
handover key is based, requires no certificate. The handover key
mechanism described in this document establishes the key's
authorization potential via the CGA property of the CGA key pair used
to encrypt and decrypt the handover key, thereby tying it definitively
to the address.
Kempf Expires January 2006 [Page 5]
Internet Draft FMIP Security July, 2005
5.0 Handover Key Option
The Handover Key Option is a standard IPv6 Neighbor Discovery option in
TLV format.
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 | Length | Key Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Encrypted Handover Key . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Fields:
Type: To be assigned by IANA.
Length: The length of the option in units of 8 octets, including
the type and length fields.
Key Length: Length of the encrypted handover key, in units of
octets.
Encrypted Key: The encrypted handover key.
The option is padded to an 8 octet boundary, as required for IPv6
Neighbor Discovery Protocol options.
6.0 Security Considerations
This document describes a security protocol for the IPv6 handover
optimization protocols. The protocol utilizes the CGA key of SEND to
bootstrap a shared key for authorizing changes due to handover
associated with the MN's former address on the wireless interface of
the AR. General security considerations involving CGAs apply to the
protocol described in this document, see [CGA] for a discussion of
security considerations around CGAs.
7.0 IANA Considerations
A new IPv6 Neighbor Discovery option, the Handover Key Option, is
defined, and requires a type code from IANA.
8.0 Normative References
[SEND] Arkko, J., et. al., "SEcure Neighbor Discovery (SEND)", Internet
Draft, work in progress.
[RFC3756] Nikander, P., editor, Kempf, J., and Nordmark, E., " IPv6
Neighbor Discovery (ND) Trust Models and Threats", RFC 3756,
May 2004.
Kempf Expires January 2006 [Page 6]
Internet Draft FMIP Security July, 2005
[CGA] Aura, T., "Cryptographically Generated Addresses", Internet Draft,
work in progress.
[RFC2461] Narten, T., and Nordmark, E., "Neighbor Discovery for IP
version 6 (IPv6)", RFC 2461, December 1998.
[RFC2462] Thomas, S., and Narten, T., "IPv6 Stateless Address
Autoconfiguration", RFC 2462, December 1998.
9.0 Informative References
[PBK] Bradner, S., Mankin, A., and Schiller, J., "A Framework for
Purpose-Built Keys (PBK)", Internet Draft, work in progress.
[FMIP] Koodli, R., editor, "Fast Handovers for Mobile IPv6", Internet
Draft, work in progress.
[CTP] Loughney, J., editor, et. al. "Context Transfer Protocol",
Internet Draft, work in progress.
[MIP6] Johnson, D., Perkins, C., and Arkko, J., "Mobility Support in
IPv6", Internet Draft, work in progress.
[RFC2631] Rescorla, E., "Diffie-Hellman Key Agreement", RFC 2631, June
1999.
10.0 Author Information
James Kempf Phone: +1 408 451 4711
DoCoMo Labs USA Email: kempf@docomolabs-usa.com
181 Metro Drive
Suite 300
San Jose, CA
95110
USA
Rajeev Koodli Phone: +1 650 625 2359
Nokia Research Center Fax: +1 650 625 2502
313 Fairchild Drive Email: Rajeev.Koodli@nokia.com
Mountain View, CA
94043
USA
Kempf Expires January 2006 [Page 7]
Internet Draft FMIP Security July, 2005
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org. By submitting this Internet-Draft, I certify that
any applicable patent or other IPR claims of which I am aware have
been disclosed, and any of which I become aware will be disclosed, in
accordance with RFC 3668.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2004). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Kempf Expires January 2006 [Page 8]
