One document matched: draft-calhoun-mobileip-min-lat-handoff-01.txt
Differences from 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-01.txt Haseeb Akhtar
Date: February 2000 Emad Qaddoura
Expires: July 2000 Nortel Networks
N. Asokan
Nokia Research Center
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.
Calhoun, Akhtar, Qaddoura, Asokan [Page 1]
INTERNET DRAFT February 2000
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 (within the
same administrative domain) while registering. This proposal is
intended to decrease the latency involved in the hand-off process,
thereby enabling seamless 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.
At present, authentication in Mobile IP uses shared key cryptography.
However, this proposal is general enough to be able to accommodate
authentication based on public key digital signatures if and when it
becomes feasible.
Calhoun, Akhtar, Qaddoura, Asokan [Page 2]
INTERNET DRAFT February 2000
Table of Contents
1.0 Introduction
1.1 Copyright Statement
1.2 Requirements language
2.0 MN-Key-Token Extension
3.0 Generalized FA-HA Key Reply Extension
4.0 HA-Key-Token Extension
5.0 Token Issuer's NAI Extension
6.0 Mobile Node Considerations
7.0 Foreign Agent Considerations
8.0 References
9.0 Authors' Addresses
Calhoun, Akhtar, Qaddoura, Asokan [Page 3]
INTERNET DRAFT February 2000
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 (within the
same administrative domain) while registering. This proposal is
intended to decrease the latency involved in the hand-off process,
thereby enabling seamless 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 authentication
tokens from which the foreign agent can extract keys necessary to
verify the MN-FA and FA-HA authentication extensions. In the case of
shared key based authentication, the extensions consist of session
keys which 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.
In the case of digital signature based authentication, the extensions
consist of public signature verification keys along with certificates
vouching for their authenticity and validity.
The entity which constructs these authentication tokens is called a
"token issuer". The token issuer is trusted by all foreign agents in
the visited administrative domain: for example, it could be the AAA
server in the domain, or the root foreign agent in a foreign agent
hierachy, or the previous foreign agent. The foreign agent MAY also
add a token-issuer NAI extension (Section 5.0) to the Registration
Reply. When the mobile node moves to a new subnet, or cell, within
the same administrative domain, it includes the token extensions in
the Registration Request as well as the token issuer's NAI.
The foreign agent can determine if it can extract the keys by using
the token issuer's NAI. The NAI and the SPI field SHOULD provide
sufficient information for the new foreign agent to extract the keys.
If the foreign agent is able to extract the keys, it uses the keys to
Calhoun, Akhtar, Qaddoura, Asokan [Page 4]
INTERNET DRAFT February 2000
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 authentication
token extensions also include an expiration time, which is used to
ensure that old keys are not provided to the new foreign agent.
In the case of authentication based on shared keys, all foreign
agents within a single administrative domain must be able to extract
each other's keys, and therefore 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 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.
In the case of authentication based on digital signatures, the
logistical difficulties are less severe. All FAs need to be
configured with an authentic copy of the token issuer's public
signature verification key. This proposal does not impose any
additional requirements on the size and update frequency on this key
than is usual due to other considerations.
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 MN-Key-Token Extension
In order to allow for the hand-off process to be done with minimal
additional latency, the MN-Key-Token Extension allows the mobile node
to securely carry the key necessary for the foreign agent to verify
the MN-FA authentication extension. 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 belonging to the same
administrative domain as the old FA, and this extension was received
in a previous Registration Reply, the mobile node SHOULD include this
Calhoun, Akhtar, Qaddoura, Asokan [Page 5]
INTERNET DRAFT February 2000
extension in the Registration Request. The Mobile Node can verify
whether foreign agents belong to the same administrative domain using
the advertisement Foreign Agent NAI extension, defined in [15].
The MN-Key-Token Extension is subtype 8 of the Generalized MN-FA Key
Reply Extension [14] and 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 | Subtype | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FA SPI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MN SPI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Authenticated MN-FA key token...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: The MN-Key-Token Subtype-Specific Data
FA SPI
A 32-bit opaque value, indicating the SPI that the foreign agent
must use to determine the algorithm to use for recovering the MN
security information.
MN SPI
A 32-bit opaque value, which the foreign agent MUST use to index
all the necessary information recovered from the MN security
information after it is decoded.
Authenticated MN-FA key token
The Authenticated MN-FA key token field is opaque to the mobile
node, but is used by a foreign agent in the same administrative
domain as the token-issuer to extract an authenticated key that
can be used to verify MA-FA authentication extensions in the
Registration Request. For this purpose, the MN-FA authenticated
key token contains the following fields, bound together using a
suitable cryptographic transform:
- 32 bit timestamp field containing the time at which the token
was created by the token issuer, whose format is consistent
with the NTP specification [9]
- 32 bit expiration field containing the time at which the
Calhoun, Akhtar, Qaddoura, Asokan [Page 6]
INTERNET DRAFT February 2000
session keys will expired
- 32 bit SPI field that corresponds to the key described in the
next field
- variable length key from AAA infrastructure, used by foreign
agents to verify the MN-FA authentication extension in
Registration Requests.
The FA SPI field of the extension is used to identify the keys
necessary to authenticate this field and extract the key embedded
in this field.
If MN-FA authentication is based on shared keys, the key embedded
in the Authenticated MN-FA key token is the MN-FA session key. In
this case, the authenticated key token must provide both
confidentiality and authentication. Therefore, it MUST be
constructed by encrypting the four fields using a key shared among
all foreign agents within the administrative domain. The
preferred transform is Triple-DES Cipher Block Chaining mode
(3DES-CBC), but other algorithms could also be used.
If MN-FA authentication is based on digital signatures, the key
embedded in the Authenticated MN-FA key token is the public
signature verification key of the mobile node. In this case, the
authenticated key token does not need to be encrypted. It MAY be
constructed as above, or MAY be constructed using a digital
signature of the token-issuer covering the four fields. All
foreign agents within the administrative domain MUST have the
key(s) necessary to be able to verify this digital signature.
3.0 Generalized FA-HA Key Reply Extension
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 | Subtype | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Registration Key Distribution Data ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: The Generalized Mobile IP FA-HA Key Reply Extension
Type
TBD (not skippable) (see [7])
Calhoun, Akhtar, Qaddoura, Asokan [Page 7]
INTERNET DRAFT February 2000
Subtype
a number assigned to identify the way in which the Encoded
Registration Key Data is to be decrypted to obtain the
registration key
Length
The 16-bit Length field indicates the length of the extension. It
is equal to 4 plus the number of bytes in the Encoded Registration
Key Data.
Lifetime
This field indicates the duration of time (in seconds) for which
the FA-HA key is valid.
Registration Key Distribution Data
An encrypted copy of the registration key, along with any other
information needed by the foreign agent to create the designated
Mobility Security Association with the home agent.
4.0 HA-Key-Token Extension
In order to allow for the hand-off process to be done in an efficient
manner, the HA-Key-Token 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 belonging to the
same administrative domain as the old FA, and this extension was
received in a previous Registration Reply, the mobile node SHOULD
include this extension in the Registration Request. The Mobile Node
can verify whether foreign agents belong to the same administrative
domain using the advertisement Foreign Agent NAI extension, defined
in [15].
The HA-Key-Token Extension is subtype 1 of the Generalized FA-HA Key
Reply Extension (see section 3.0) and is defined as follows:
Calhoun, Akhtar, Qaddoura, Asokan [Page 8]
INTERNET DRAFT February 2000
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 | Subtype | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FA SPI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| HA SPI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Authenticated FA-HA key token...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: The HA-Key-Token Subtype-Specific Data
FA SPI
A 32-bit opaque value, indicating the SPI that the foreign agent
must use to determine the algorithm to use for recovering the HA
security information.
HA SPI
A 32-bit opaque value, which the foreign agent MUST use to index
all the necessary information recovered from the HA security
information after it is decoded.
Authenticated FA-HA key token
The Authenticated FA-HA key token field is opaque to the mobile
node, but is used by a foreign agent in the same administrative
domain as the token-issuer to extract an authenticated key that
can be used to verify FA-HA authentication extensions in a
Registration Reply sent by the home agent. For this purpose, the
HA-FA authenticated key token contains the following fields, bound
together using a suitable cryptographic transform:
- 32 bit timestamp field containing the time at which the token
was created by the token issuer, whose format is consistent
with the NTP specification [9]
- 32 bit expiration field containing the time at which the
session keys will expire
- 32 bit SPI field that corresponds to the key described in the
next field
- variable length key from AAA infrastructure, used by foreign
agents to verify the FA-HA authentication extension in
Registration Replies.
Calhoun, Akhtar, Qaddoura, Asokan [Page 9]
INTERNET DRAFT February 2000
The FA SPI field of the extension is used to identify the keys
necessary to authenticate this field and extract the key embedded
in this field.
If HA-FA authentication is based on shared keys, the key embedded
in the Authenticated FA-HA key token is the FA-HA session key. In
this case, the authenticated key token must provide both
confidentiality and authentication. Therefore, it MUST be
constructed by encrypting the four fields using a key shared among
all foreign agents within the administrative domain. The
preferred transform is Triple-DES Cipher Block Chaining mode
(3DES-CBC), but other algorithms could also be used.
If HA-FA authentication is based on digital signatures, the key
embedded in the Authenticated FA-HA key token is the public
signature verification key of the home agent. In this case, the
authenticated key token does not need to be encrypted. It MAY be
constructed as above, or MAY be constructed using a digital
signature of the token-issuer covering the four fields. All
foreign agents within the administrative domain MUST have the
key(s) necessary to be able to verify this digital signature.
5.0 Token Issuer's NAI Extension
The Token Issuer's NAI Extension is subtype 5 of the Generalized NAI
extension [16] and contains the NAI of the token issuer that created
the MN-Key-Token and/or HA-Key-Token. The mobile node MUST include
this extension if either the MN-Key-Token or the HA-Key-Token are
present in the Registration Request. The foreign agent uses this
information to identify whether it shares a common security
association with the token issuer that would be used to extract the
various session keys.
The Token Issuer's 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 | SubType | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Token Issuer's NAI...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
TBD (non-skippable)
Sub-Type
Calhoun, Akhtar, Qaddoura, Asokan [Page 10]
INTERNET DRAFT February 2000
5
Length
The length field MUST contain at least 1
Token Issuer's NAI
The Token Issuer's NAI field contains the NAI of the token issuer
that created the extensions defined in section 2.1 and 2.2.
6.0 Mobile Node Considerations
The mobile node MAY receive the MN-Key-Token and/or the HA-Key-Token
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 foreign agent that belongs to the same
adminstrative domain as the old Foreign Agent (identified via the
NAI), it SHOULD include both Key Token extensions and the Token
Issuer's 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, using
the Advertisement foreign agent NAI extension [15].
In the event that the Mobile Node is requesting keying material by
including the MN-AAA [10] authentication extension, if the Foreign
Agent returns an authentication failure code of 67 [11], the Mobile
Node SHOULD resend a registration that includes the MN-AAA
authentication extension. This will allow the Foreign Agent to issue
the request to the AAA infrastructure, and receive new keying
information.
7.0 Foreign Agent Considerations
The foreign agent MAY receive the MN-Key-Token and/or the HA-Key-
Token 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 extract keys (to be used in
verifiying authentication extensions) that were initially derived
from the Home AAA (AAAH).
In order for a foreign agent to be able to extract 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.
Calhoun, Akhtar, Qaddoura, Asokan [Page 11]
INTERNET DRAFT February 2000
In the case of authentication based on shared keys, if the foreign
agent is not able to extract 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.
8.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 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 Implementing and
Using the Data Encryption Standard", Federal Information
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] B. Schneier, "Applied Cryptography Second Edition", John Wiley &
Sons, New York, NY, 1995. ISBN 0-471-12845-7.
[8] M. Khalil, R. Narayanan, H. Akhtar, E. Qaddoura, "Mobile IP
Extensions Rationalization (MIER)", draft-ietf-mobileip-mier-
02.txt, IETF Work in Progress, December 1999.
[9] Mills, "Simple Network Time Protocol (SNTP) Version 4 for IPv4,
IPv6 and OSI, RFC 2030, October 1996.
[10] C. Perkins, P. Calhoun, "Mobile IP Challenge/Response
Extensions", draft-ietf-mobileip-challenge-06.txt, IETF Work in
Progress, October 1999.
[11] C. Perkins, Editor. IP Mobility Support. RFC 2002, October
1996.
Calhoun, Akhtar, Qaddoura, Asokan [Page 12]
INTERNET DRAFT February 2000
[12] C. Perkins, P. Calhoun, "AAA Registration Keys for Mobile IP",
draft-ietf-mobileip-aaa-keys-01.txt, IETF Work in Progress,
January 2000.
[13] B. Aboba, M. Beadles "The Network Access Identifier." RFC 2486.
January 1999.
[14] C. Perkins, D. Johnson, "Registration Keys for Route
Optimization", draft-ietf-mobileip-reg-key-01.txt, IETF Work in
Progress, February 2000.
[15] E. Gustafsson, A. Johnsson, C. Perkins, "Mobile IP Regional
Tunnel Management", draft-ietf-mobileip-reg-tunnel-01.txt, IETF
Work in Progress, August 1999.
[16] M. Khalil, E. Qaddoura, H. Akhtar, P. Calhoun, "Generalized NAI
Extension", draft-mkhalil-mobileip-gnaie-00.txt, IETF Work in
Progress, February 2000.
Calhoun, Akhtar, Qaddoura, Asokan [Page 13]
INTERNET DRAFT February 2000
9.0 Authors' Addresses
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
N. Asokan
Communication Systems Lab
Nokia Research Center
P.O. Box 407, FIN-00034, Nokia Group
Helsinki, Finland
Phone: +358 40 743 1961
E-Mail: n.asokan@nokia.com
Calhoun, Akhtar, Qaddoura, Asokan [Page 14]
| PAFTECH AB 2003-2026 | 2026-04-21 21:31:37 |