One document matched: draft-calhoun-mobileip-fa-tokens-00.txt
INTERNET DRAFT Pat R. Calhoun
Category: Standards Track Sun Microsystems, Inc.
Title: draft-calhoun-mobileip-fa-tokens-00.txt Haseeb Akhtar
Date: March 2000 Emad Qaddoura
Expires: September 2000 Nortel Networks
N. Asokan
Nokia Research Center
Foreign Agent Keys Encoded as Opaque Tokens for use in Hand-off Process
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 March 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 March 2000
Table of Contents
1.0 Introduction
1.1 Copyright Statement
1.2 Requirements language
2.0 MN-Key-Token Extension
3.0 HA-Key-Token Extension
4.0 Token Issuer's NAI Extension
5.0 Mobile Node Considerations
6.0 Foreign Agent Considerations
7.0 References
8.0 Authors' Addresses
Calhoun, Akhtar, Qaddoura, Asokan [Page 3]
INTERNET DRAFT March 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 March 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 March 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MN Home Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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.
MN Identifier
The 32-bit address using which foreign agents within the visited
domain can uniquely identify the Mobile Node. This SHOULD be the
Mobile Node's 32-bit Home Address.
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:
Calhoun, Akhtar, Qaddoura, Asokan [Page 6]
INTERNET DRAFT March 2000
- 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 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 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
Calhoun, Akhtar, Qaddoura, Asokan [Page 7]
INTERNET DRAFT March 2000
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 [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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| HA SPI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Authenticated FA-HA key token...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: 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
Calhoun, Akhtar, Qaddoura, Asokan [Page 8]
INTERNET DRAFT March 2000
- 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.
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.
4.0 Token Issuer's NAI Extension
The Token Issuer's NAI Extension is subtype 5 of the Generalized NAI
extension [4] 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:
Calhoun, Akhtar, Qaddoura, Asokan [Page 9]
INTERNET DRAFT March 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Token Issuer's NAI...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: The Token Issuer's NAI Extension
Type
TBD (non-skippable)
Sub-Type
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 3.0 and 4.0.
5.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.
6.0 Foreign Agent Considerations
Calhoun, Akhtar, Qaddoura, Asokan [Page 10]
INTERNET DRAFT March 2000
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.
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.
7.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] M. Khalil, E. Qaddoura, H. Akhtar, P. Calhoun. "Generalized NAI
Extension", draft-mkhalil-mobileip-gnaie-00.txt, IETF Work in
Progress. February 2000.
[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-
03.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
Calhoun, Akhtar, Qaddoura, Asokan [Page 11]
INTERNET DRAFT March 2000
Extensions", draft-ietf-mobileip-challenge-09.txt, IETF Work in
Progress. February 2000.
[11] C. Perkins, Editor. "IP Mobility Support", RFC 2002. October
1996.
[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, P. Calhoun. "Generalized Key Distribution Extensions
for Mobile IP", draft-perkins-mobileip-gen-key-00.txt, IETF Work
in Progress. March 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.
Calhoun, Akhtar, Qaddoura, Asokan [Page 12]
INTERNET DRAFT March 2000
8.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 13]
| PAFTECH AB 2003-2026 | 2026-04-22 21:31:41 |