One document matched: draft-calhoun-mobileip-min-lat-handoff-00.txt
INTERNET DRAFT Pat R. Calhoun
Category: Standards Track Sun Microsystems, Inc.
Title: draft-calhoun-mobileip-min-lat-handoff-00.txt Haseeb Akhtar
Date: October 1999 Emad Qaddoura
Nortel Networks
Minimal Latency Secure Hand-off
Status of this Memo
This document is a submission by the mobile-ip Working Group of the
Internet Engineering Task Force (IETF). Comments should be submitted
to the MOBILE-IP@STANDARDS.NORTELNETWORKS.COM mailing list.
Distribution of this memo is unlimited.
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
The Mobile IP Working Group has been working on defining its AAA
requirements, which currently supports a Key Distribution Center
(KDC) model that issues temporary session keys for use between the
mobility nodes. In order to support real-time traffic, the Mobile IP
architecture also requires that hand-off be done in a quick and
efficient manner, and has provisions to allow new foreign agents to
retrieve the session keys from the AAA infrastructure.
Although the AAA infrastructure can assist in the hand-off process,
Calhoun, Akhtar, Qaddoura expires April 2000 [Page 1]
INTERNET DRAFT October 1999
this is largely a mobility problem, and should be dealt with in the
mobility protocol. This draft describes how the mobile node can
assist in the hand-off process by carrying the foreign agent's keying
information, providing the keys to new foreign agents while
registering. This proposal is intended to decrease the latency
involved in the hand-off process, thereby enabling seemless real time
traffic over Mobile IP networks. This draft still allows the foreign
agents to get keying information from the AAA infrastructure should
that be necessary.
Calhoun, Akhtar, Qaddoura expires April 2000 [Page 2]
INTERNET DRAFT October 1999
Table of Contents
1.0 Introduction
1.1 Copyright Statement
1.2 Requirements language
2.0 New Extensions
2.1 FA-Encrypted-MN-Key Extension
2.2 FA-Encrypted-HA-Key Extension
2.3 Previous Foreign Agent NAI Extension
3.0 Mobile Node Considerations
4.0 Foreign Agent Considerations
5.0 References
6.0 Author's Address
Calhoun, Akhtar, Qaddoura expires April 2000 [Page 3]
INTERNET DRAFT October 1999
1.0 Introduction
The Mobile IP Working Group has been working on defining its AAA
requirements, [3] which currently supports a Key Distribution Center
(KDC) model that issues temporary session keys for use between the
mobility nodes. In order to support real-time traffic, the Mobile IP
architecture also requires that hand-off be done in a quick and
efficient manner, and has provisions to allow new foreign agents to
retrieve the session keys from the AAA infrastructure.
Although the AAA infrastructure can assist in the hand-off process,
this is largely a mobility problem, and should be dealt with in the
mobility protocol. This draft describes how the mobile node can
assist in the hand-off process by carrying the foreign agent's keying
information, providing the keys to new foreign agents while
registering. This proposal is intended to decrease the latency
involved in the hand-off process, thereby enabling seemless real time
traffic over Mobile IP networks. This draft still allows the foreign
agents to get keying information from the AAA infrastructure should
that be necessary.
This specification defines new extensions that a foreign agent SHOULD
add to a Registration Reply when new keying information is received
by the AAA infrastructure. The extensions contain the session keys
that the foreign agent uses for the MN-FA and FA-HA authentication
extensions. The session keys in the extensions are encrypted so that
the mobile node cannot decrypt them, and this also enables the new
foreign agent some guarantees that the mobile node is not providing
invalid keys for the purposes of fraud.
When the mobile node moves to a new subnet, or cell, it includes the
key extensions in the Registration Request as well as the previous
foreign agent's NAI. The foreign agent can determine if it can
decrypt the keys by using the previous foreign agent's NAI. The NAI
and the SPI field SHOULD provide sufficient information for the new
foreign agent to decrypt the keys. If the foreign agent is able to
decrypt the keys, it uses the keys to authenticate the MN-FA
authentication extension in the Registration Request, which will
ensure that the keys are valid, otherwise a request to the AAA
infrastructure is required. The encrypted key extensions also include
an expiration time, which is used to ensure that old keys are not
provided to the new foreign agent.
In order for the foreign agents within a single administrative domain
to be able to decrypt their keys, a group key is recommended. This is
due to the fact that a foreign agent cannot encrypt the keys for a
specific new foreign agent since the movement pattern of the mobile
node is not known a priori. Due to the fact that the cost of
Calhoun, Akhtar, Qaddoura expires April 2000 [Page 4]
INTERNET DRAFT October 1999
changing group keys within a network is quite high, it is recommended
that the group key size used be sufficiently large (e.g. 128 bits).
The network operator SHOULD still change the group keys periodically
in order to ensure that if the key become compromised it cannot be
used. [editor's note: I am not sure about the previous two
statements, but it seemed logical to add such a warning, which has
nothing to with the spec].
1.1 Copyright Statement
Copyright (C) The Internet Society 1999. All Rights Reserved.
1.2 Requirements language
In this document, the key words "MAY", "MUST, "MUST NOT", "optional",
"recommended", "SHOULD", and "SHOULD NOT", are to be interpreted as
described in [1].
2.0 New Extensions
This section details the new extensions that an implementation MUST
support in order to conform to this specification.
2.1 FA-Encrypted-MN-Key Extension
In order to allow for the hand-off process to be done with minimal
additional latency, the FA-Encrypted-MN-Key extension allows the
mobile node to carry the foreign agent's MN-FA session key
information. The foreign agent adds this extension in a Registration
Reply that includes keying information from the AAA infrastructure.
If the mobile node detects that it is being serviced by a new foreign
agent, and this extension was received in a previous Registration
Reply, the mobile node SHOULD include this extension in the
Registration Request.
The FA-Encrypted-MN-Key Extension is defined as follows:
Calhoun, Akhtar, Qaddoura expires April 2000 [Page 5]
INTERNET DRAFT October 1999
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 | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SPI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MN-FA Session Key...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
TDB
Reserved
0
Length
The length field MUST contain at least 15
SPI
The Security Parameter Index field contains an opaque value that
is used to identify the keying material used to encrypt the
following field.
MN-FA Session Key
The MN-FA Session Key field contains an encrypted version of the
following fields:
- 32 bit timestamp field containing the time at which the
extension was created by the foreign agent
- 32 bit expiration field containing the time at which the
session keys will expire
- 32 bit SPI field that corresponds to the session key
- variable length MN-FA session key from AAA infrastructure
The SPI field is used to identify the keys necessary to decrypt
this field. The preferred transform is Triple-DES Cipher Block
Chaining mode (3DES-CBC), but other algorithms could also be used.
Calhoun, Akhtar, Qaddoura expires April 2000 [Page 6]
INTERNET DRAFT October 1999
2.2 FA-Encrypted-HA-Key Extension
In order to allow for the hand-off process to be done in an efficient
manner, the FA-Encrypted-HA-Key extension allows the mobile node to
carry the foreign agent's FA-HA session key information. The foreign
agent adds this extension in a Registration Reply that includes
keying information from the AAA infrastructure. If the mobile node
detects that it is being serviced by a new foreign agent, and this
extension was received in a previous Registration Reply, the mobile
node SHOULD include this extension in the Registration Request.
The FA-Encrypted-HA-Key Extension is defined 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SPI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FA-HA Session Key...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
TDB
Reserved
0
Length
The length field MUST contain at least 15
SPI
The Security Parameter Index field contains an opaque value that
is used to identify the keying material used to encrypt the
following field.
FA-HA Session Key
The FA-HA Session Key field contains an encrypted version of the
following fields:
Calhoun, Akhtar, Qaddoura expires April 2000 [Page 7]
INTERNET DRAFT October 1999
- 32 bit timestamp field containing the time at which the
extension was created by the foreign agent
- 32 bit expiration field containing the time at which the
session keys will expire
- 32 bit SPI field that corresponds to the session key
- variable length FA-HA session key from AAA infrastructure
The SPI field is used to identify the keys necessary to decrypt
this field. The preferred transform is Triple-DES Cipher Block
Chaining mode (3DES-CBC), but other algorithms could also be used.
2.3 Previous Foreign Agent NAI Extension
The Previous Foreign Agent NAI Extension contains the NAI of the
foreign agent that provided service to the mobile node before
entering the new service area. The mobile node MUST include this
extension if either the FA-Encrypted-MN-Key or the FA-Encrypted-HA-
Key are present in the Registration Request. The foreign agent uses
this information to identify whether it shares a common security
association with the old foreign agent that would be used to decrypt
the various session keys.
The Previous Foreign Agent NAI Extension is defined 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Previous Foreign Agent NAI...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
TDB
Length
The length field MUST contain at least 1
Previous Foreign Agent NAI
The Previous Foreign Agent NAI field contains the NAI of the
foreign agent that created the extensions defined in section 2.1
and 2.2.
Calhoun, Akhtar, Qaddoura expires April 2000 [Page 8]
INTERNET DRAFT October 1999
3.0 Mobile Node Considerations
The mobile node MAY receive the FA-Encrypted-MN-Key and/or the FA-
Encrypted-HA-Key in a Registration Reply from the foreign agent. The
extensions MUST be found prior to the MN-FA authentication extension
and after the MN-HA authentication extension. When a mobile node
moves to a new subnet, or cell, serviced by a new foreign agent, it
SHOULD include the both key and the Previous foreign agents NAI
extensions in the Registration Request. The mobile node MAY attempt
to determine whether both foreign agents belong to the same
administrative domain prior to including the extensions.
Since it is possible that the keying information provided cannot be
used by the new foreign agent, the mobile node MUST also include the
MN-AAA authentication extension in the Registration Request. This
will allow the foreign agent to send a request to the AAA
infrastructure, should that be necessary.
4.0 Foreign Agent Considerations
The foreign agent MAY receive the FA-Encrypted-HA-Key and/or the FA-
Encrypted-MN-Key within a Registration Request from a mobile node
that does not already belong to its visitors list. The foreign agent
MUST use the SPI field in the extensions in order to decrypt the
session keys that were initially derived from the AAAH.
In order for a foreign agent to be able to decrypt keys from another
foreign agent, the foreign agents MUST share a group key. Since group
keys are somewhat difficult to manage, it is imperative that they not
be compromised. Therefore, the group key used MUST be sufficiently
strong and SHOULD be used only for the encryption of the extensions
defined in this specification.
In the event that the foreign agent is not able to decrypt the
session keys, it SHOULD issue a request to the AAA infrastructure.
The AAA infrastructure can then either issues new session keys or
return the old session keys.
5.0 References
[1] Bradner, "Key words for use in RFCs to Indicate Requirements
Levels", BCP 14, RFC 2119, March 1997.
[2] G. Dommety, S. Glass, T. Hiller, S. Jacobs, B. Patil,
C. Perkins, "Mobile IP Authentication, Authorization, and
Accounting Requirements", draft-ietf-aaa-mobile-ip-req-00.txt
Calhoun, Akhtar, Qaddoura expires April 2000 [Page 9]
INTERNET DRAFT October 1999
IETF Work in Progress, April 1999.
[3] US National Bureau of Standards, "Data Encryption Standard",
Federal Information Processing Standard (FIPS) Publication
46, January 1977.
[4] US National Bureau of Standards, "Data Encryption Standard",
Federal Information Processing Standard (FIPS) Publication
[5] US National Bureau of Standards, "Guidelines for Implement-
ing and Using the Data Encryption Standard", Federal Infor-
mation Processing Standard (FIPS) Publication 74, April
1981.
[6] US National Bureau of Standards, "DES Modes of Operation"
Federal Information Processing Standard (FIPS) Publication
81, December 1980.
[7] Schneier, B., "Applied Cryptography Second Edition", John
Wiley & Sons, New York, NY, 1995. ISBN 0-471-12845-7.
Calhoun, Akhtar, Qaddoura expires April 2000 [Page 10]
INTERNET DRAFT October 1999
6.0 Author's Address
Questions about this memo can be directed to:
Pat R. Calhoun
Sun Laboratories, Network and Security
Sun Microsystems, Inc.
15 Network Circle
Menlo Park, California, 94025
USA
Phone: 1-650-786-7733
Fax: 1-650-786-6445
E-mail: pcalhoun@eng.sun.com
Haseeb Akhtar
Wireless Technology Labs
Nortel Networks
2221 Lakeside Blvd.
Richardson, TX 75082-4399
USA
Phone: 1-972-684-8850
E-Mail: haseeb@nortelnetworks.com
Emad Qaddoura
Wireless Technology Labs
Nortel Networks
2221 Lakeside Blvd.
Richardson, TX 75082-4399
USA
Phone: 1-972-684-2705
E-Mail: emadq@nortelnetworks.com
Calhoun, Akhtar, Qaddoura expires April 2000 [Page 11]
| PAFTECH AB 2003-2026 | 2026-04-23 04:24:37 |