Mipshop V. Narayanan
Internet-Draft Motorola
Expires: April 24, 2006 N. Venkitaraman
Motorola Labs
H. Tschofenig
Siemens
G. Giaretta
TILab
J. Bournelle
GET/INT
October 21, 2005
Handover Keys Using AAA
draft-vidya-mipshop-handover-keys-aaa-01.txt
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 April 24, 2006.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract
This document describes a AAA-assisted key management protocol to
Narayanan, et al. Expires April 24, 2006 [Page 1]
Internet-Draft Handover Keys Using AAA October 2005
generate session keys between a mobile node (MN) and an access router
(AR) for the purpose of securing handoff signaling messages. As
such, it specifies a message exchange between the MN and the AR and
assumptions that must hold in order for this protocol to work. The
idea is that the key derived between a mobile node and an access
router through this protocol can be used in fast handovers.
The protocol is loosely based on the Mobile IP-AAA model [11] where
the MN-HA security association is derived using a AAA server.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Goals and Assumptions . . . . . . . . . . . . . . . . . . 3
1.2. Applicability . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 5
4. Message Formats . . . . . . . . . . . . . . . . . . . . . . . 7
4.1. Mobility Header Types . . . . . . . . . . . . . . . . . . 7
4.1.1. Handover Key Request (HKReq) . . . . . . . . . . . . . 7
4.1.2. Handover Key Response (HKResp) . . . . . . . . . . . . 9
4.2. New Mobility Options . . . . . . . . . . . . . . . . . . . 11
4.2.1. Handover Nonce Mobility Sub-Option . . . . . . . . . . 11
4.3. New Neighbor Discovery Options . . . . . . . . . . . . . . 12
4.3.1. Handover Key NS Option . . . . . . . . . . . . . . . . 12
5. Protocol Details . . . . . . . . . . . . . . . . . . . . . . . 13
5.1. Basic Protocol . . . . . . . . . . . . . . . . . . . . . . 13
5.1.1. Mobile Node Considerations . . . . . . . . . . . . . . 13
5.1.2. Access Router Considerations . . . . . . . . . . . . . 15
5.1.3. AAA Server Considerations . . . . . . . . . . . . . . 17
5.2. Indirect MN-AR Handover Key Exchange . . . . . . . . . . . 18
6. Security Considerations . . . . . . . . . . . . . . . . . . . 19
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 21
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21
9.1. Normative References . . . . . . . . . . . . . . . . . . . 21
9.2. Informative References . . . . . . . . . . . . . . . . . . 22
Appendix A. Deriving the Handover Master Key . . . . . . . . . . 22
A.1. Identity Derivation for the Mobile Node . . . . . . . . . 24
Appendix B. RADIUS Handover Key Attributes . . . . . . . . . . . 24
Appendix C. Diameter Handover Key Application . . . . . . . . . . 27
C.1. New Messages . . . . . . . . . . . . . . . . . . . . . . . 27
C.2. AVPs . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
C.3. Diameter Flow of Messages . . . . . . . . . . . . . . . . 27
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 29
Intellectual Property and Copyright Statements . . . . . . . . . . 30
Narayanan, et al. Expires April 24, 2006 [Page 2]
Internet-Draft Handover Keys Using AAA October 2005
1. Introduction
Fast Mobile IPv6 [1] specifies a fast handoff protocol for IPv6
mobile nodes. It requires tunneling of packets from an old access
router to the mobile node. For this purpose, the FMIPv6 signaling
messages between the mobile node and the access router must be
secured to ensure FMIPv6 support for a legitimate mobile node that
has been authorized to obtain such services. The FMIPv6 protocol
itself does not provide a method to establish a session key and the
corresponding parameters between the mobile node and the access
router required for this purpose.
This document describes a AAA-assisted key management protocol to
generate session keys between a mobile node and an access router for
usage in the context of FMIPv6. As such, it specifies:
o A message exchange between the MN and the AR
o Payloads to carry keying material and parameters in the AAA
infrastructure
o Derivation of a new session key for handoff purposes based on a
shared secret
1.1. Goals and Assumptions
This document has been written with the following goals and
assumptions in mind.
o The protocol is designed to leverage the existence of AAA
infrastructure to establish session keys for securing Fast MIPv6
signaling messages. AAA is widely deployed today due to the usage
of AAA-based network access authentication infrastructure. The
AAA server is used to authenticate and authorize the MN for fast
handovers prior to generation of the handover key. The solution
presented in this document relies on the AAA infrastructure
components to derive and distribute keying material keys for
handover support.
o A Handover Master Key (HMK) between the MN and the home AAA server
(AAAH ) is required for this protocol to be able to derive
handover keys between the MN and AR. The exact method of
establishing or deriving this HMK is outside the scope of this
document. No particular method is mandated for this protocol to
work but we illustrate an example approach using the Application
Master Session Key (AMSK), as defined in EAP, in Appendix A. Due
to deployment considerations, it may be practical to use the
method to derive the HMK.
Narayanan, et al. Expires April 24, 2006 [Page 3]
Internet-Draft Handover Keys Using AAA October 2005
o Key naming of the HMK is provided using the Network Access
Identifier (NAI). In order to provide identity protection, it may
be undesirable to reuse the same NAI as used for network access
authentication. For sake of identity protection, it may be
desirable to have the AAA server to derive an ephemeral identity
at the time of HMK creation that can be used in subsequent
creation of handover keys.
o It is further assumed that a security association exists between
each AR and the AAA server. If a AAAL or other proxies are used
(as it is typical in a roaming environment) then the AR will
likely share a security association only with its local AAA server
(AAAL) instead of the user's home AAA server (AAAH). The AAAL in
this case acts as a AAA proxy between the AR and the AAAH server.
These security associations protect the signaling message exchange
including the transport of keying material and other security
sensitive parameters.
o The protocol does not introduce any new required steps at the time
of handover. Any new messages introduced for deriving handover
keys can be exchanged prior to the handover process.
o The protocol has been designed such that the compromise of one AR
does not lead to the compromise of any other AR. No AR is able to
view the key of another AR - keys are transferred securely from
the AAA server directly to the AR requesting it.
1.2. Applicability
Although this document is focused on FMIPv6, it is applicable to
other protocols as well. In the context of FMIPv6, the key derived
using this protocol can be used to secure the Fast Binding Update
(FBU) sent from the MN to the PAR as specified in [1]. Other
protocols may also use this mechanism as noted below. For instance,
CxTP [12] can also use this protocol to derive keys between the AR
and MN to secure the CTAR message. Additionally, keys between an MN
and a MAP can be derived using this protocol for HMIPv6 [13]
operation. This draft, however, does not address any details on how
the protocol described in this draft may be used for CxTP or HMIPv6.
The document is organized as follows. Section 2 describes the
terminology used in this document. Section 3 provides a general
protocol overview. Section 4 details the message formats. Section 5
provides protocol details on mobile node and access router operation.
Section 6 describes the security considerations for this protocol.
Appendix A provides a method of deriving the handover master key
using EAP. Appendices B and C describe the AAA messages and
attributes necessary for this protocol in RADIUS [2] and Diameter [3]
Narayanan, et al. Expires April 24, 2006 [Page 4]
Internet-Draft Handover Keys Using AAA October 2005
respectively.
2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC- 2119 RFC2119 [4].
In addition, this document uses the following terms:
MN-AAA Handover Master Key (HMK):
A key that is shared between the Mobile Node and the AAAH server,
hereby referred to simply as the Handover Master Key.
Handover Key (HK):
Session key used to secure messages between the Mobile Node and
Access Router. A given HK between an MN and ARn is termed as HKn.
3. Protocol Overview
This section provides a description of the procedure to obtain the
Handover Key (HK). We assume that the MN shares a session key,
called Handover Master Key (HMK), with the AAA (AAAH) server. This
key, for instance, may be the derived from the EAP key hierarchy.
Appendix A describes a method of deriving the HMK and an identity for
the MN from the EAP Application Master Session Key (AMSK). This
method can be used whenever possible. For the purpose of the
protocol itself, the HMK may simply be a handover specific master key
pre-shared between the MN and the AAA server.
Figure 1 depicts the high-level protocol interaction.
MN AR AAAH Server
| HKReq. | |
| ---------> | |
| | AAA Request |
| | ----------------------> |
| | AAA Response |
| | <----------------------- |
| HKResp. | (Keying material) |
| <--------- | |
Figure 1: Protocol Operation
Narayanan, et al. Expires April 24, 2006 [Page 5]
Internet-Draft Handover Keys Using AAA October 2005
The MN, upon attaching to an AR (say AR1) in a given administrative
domain, sends a Handover Key Request (HKReq) message to the AR. The
MN creates a HKReq message including a NAI-like identifier (that was
derived possibly during the time of HMK derivation), a message ID, a
sequence number, care-of-address (CoA) and a keyed message digest of
these fields by using the HMK. Upon receiving the HKReq from the MN,
AR1 verifies the validity and uniqueness of the CoA claimed by the
MN. AR1 must first ensure that it has a valid neighbor cache entry
for the CoA claimed by the MN. AR1 must also ensure that no other
mobile node on that link claims the same CoA specified in the HKReq.
Details of these operations are described in section Section 5.
After verifying the validity and uniqueness of the CoA of the MN, AR1
forwards the HKReq message to the AAA Server via the AAA
infrastructure. The keyed message digest allows the home AAA server
to authenticate the MN and to perform authorization for fast handoffs
before deriving a unique and fresh session key, the Handover Key
(HK1).
HK1 will subsequently be used between the MN and the AR1 after a
successful protocol execution. The key derivation procedure for the
Handover Key is defined as follows:
HK1 = PRF(HMK, AAA-MN Nonce | AR1 ID | MN ID, "Handover Key"), where
| indicates concatenation
The AR1 ID is the IP address of AR1 as seen by the MN. The MN ID is
the NAI of the MN that is sent by the MN in the HKReq message. The
AAA-MN Nonce is a nonce generated by the AAA server for the purpose
of HK1 derivation.
After successful authentication and authorization, the AAA Server
then sends two different parameters to AR1 - one of the parameters
includes the session key HK1 and the lifetime associated with it.
The other parameter, to be sent to the MN, includes the AAA-MN Nonce.
A keyed message digest computed based on the HMK is included with
this parameter to the MN. The message is protected with the AR1-AAA
SA when forwarded to AR1.
AR1 sends a Handover Key Response (HKResp) to the MN, including the
material (nonce) sent by the AAA server and also the key lifetime it
received from the AAA server. Using this keying material, the MN
derives HK1.
When the MN is ready to send an FBU to AR1 (in accordance with [1],
it uses HK1 to secure the FBU message.
Narayanan, et al. Expires April 24, 2006 [Page 6]
Internet-Draft Handover Keys Using AAA October 2005
4. Message Formats
This protocol defines new Mobility Header types for carrying the
Handover Key Request (HKReq) and Handover Key Response (HKResp)
messages. This protocol also defines a new Mobility Option called
Handover Nonce Mobility Option and a new Neighbor Discovery option
called Handover Key NS Option. This section presents the description
of the HKReq and HKResp messages and the Handover Nonce Mobility
option and the Handover Key NS Option that this protocol uses. The
description of AAA attributes that are needed for this protocol are
described in Appendices B and C. Appendix B provides the attributes
for RADIUS and Appendix C describes a Diameter handover application.
4.1. Mobility Header Types
4.1.1. Handover Key Request (HKReq)
A Handover Key Request (HKReq) message MUST be sent from the MN to
the AR to request the derivation of a handover key. The MN sends
this message some time after selecting the AR as its default router
but prior to the need to hand over to a different AR. The detailed
processing rules for this message are described in the Protocols
Details section.
The HKReq message uses the MH Type value TBA1. The length in the
mobility header is set to include the mobility suboptions. When this
value is indicated in the MH Type field, the format of the Message
Data field in the Mobility Header is as follows:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Type |v| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message ID | Sequence # |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Key Care of Address |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Mobility Suboptions (variable) .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Narayanan, et al. Expires April 24, 2006 [Page 7]
Internet-Draft Handover Keys Using AAA October 2005
Figure 2: Handover Key Request
HKReq Fields
Message Type
A one octet field indicating the handover key exchange
mechanism encoded in the mobility options, the value of which
is taken from the IANA Handover Key Exchange Mechanism Type
registry. A value of '1' (to be assigned by IANA) indicates
AAA-assisted handover key exchange. Other key exchange
protocols defined in future may define additional values.
v
Verify flag. This is set by the MN to indicate that it may
already share a key with the AR.
Reserved
Set to 0; ignored on reception.
Message ID
A two octet random value used to uniquely match requests and
responses and identify retransmissions.
Sequence #
A two octet unsigned integer used by the AR to sequence HKReq
messages and by the MN to match a returned HKResp with this
HKReq.
Key Care of Address
Sixteen octet field containing the IPv6 CoA for which the key
is requested.
Mobility Suboptions
Variable length field of such length that the complete Mobility
Header is an integer multiple of 8 octets. This field contains
zero or more TLV-encoded mobility suboptions. Valid mobility
sub-options for this message include the following:
Narayanan, et al. Expires April 24, 2006 [Page 8]
Internet-Draft Handover Keys Using AAA October 2005
Mobile Node Identifier Mobility Sub-option, as defined in
[5]
MN-AAA Auth Option as defined in [6]
MN-AR Auth Option as defined in [7]
4.1.2. Handover Key Response (HKResp)
A handover key response (HKResp) message MUST be sent from the AR to
the MN in response to a HKReq message. HKResp MUST carry suboptions
appropriate to the key agreement mechanism requested in the HKReq,
which the MN can use to configure itself with a handover key for the
requested CoA.
The HKResp message uses the MH Type value TBA2. When this value is
indicated in the MH Type field, the format of the Message Data field
in the Mobility Header is as follows:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Type |v| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message ID | Sequence # |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Status Code | Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SPI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Mobility options .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: Handover Key Response
HKResp Fields
Message Type
A one octet field indicating the key exchange mechanism encoded
in the mobility options, the value of which is taken from the
IANA Handover Key Agreement Mechanism Type registry. A value
of '1' (to be assigned by IANA) indicates AAA-assisted handover
Narayanan, et al. Expires April 24, 2006 [Page 9]
Internet-Draft Handover Keys Using AAA October 2005
key exchange. Other key exchange protocols defined in future
may define additional values.
Verified flag. Set by the AR in response to a HKReq with the V
bit set, if it verified the request.
Reserved
Set to 0; ignored on reception.
Message ID
A two octet random value used to uniquely match requests and
responses and identify retransmissions. This value is copied
from the corresponding HKReq.
Sequence #
A two octet unsigned integer from the matching HKReq that
triggered this message.
Status Code
One octet status code indicating the status of the request.
0 - Success.
129 - Requested handover key exchange mechanism is not
supported.
130 - Care of address authorization denied.
131 - Administratively prohibited.
132 - Unable to verify handover key
133 - MN-AAA Authentication Option Required
134 - MN-AR Authentication Option Required
135 - Invalid MN-AAA Authenticator Value (Sent by the AAA
server)
Narayanan, et al. Expires April 24, 2006 [Page 10]
Internet-Draft Handover Keys Using AAA October 2005
136 - Invalid MN-AR Authenticator Value
Lifetime
Lifetime of the handover key, in seconds.
SPI
Four octet Security Parameter Index for the handover key at the
AR. The SPI is used by the MN and the AR to identify the key
when the key is used.
Mobility Suboptions
Variable length field of such length that the complete Mobility
Header is an integer multiple of 8 octets. This field contains
zero or more TLV-encoded mobility suboptions. Valid mobility
sub-options for this message include the following:
Nonce Mobility Sub-option (new option defined in section
Section 4.2.1 below)
MN-AAA Auth Option as defined in [6]
MN-AR Auth Option as defined in [7]
4.2. New Mobility Options
4.2.1. Handover Nonce Mobility Sub-Option
This new mobility option is defined to carry the nonce in the HKResp
to the MN.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Subtype | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Handover Nonce ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: Handover Nonce Mobility Option
Narayanan, et al. Expires April 24, 2006 [Page 11]
Internet-Draft Handover Keys Using AAA October 2005
Option Fields
Option Type
Handover Nonce (to be assigned by IANA)
Option Length
8-bit unsigned integer, representing the length in octets of
the Sub-type, and the handover nonce fields.
Sub-type
'1' - AAA-Nonce (nonce generated by the AAA Server)
Set to 0 and ignored on reception.
A variable length nonce generated by the AAA server.
4.3. New Neighbor Discovery Options
4.3.1. Handover Key NS Option
This option is used in the neighbor solicitation sent by the AR in
response to a HKReq received from a mobile node.
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 | Message ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: Handover Key NS Option
Option Fields
Option Type
Handover Message ID (to be assigned by IANA)
Narayanan, et al. Expires April 24, 2006 [Page 12]
Internet-Draft Handover Keys Using AAA October 2005
Option Length
8-bit unsigned integer, representing the length in octets of
the message ID field.
Message ID
Copied from the Message ID field in the HKReq that triggered
the neighbor solicitation.
5. Protocol Details
5.1. Basic Protocol
The proposed protocol enables a MN to derive session keys (HKs) with
an access router. This section describes the processing rules for
the mobile node, the access router and the AAA server.
5.1.1. Mobile Node Considerations
After completing MIPv6 signaling the mobile node SHOULD immediately
proceed to obtain a session key between itself and its current AR.
5.1.1.1. Sending Handover Key Request Messages
In order to derive a shared key with the AR, the MN MUST create a
HKReq with a unique, random Message ID with the sequence number
starting at 0. For subsequent retransmissions, the sequence number
MUST be incremented by 1 and the Message ID MUST remain the same.
The HKReq sent by the MN MUST include the MN-AAA Authentication
Option. The authentication data in the MN-AAA authentication option
shall be calculated as follows:
Authentication data = hash_fn(MN-AAA Shared key, MH Data)
hash_fn() is decided by the value of mobility SPI field in the
authentication option.
If the mobility SPI indicates HMAC_SHA1, then hash_fn() is HMAC_SHA1.
When HMAC_SHA1_SPI is used, the HKReq is authenticated by AAA using
HMAC_SHA1 authentication.
MH Data is the content of the Mobility Header up to and including the
mobility SPI field of this option.
The MN should send a new HKReq before the expiry of lifetime of the
Narayanan, et al. Expires April 24, 2006 [Page 13]
Internet-Draft Handover Keys Using AAA October 2005
key obtained via the pervious HKReq. Once a MN obtains a new key, it
MUST discard the old key and use the new key for authenticating the
FBU.
If the MN does not receive a response after a configured timeout
(HKEY_REQ_TOUT), it SHOULD retransmit the request for a maximum of N
HO_KEYTRIES. In each of the retry attempts, the MN MUST use the same
message ID. The default value of N_HO_KEYTRIES is 3.
5.1.1.2. Receiving and Processing Neighbor Solicitation Message with
Handover Key Option
When the MN receives a neighbor solicitation from the AR with the
Handover Key Option corresponding to the HKReq sent by it, it MUST
NOT respond with a neighbor advertisement.
5.1.1.3. Receiving and Processing Handover Key Response Messages
Upon receiving a successful HKResp message from the AR, the MN MUST
compute the handover key using the keying material contained in the
HKResp message. The key is computed as follows:
HK = PRF(HMK, AAA-MN Nonce | AR ID | MN ID, "Handover Key"), where |
indicates concatenation
The AR ID is the IP address of the AR. The MN ID is the NAI of the
MN that is sent by the MN in the HKReq message. The AAA-MN Nonce is
a nonce generated by the AAA server and included in the HKResp
received by the MN.
Additionally, the MN MUST store the SPI and lifetime associated with
the key, as sent in the HKResp.
If the MN receives a HKResp with the Code set to HKE_NOT_SUPPORTED,
it SHOULD use a different key exchange protocol to derive the
handover key. If the code is set to COA_UNAUTHORIZED, it MAY
retransmit the HKReq after a random time greater than
HK_RETRY_INTERVAL. However, the MN MUST NOT retransmit the HKReq
more than N HO_KEYTRIES. If the code is set to MN_AAA_AUTH_REQD, the
MN MUST send a new HKReq with the MN AAA Authentication Option
included. If the code is set to INVALID_MN_AAA_AUTH, the MN MUST NOT
send any more HKReq messages to the AR.
5.1.1.4. Returning to an Access Router
When a MN attaches to an AR with which the MN believes it has a
Narayanan, et al. Expires April 24, 2006 [Page 14]
Internet-Draft Handover Keys Using AAA October 2005
shared Key (for example the MN has an unexpired key it obtained when
it was Previously associated with the access router), the MN MAY
request that the AR utilize the Key as long as the key has not
expired. The MN MAY do so only after verifying that by sending a
HKReq with the verify flag set. The MN MUST include a MN-AR
Authentication option in HKReq with verify flag set. The MN-AR
Authentication Option MUST be the last option included in the HKReq.
The verify procedure serves two purposes: (1) It is used to verify
that the AR still has the key and allows use of the key until the
lifetime of the key and (2)It enables the MN CoA to be bound to the
key. If the verify request is not successful the MN SHOULD create a
new MN-AR key by sending a HKReq with the MN-AAA Auth option .
5.1.2. Access Router Considerations
If the HKReq does not have the verify bit set, the AR does the
following.
The AR MUST first determine if it has a pending request from the MN
with the same message id. If so and if the AR has already received
the HKResp, the AR SHOULD retransmit the response to the MN. If the
received message has the same message ID and the sequence number as
before, the AR MUST drop the packet. For further protection from
replays, the rate of retransmissions of responses to MN MUST not be
more than a preconfigured RETRANS_RATE. If the AR already forwarded
this message to the home AAA Server but has not yet received a
response from AAA server, the AR MUST silently discard the
retransmitted request from the MN. Note that the AAA protocol should
independently perform its own retransmission. If this is a new
HKReq, the AR MUST check to determine if the MN-AAA Authentication
Option has been included in this message by the MN. If it has been
included, then the AR MUST forward the request to the home AAA
Server. If it has not been included, the AR MUST drop the message
and return a HKResp to the MN with the error code set to "MN-AAA
Authentication Option Required".
If it is a new HKReq, the AR MUST validate the CoA in the HKReq using
the procedure in section Section 5.1.2.1. The AR SHOULD send a
request to the AAA server only after successful validation of the
CoA.
The AAA message is constructed using the appropriately defined
attributes (defined in Appendix B for RADIUS and Appendix C for
Diameter). While creating the AAA request message, the AR MUST
include the NAS-IP-Address AVP in the AAA message (e.g. RADIUS
Access Request) sent to the AAA server. The AR MUST use its IP
address as seen by the MN in this AVP. This will be used as the AR
ID in deriving the handover key.
Narayanan, et al. Expires April 24, 2006 [Page 15]
Internet-Draft Handover Keys Using AAA October 2005
The domain name in the NAI is used to determine the AAA server to be
contacted. Note that if there is a local AAA server that is
different from the MNs AAA server, then the AR may send the message
via the AAA protocol to the Local AAA server which in turn would
forward the request. The AAAL will act as a AAA proxy in this case.
If the AR receives a RADIUS Access Accept message from the AAA
server, it MUST store the handover key received from the AAA server
along with the CoA and MN ID and index it with an SPI. The AR MUST
send the SPI, AAA-MN Nonce, lifetime and the MN-AAA authentication
value in the RADIUS message in the HKResp message to the MN.
If the AR receives a RADIUS Access Reject message from the AAA
server, the AR MUST send an appropriate error code to the MN in the
HKResp message.
The AR SHOULD buffer the packet for a maximum value of HKEY_REQ_TOUT,
so that it can be retransmitted upon receiving a HKReq with the same
Message ID and incremented sequence number.
If an AR receives a RADIUS Access Accept or Reject corresponding to a
MN that is no longer connected to it, the AR SHOULD silently discard
it.
When the neighbor cache entry for the CoA expires, the AR MUST
disassociate the key and the corresponding CoA. When the lifetime of
the key expires, the AR should remove the SPI.
5.1.2.1. MN Care-of-address Validation
The objective of validating the CoA provided by the MN in the HKReq
is to ensure that the same CoA is not being claimed by another MN.
This is essential to ensure that a node cannot redirect traffic meant
for another mobile node to some other location. For this purpose,
the AR must perform address validation as explained here. While this
procedure ensures that an authenticated node cannot send a FBU
corresponding to some other mobile node's CoA, it does not eliminate
the known threats generally introduced by the Neighbor Discovery
Protocol [8] in the absence of SEND [9].
As a first step, the AR, upon receiving a HKReq from a mobile node,
MUST verify that the CoA is not already associated with a key. It
SHOULD also verify that the link layer address associated with the
CoA in the neighbor cache is the same as the respective addresses in
the HKReq. If these test pass, the AR MUST then send a Neighbor
Solicitation message for the CoA claimed by the MN in the HKReq,
including the Handover Option in the NS. If the AR receives at least
one NA corresponding to the NS, it MUST reject the HKReq with the
Narayanan, et al. Expires April 24, 2006 [Page 16]
Internet-Draft Handover Keys Using AAA October 2005
code in HKResp set to "Care of address authorization denied". If the
AR does not receive any NAs corresponding to the NS, it MUST proceed
with normal processing of the HKReq.
5.1.2.2. Returning Mobile Node
If a mobile node believes that it shares a handover key with a valid
lifetime with the AR, it may send a HKReq with the 'V' bit set. If
so, the AR MUST use the included SPI (from the MN-AR Authentication
option) to lookup the MN and obtain the key. If a key is present and
the computed keyed message digest matches the values included in the
HKReq message, the AR MUST verify that the IP address is valid and is
not claimed by any other node as described in Section 5.1.2.1. If
that procedure succeeds the AR MUST send a response with the verified
bit set including the hash of the response. Also, the AR MUST record
the CoA of the MN as the IP address associated with the handover key
for that MN, in addition to the MN ID (NAI). If the MN-AR
Authentication Option is not present in the HKReq in this case, the
AR MUST drop the message and return a HKResp with the error code set
to "MN-AR Authentication Option Required". Also, if the MN-AR
Authentication Option was included but the AR was unable to verify
the keyed message digest, it MUST drop the message and return a
HKResp with the error code set to "Invalid MN-AR Authenticator
Value". If the AR does not have the key and if the HKReq does not
have the MN-AAA Authentication Option, it MUST drop the message and
return a HKResp with the error code set to "Invalid MN-AR
Authenticator Value".
If the AR does not have the key and the HKReq included the MN-AAA
Authentication Option, the AR MAY process the HKReq as though the 'V'
bit was not set.
5.1.3. AAA Server Considerations
A description of the actual AAA attributes is included in Appendices
B and C. This section provides a brief description of the operation
of the AAA server for this protocol.
Upon receiving a handover key request, the AAA server MUST verify
that the MN-AAA Authentiation Option is present in the message. If
it is absent, the AAA server MUST silently discard the message.
Otherwise, the AAA server MUST verify the keyed message digest
included in the option. If it is invalid, the AAA server MUST
silently discard the message. If the hash is valid, the AAA server
must proceed with the handover key generation as follows.
HK = PRF(HMK, AAA-MN Nonce | AR ID | MN ID, "Handover Key"), where |
indicates concatenation
Narayanan, et al. Expires April 24, 2006 [Page 17]
Internet-Draft Handover Keys Using AAA October 2005
The AR ID is the IP address of the AR included in the NAS-IP-Address
AVP in the request. The MN ID is obtained from the HK-MN-NAI
attribute included in the RADIUS Access Request. The AAA-MN Nonce is
generated by the AAA Server. The Handover Master Key (HMK) is shared
between the MN and the AAA server.
If the NAS-IP-Address AVP was not included in the request, the AAA
server MUST return an error to the AR, indicating "NAS-IP-Address
Required".
The AAA server MUST send a response back to the AR, including the
AAA-MN Nonce as well as the derived HK in encrypted form. Note that
the AAA protocol is expected to provide its own security between the
AR and the AAA server for purposes of encrypting the HK. The AAA
server SHOULD include a lifetime for the HK in the RADIUS Access
Accept message. The AAA server is, however, not required to store
the key or the lifetime. The MN-AAA Authentication Option MUST be
calculated as a hash of the AAA-MN-Nonce using the HMK that the AAA
Server shares with the MN and MUST be included in the RADIUS Access
Accept message.
5.2. Indirect MN-AR Handover Key Exchange
The MN may wish to derive a handover key with an AR when it is not
directly attached to that AR. This may happen for two reasons. In
one case, the MN may be using FMIPv6 service from a pAR and its
handover key with the pAR may be about to expire. So, it may need to
refresh the key via the nAR it is attached to. In the second case,
the MN may wish to pre-authenticate with a target AR before it
attaches to it. In the latter case, the MN may learn about the
neighboring ARs while it is attached to AR1 by exchanging the RtSolPr
and PrRtAdv messages as defined in [1] or via layer 2 mechanisms.
To generate a handover key with the neighboring AR, the MN sends
HKReq message to those ARs. Assuming that AR2 is a neighbor of AR1,
the MN sends a HKReq to AR2 through AR1, while still attached to AR1.
The HKReq is sent and processed in the same manner as in the direct
case, with only one exception. The MN, in this indirect case, may
not have a valid CoA on the link of the AR (say, AR2) with which it
tries to establish this handover key. Note that this is true only
for the pre-authentication case. If such is the case, the MN MAY
send the HKReq with a NULL CoA. AR2, in this case, contacts the AAA
server and establishes the handover key without performing the step
of CoA validation as explained in section Section 5.1.2.1. In this
case, if the MN roams to AR2, it MUST send another HKReq with the "V"
bit set, including the valid CoA. AR2 MUST process this as described
in section Section 5.1.2.2 and establish the binding between the CoA
Narayanan, et al. Expires April 24, 2006 [Page 18]
Internet-Draft Handover Keys Using AAA October 2005
and the handover key. AR2 MUST NOT allow the use of the handover key
prior to the establishment of this binding between the key and the
CoA of the MN.
If the MN hands off prior to receiving the HKResp from AR2, it re-
sends the HKReq message with the same message ID, to AR2, upon
attaching to it. AR2 re-sends the HKResp sent earlier via AR1 to the
MN directly in this case. This does not add to the handoff delay,
since HK2 is required to authenticate the FBU sent only when the MN
is performing a handoff from AR2 to a third AR. The MN sends a new
HKReq to any new neighbors it receives information about, while
attached to AR2.
6. Security Considerations
This section describes the security considerations for the base
protocol for establishing handover keys specified in this document
itself. The messages described in this document are intended to
allow the establishment of a security association between the mobile
node and access router for fast handoff purposes. The protocol is
loosely based on the Mobile IP-AAA model [11] where the MN-HA
security association is derived using a AAA server. The protocol
relies on existing shared security association between the mobile
node and the AAA server. It also relies on the security of the AAA
protocol (RADIUS or Diameter) used between the AR and the AAA server.
The Security Associations resulting from use of this protocol do not
offer any higher level of security than what is already implicit in
use of the AAA Security Association between the mobile node and the
AAAH. In order to deny any adversary the luxury of unbounded time to
analyze and break the secrecy of the AAA Security Association between
the mobile node and the AAA server, that AAA Security Association
MUST be refreshed periodically. The provisioning and refreshing of
the AAA key in the MN and AAA server is outside the scope of this
document.
The handover key protocol described in this document transports the
nonce from the AAA server to the MN and the MN derives its own
handover key using the nonce and other parameters.
The proposed protocol uses an NAI-like identity of the MN as the
identity to derive the handover keys between the MN and AR. This
protocol does not provide active or passive user identity
confidentiality. If such confidentiality is desired, a service
specific identity must be derived as part of the HMK bootstrapping
procedure.
Narayanan, et al. Expires April 24, 2006 [Page 19]
Internet-Draft Handover Keys Using AAA October 2005
The proposed protocol uses a sequence number in combination with a
message ID to detect retransmissions and replays. It must be noted
that this provides limited replay protection. Replay protection is
provided as long as there is state corresponding to an MN at the AR.
An attacker may, however, cache a HKReq message sent on the link
between an MN and AR and replay it at a sufficiently later time when
the AR has no state for that MN. In this case, the AR will end up
sending a AAA request to the AAA server. The HKReq will be
successfully processed by the AAA server in this case, since the
authentication data will be valid (as the attacker has not modified
anything in the message). The AAA server will create a HK
corresponding to this message and will provide it to the AR.
However, it must be noted that the MN cannot obtain the HK, because,
without the HMK, it cannot derive the key from the nonce. Hence,
this scenario does not lead to an adversary using FMIP services on
the AR. But, it does result in some minimal resource consumption at
the AAA server (for computing the handover key). The assumption from
an accounting perspective here is that accounting at the AAA server
will not be triggered until the MN actually starts using the FMIP
service (in other words, until the MN sends an FBU to the AR). If
accounting for FMIPv6 is started based on when the handover key is
derived, this issue could result in an MN getting charged for FMIP
service due to an adversary. If this model is adopted for
accounting, this issue must be revisited and a timestamp-based replay
protection for the handover keys protocol may then be more
appropriate. A timestamp- based mechanism is not considered for the
moment, as the added complexity has not been viewed as necessary.
For FMIPv6 operation, the access router must ensure that a mobile
node cannot redirect traffic belonging to any other node. For this
purpose, the access router must bind the hanodver key of a mobile
node to its care-of-address. The AR must ensure that the CoA claimed
by the MN is does not belong to any other node. The handover key
protocol described in this draft proposes extensions to ND messages
to accomplish this. It must be noted that this protocol is not
attempting to solve the general threats (documented in X) of ND
itself. While an unauthorized node cannot obtain FMIPv6 service or
redirect traffic from another subnet, it is possible for a node to
prevent legitimate nodes from obtaining FMIPv6 service by simply
responding to the NS messages from the AR. To protect from all the
known threats of ND, it is recommended that SEND be used in
conjunction with this protocol.
7. IANA Considerations
TBD: Details will be provided in a future draft version.
Narayanan, et al. Expires April 24, 2006 [Page 20]
Internet-Draft Handover Keys Using AAA October 2005
8. Acknowledgments
The authors would like to thank James Kempf for helping with the
design of the Mobility Header messages and for his help in several
discussions that helped the design of the protocol itself. The
authors would like to thank, in alphabetical order of last names,
Mike Korus, Madjid Nakhjiri and George Popovich for their
discussions, reviews and comments on the early versions of this
document.
9. References
9.1. Normative References
[1] Koodli, R., "Fast Handovers for Mobile IPv6", RFC 4068,
July 2005.
[2] Rigney, C., Willens, S., Rubens, A., and W. Simpson, "Remote
Authentication Dial In User Service (RADIUS)", RFC 2865,
June 2000.
[3] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. Arkko,
"Diameter Base Protocol", RFC 3588, September 2003.
[4] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[5] Patel, A., "Mobile Node Identifier Option for MIPv6",
draft-ietf-mip6-mn-ident-option-03 (work in progress),
September 2005.
[6] Patel, A., "Authentication Protocol for Mobile IPv6",
draft-ietf-mip6-auth-protocol-07 (work in progress),
September 2005.
[7] Venkitaraman, N., "Mobile Node-Access Router Authentication
Option", draft-narayanan-mipshop-mn-ar-auth-option-00 (work in
progress), October 2005.
[8] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery
for IP Version 6 (IPv6)", RFC 2461, December 1998.
[9] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure
Neighbor Discovery (SEND)", RFC 3971, March 2005.
[10] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in
IPv6", RFC 3775, June 2004.
Narayanan, et al. Expires April 24, 2006 [Page 21]
Internet-Draft Handover Keys Using AAA October 2005
9.2. Informative References
[11] Perkins, C. and P. Calhoun, "Authentication, Authorization, and
Accounting (AAA) Registration Keys for Mobile IPv4", RFC 3957,
March 2005.
[12] Loughney, J., "Context Transfer Protocol",
draft-ietf-seamoby-ctp-11 (work in progress), August 2004.
[13] Soliman, H., "Hierarchical Mobile IPv6 Mobility Management
(HMIPv6)", draft-ietf-mipshop-hmipv6-04 (work in progress),
December 2004.
[14] Aboba, B., "Extensible Authentication Protocol (EAP) Key
Management Framework", draft-ietf-eap-keying-06 (work in
progress), April 2005.
[15] Housley, R. and B. Aboba, "AAA Key Management",
draft-housley-aaa-key-mgmt-00 (work in progress), June 2005.
Appendix A. Deriving the Handover Master Key
A Handover Master Key (HMK) between the MN and AAAH server is
required for this protocol to be able to derive handover keys between
the MN and AR. As mentioned earlier in the document, the exact
method of derivation of this HMK is outside the scope of this
document. One method of HMK derivation is presented in this Appendix
and it is based on the Application Master Session Key (AMSK) defined
in EAP EAPKEY [14]. The basic idea is that during the authentication
for network access, the MN and the AAA server derive an AMSK and
subsequently an HMK from the EAP method derived keying material.
The procedure requires that the authentication for network access is
based on an EAP method capable of exporting session keys. Deriving
the Handover Master Key (HMK) involves requires the following steps:
1. The MN and the AAA server of the home domain undertake the EAP
exchange for network access authentication.
2. At the end of the EAP exchange the EAP peers derive the Master
Session Key (MSK) and the Extended Master Session Key (EMSK). As
such, the EAP method MUST be capable of deriving these session
keys.
3. The MN and the AAA server derive an AMSK from the EMSK to be used
as HMK. The key derivation function is described below. The
lifetime of the HMK is managed as a system parameter and must not
Narayanan, et al. Expires April 24, 2006 [Page 22]
Internet-Draft Handover Keys Using AAA October 2005
be higher than the lifetime of the EMSK (as stated in EAPKEY
[14]). As a default choice the two lifetimes should be equal.
Figure 6 shows how the AMSK and the HMK-AMSK is derived.
EAP Peer EAP Server
(MN) (AAA Server)
+--------------------------------+
/-------------------------\
/ EAP \
MSK \ exchange / MSK
\-------------------------/
+------+ +------+
| EMSK | | EMSK |
+------+ +------+
+------------+ +------------+
| HMK-AMSK | | HMK-AMSK |
+------------+ +------------+
Figure 6: Key Hierarchy
The HMK is derived through the key derivation function specified for
AMSK in EAPKEY [14] and shown below for the sake of clarity.
KDF (K,L,D,O) = T1 | T2 | T3 | T4 | ...
where:
T1 = prf (K, S | 0x01)
T2 = prf (K, T1 | S | 0x02)
T3 = prf (K, T2 | S | 0x03)
T4 = prf (K, T3 | S | 0x04)
prf = HMAC-SHA1
K = EMSK
L = key label
D = application data
Narayanan, et al. Expires April 24, 2006 [Page 23]
Internet-Draft Handover Keys Using AAA October 2005
O = OutputLength (2 bytes)
S = L | " " | D | O
The application specific parameters are set as follows:
o key label = "Handover Master Key"
o application data =
o output length = 128 bits
A.1. Identity Derivation for the Mobile Node
Based on the protocol defined in this document, the MN provides its
identity in the HKReq message. As this message is not encrypted, the
identity used by the MN in this exchange can be seen by other,
possible malicious, nodes. This should be avoided since it exposes
the identity of the MN implying identity privacy concerns. To solve
this issue, several EAP methods provide user identity
confidentiality. Thus, an exchange of HKReq/HKResp messages that
carries the MN identity in clear, will destroy the security
properties of the EAP method used for network authentication. One
possible approach to solve this issue is to use in the HKReq/HKResp
exchange a derived identity based on a pseudonym - during the EAP
method used for network access authentication and based on the
cryptographic material exported by the EAP method itself, the AAA
server can send to the MN an identity that the MN can use for
subsequent HKReq/HKResp exchanges. Moreover, different MN identities
can be derived so that the MN can use different entities in different
exchanges of the protocol, in order that malicious nodes are unable
to trace its movements based on the same pseudonym. Alternatively,
the capability of certain EAP to establish an encrypted channel to
securely exchange parameters can be exploited to secure provisioning
a temporal identity.
Appendix B. RADIUS Handover Key Attributes
This section provides an overview of the protocol interaction between
the access router and the RADIUS server to request a key for FMIPv6.
The proposal assumes that the AAA exchange is authenticated, replay
protected, integrity protected and encrypted. For RADIUS, the usage
of IPsec between the AR and the AAAH server is recommended. The AR
acts as a AAA client in order to get a Handover Key in order to
secure FMIPv6 signaling messages.
A more detailed version of this section will be provided in the near
Narayanan, et al. Expires April 24, 2006 [Page 24]
Internet-Draft Handover Keys Using AAA October 2005
future.
MN AR AAAH Server
| HKReq. | |
| ---------> | |
| | Access Request |
| | ----------------------> |
| | Access Accept (key mtrl)|
| | <----------------------- |
| HKResp. | |
| <--------- | |
Figure 7: RADIUS Messages
As shown in Figure 7 the MN sends a HKReq to the AR. This message
contains an NAI of the Mobile node and the MN-AAA Authenticator.
This authenticator is the keyed message digest computed with the HMK
(see Appendix A). The access router extracts the necessary
information to from the attributes to be included in a RADIUS Access
Request messages. This message is sent to the AAA infrastructure.
The AR includes at least the IP address used with the MN in the
NAS-IP attributes.
The message is the following:
RADIUS-Access-Request {
HK-MN-MSGID-SEQ (Message ID | Sequence number from HKReq)
HK-MN-NAI
NAS-IP (IP Address of the AR)
HK-MN-AAA Authenticator
Message Authenticator(80)}
The home RADIUS server receives the message and checks the validity
of the HK-MN-AAA Authenticator. This authenticator value is
calculated on the HK-MN-MSGID-SEQ and HK-MN-NAI. The RADIUS server
generates a Nonce of at least 128 bits (AAA-MN Nonce) and computes
the Handover Key (HK1) as follows:
HK1 = PRF(HMK, AAA-MN Nonce, AR1 ID, MN ID, "Handover Key")
where, AR1 ID is extracted from the NAS-IP Attribute, MN ID is
Narayanan, et al. Expires April 24, 2006 [Page 25]
Internet-Draft Handover Keys Using AAA October 2005
extracted from the NAI, and the HMK is the shared key between MN and
its RADIUS server.
The RADIUS server answers to the AR by sending a RADIUS-Access-
Accept message.
RADIUS-Access-Accept{
HK-MN-AR-Key (HK1)
HK-MN-AR-Key-Lifetime (HK1's lifetime)
HK-AAA-MN-Nonce (Nonce generated by AAAH)
HK-MN-AAA-SHASH (PRF(HMK, Nonce || Lifetime HK1)
Message Authenticator(80)}
If the authentication failed (wrong MN-AAA MAC), the AAAH generates a
RADIUS Access-Reject message.
The AR receives the message, extracts the HK1 and its associated
lifetime and creates the HKResp containing the Nonce AAA-MN, the
HK1's lifetime and the signed hash.
Thus, this proposal needs the following attributes to be defined:
o HK-MN-NAI
o HK-MN-MSGID-SEQ
o HK-MN-AAA Authenticator
o HK-MN-AR-Key (HK1)
o HK-MN-AR-Key-Lifetime (HK1's lifetime)
o HK-AAA-MN-Nonce (Nonce generated by AAAH)
o HK-MN-AR-SHASH (PRF(HMK, Nonce || Lifetime HK1)
It may be possible to reuse some attributes defined for Mobile IPv4
here - such as the MIP-MN-NAI or the MIP-MN-AAA-Authenticator
attribute - this possibility will be explored in later revisions of
this document.
Narayanan, et al. Expires April 24, 2006 [Page 26]
Internet-Draft Handover Keys Using AAA October 2005
Appendix C. Diameter Handover Key Application
To support this proposal a new Diameter application may need to be
defined. It needs to be determined if a re-use of the Diameter
NASREQ application is feasible with new attributes defined. The
intent of this section is to provide an overview of what is needed to
support the proposal. Note that the proposal assumes that AAA
exchanges between AR and the AAAH server is protected. Use of IPsec
or TLS is recommended for this purpose. In this section, we describe
needed Diameter messages and AVPs. A more detailed version of this
section will be provided in the near future.
C.1. New Messages
As for RADIUS, the AR will act as a AAA client and thus as a Diameter
client. However, new Diameter command could be defined for this
proposal:
o HK-Mobile-Node-Request (HMR) - Command Code (TBD) and 'R' bit set
in Command Flags field. This message is sent by AR acting as a
Diameter client to a AAAH in order to request the handover key for
the mobile node. The AR uses the information provided in the
HKreq to construct the needed AVPs.
o HK-Mobile-Node-Answer (HMA) - The HK-Mobile-Node-Answer (HMA)
indicated by the Command-Code field set to TBD and 'R' bit cleared
in Command Flags field is sent by the AAAH in response to a HMR
message.
For backward compatibility, attributes defined for RADIUS can be
reused within this new Diameter Application.
C.3. Diameter Flow of Messages
The AAA exchanges between AR and its home AAA server is basically the
same as for RADIUS. However, the Diameter application will benefit
from all of the advantages that Diameter provides.
Narayanan, et al. Expires April 24, 2006 [Page 27]
Internet-Draft Handover Keys Using AAA October 2005
MN AR AAAH Server
| HKReq. | |
| ---------> | |
| | HMR |
| | ----------------------> |
| | HMA |
| | <----------------------- |
| HKResp. | |
| <--------- | |
Figure 8: Diameter Handover Key Messaging
Narayanan, et al. Expires April 24, 2006 [Page 28]
Internet-Draft Handover Keys Using AAA October 2005
Authors' Addresses
Vidya Narayanan
Motorola
1301 E. Algonquin Road
Schaumburg, IL 60196
US
Email: vidya@motorola.com
Narayanan Venkitaraman
Motorola Labs
1301 E. Algonquin Road
Schaumburg, IL 60196
US
Email: narayanan.venkitaraman@motorola.com
Hannes Tschofenig
Siemens
Otto-Hahn-Ring 6
Munich, Bavaria 81739
Germany
Email: Hannes.Tschofenig@siemens.com
Gerardo Giaretta
TILab
via G. Reiss Romoli, 274
TORINO 10148
Italy
Email: gerardo.giaretta@telecomitalia.it
Julien Bournelle
GET/INT
9 rue Charles Fourier
Evry 91011
France
Email: julien.bournelle@int-evry.fr
Narayanan, et al. Expires April 24, 2006 [Page 29]
Internet-Draft Handover Keys Using AAA October 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.
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 (2005). 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.
Narayanan, et al. Expires April 24, 2006 [Page 30]