to the mobile node. When it is necessary to protect the session keys
and SPIs from un-trusted Diameter agents, end-to-end security
mechanisms such as TLS or IPSec are required to eliminate all
Diameter Agents between the FA or HA and the AAAH, as outlined above.
In [MIPKEYS], the mobility security associations are established via
nonces transmitted to the mobile node via Mobile IPv4. To provide
the nonces, the AAAH must generate a random [RANDOM] value of at
least 128 bits [MIPKEYS]. The mobile node then uses the nonce to
derive the MN-HA and MN-FA session keys.
More details of the MN-HA and the MN-FA session key creation
procedures are found in [MIPKEYS].
The hashing algorithm used by the mobile node to construct the
session key has to be the same as that used by the AAAH in the
session key generation procedure. The AAAH therefore indicates the
algorithm used along with the nonce.
The FA-HA and HA-FA session key is shared between the FA and HA. The
AAAH generates a random [RANDOM] value of at least 128 bits for use
as this session key.
See sections 9 for details about the format of the AVPs used to
transport the session keys.
8.3. Distributing the Mobile-Home Session Key
If the mobile node does not have an MN-HA session key, then the AAAH
is likely to be the only trusted entity that is available to the
mobile node. Thus, the AAAH has to generate the MN-HA session key.
The distribution of the HA-MN (session) key to the HA is specified in
sections 1.2 and 3.4. The HA and AAAH establish a security
association (IPSec or TLS) and transport the key over it. If no
security association exists between the AAAH and the home agent and a
security association cannot be established, the AAAH MUST return a
Result-Code AVP with DIAMETER_ERROR_END_TO_END_MIP_KEY_ENCRYPTION.
The AAAH also has to arrange for the key to be delivered to the
mobile node. Unfortunately, the AAAH only knows about Diameter
messages and AVPs, and the mobile node only knows about Mobile IPv4
messages and extensions [MOBILEIP]. For this purpose, AAAH includes
the MN-HA MIP-nonce AVP into a MIP-MN-to-HA-MSA AVP, which is added
to the HAR (for FA COA style Mobile IPv4) or to the AMA (for
collocated COA-style Mobile IPv4 messages) and delivered either to a
local home agent or a home agent in the visited network. Note that
the mobile node will use the nonce to create the MN-HA session key by
using the MN-AAA key it shares with the AAAH [MIPKEYS]. The AAAH has
to rely on the home agent (which also understands Diameter) to
transfer the nonce into a Mobile IPv4 "Generalized MN-HA Key
Generation Nonce Reply" extension [MIPKEYS] in the Registration Reply
message. The HA includes the SPIs proposed by the mobile node and
the home agent in the "Generalized MN-HA Key Generation Nonce
Request" extension. The home agent can format the Reply message and
extensions correctly for eventual delivery to the mobile node. The
resulting Registration Reply is added to the HAA’s MIP-Reg-Reply AVP.
The AAAH parses the HAA message, transforms it into an AMA message
containing an MIP-Reg-Reply AVP, and sends the AMA message to the
foreign agent. The foreign agent then uses that AVP to recreate a
Registration Reply message containing the "Generalized MN-HA Key
Generation Nonce Reply" extension for delivery to the mobile node.
In summary, the AAAH generates the MN-HA nonce, which is added to the
MIP-MN-to-HA-MSA AVP, and a session key, which is added to the
MIP-HA-to-MN-MSA AVP. These AVPs are delivered to the home agent in
HAR or AMA messages. The home agent retains the session key for its
own use and copies the nonce from the MIP-MN-to-HA-MSA AVP into a
"Generalized MN-HA Key Generation Nonce Reply" extension, which is
appended to the Mobile IPv4 Registration Reply message. This
Registration Reply message MUST also include the HA-MN authentication
extension, which is created by using the newly allocated HA-MN
session key. The home agent then includes the Registration Reply
message and extensions into a MIP-Reg-Reply AVP as part of the HAA
message to be sent back to the AAA server.
The key derived by the MN from the MN-HA session nonce is identical
to the HA-MN session key provided to the HA.
8.4. Distributing the Mobile-Foreign Session Key
The MN-FA session nonce is also generated by AAAH (upon request) and
added to the MIP-MN-to-FA-MSA AVP, which is added to the HAR and
copied by the home agent into a "Generalized MN-FA Key Generation
Nonce Reply" extension [MIPKEYS] of the Mobile IPv4 Registration
Reply message. The HA also includes the SPIs proposed by the mobile
node and foreign agent in the "Generalized MN-FA Key Generation Nonce
Request" extension. The AAAH includes the FA-MN session key in the
MIP-FA-to-MN-MSA AVP in the AMA, to be used by the foreign agent in
the computation of the FA-MN authentication extension.
The key derived by the MN from the MN-FA session nonce is identical
to the FA-MN session key provided to the FA.
8.5. Distributing the Foreign-Home Session Key
If the foreign agent requests an FA-HA session key, it also includes
a MIP-HA-to-FA-SPI AVP in the AMR to convey the SPI to be used by the
home agent for this purpose. The AAAH generates the FA-HA session
key, which is identical to the HA-FA session key, and distributes
that to both the HA and the FA over respective security associations
by using the MIP-HA-to-FA-MSA and MIP-FA-to-HA-MSA AVPs. The HA
conveys the SPI that the FA MUST use in the HAA; this is similar to
the way in which the FA conveys that the SPI that the HA MUST use in
the AMR. The AAAH later includes these SPIs in the MIP-FA-HA-MSA and
MIP-HA-FA-MSA AVPs, respectively, along with the session key.
Refer to Figures 2, 3, 4, and 6 for the messages involved.
Note that if multiple MNs are registered on the same FA and HA pair,
then multiple mobility security associations would be distributed.
However, only one is required to protect the Mobile IP control
traffic between FA and HA. This creates an unacceptable level of
state (i.e., to store the two SPIs and shared key for each FA-HA
mobility security association). To improve scalability, the FA and
HA may discard FA-HA mobility security associations prior to the time
when they actually expire. However, if a proper discard policy is
not chosen, this could cause Mobile IP messages in transit or waiting
in queues for transmission to fail authentication.
The FA MUST always use the FA-HA security association with the latest
expiry time when computing authentication extensions on outgoing
messages. The FA MAY discard HA-FA mobility security associations 10
seconds after a new HA-FA mobility security association arrives with
a later expiry time.
The HA SHOULD use the HA-FA mobility security association that has
the latest expiry time when computing authentication extensions in
outgoing messages. However, when the HA receives a new HA-FA
mobility security association with a later expiry time, the HA SHOULD
wait 4 seconds for the AMA to propagate to the FA before using the
new association. Note that the HA always uses the mobility security
association from the HAR when constructing the Mobile IP Registration
Reply in the corresponding HAA. The HA MAY discard an FA-HA mobility
security association once it receives a message authenticated by a
FA-HA mobility security association with a later expiry time.
9. Key Distribution AVPs
The Mobile-IP protocol defines a set of mobility security
associations shared between the mobile node, foreign agent, and home
agent. These three mobility security associations (MN-HA, MN-FA, and
FA-HA) are dynamically created by the AAAH and have previously been
described in sections 3.4 and 8. AAA servers supporting the Diameter
Mobile IP Application MUST implement the key distribution AVPs
defined in this document.
The names of the key distribution AVPs indicate the two entities
sharing the mobility security association. The first named entity in
the AVP name will use the mobility security association to create
authentication extensions using the given SPI and key. The second
named entity in the AVP name will use the mobility security
association to verify the authentication extensions of received
Mobile IP messages.
For instance, the MIP-MN-to-HA-MSA AVP contains the MN-HA nonce,
which the mobile node will use to derive the MN-HA Key, and the
MIP-HA-to-MN-MSA AVP contains the MN-HA key for the home agent. Note
that mobility security associations are unidirectional; however, this
application delivers only one key that is shared between both
unidirectional security associations that exist between two peers.
The security considerations of using the same key in each direction
are given in section 13. The SPIs are, however, unique to each
unidirectional security association and are chosen by the peer that
will receive the Mobile IP messages authenticated with that security
association.
The following table describes the Diameter AVPs defined in the Mobile
IP application and their AVP Code values, types, and possible flag
values.
+--------------------------+
| AVP Flag Rules |
|----+-----+----+-----|----+
AVP Section | | |SHLD| MUST|MAY |
Attribute Name Code Defined Value Type |MUST| MAY | NOT| NOT|Encr|
-----------------------------------------|----+-----+----+-----|----|
MIP-FA-to-HA-SPI 318 9.11 Unsigned32 | M | P | | V | Y |
MIP-FA-to-MN-SPI 319 9.10 Unsigned32 | M | P | | V | Y |
MIP-HA-to-FA-SPI 323 9.14 Unsigned32 | M | P | | V | Y |
MIP-MN-to-FA-MSA 325 9.5 Grouped | M | P | | V | Y |
MIP-FA-to-MN-MSA 326 9.1 Grouped | M | P | | V | Y |
MIP-FA-to-HA-MSA 328 9.2 Grouped | M | P | | V | Y |
MIP-HA-to-FA-MSA 329 9.3 Grouped | M | P | | V | Y |
MIP-MN-to-HA-MSA 331 9.6 Grouped | M | P | | V | Y |
MIP-HA-to-MN-MSA 332 9.4 Grouped | M | P | | V | Y |
MIP-Nonce 335 9.12 OctetString| M | P | | V | Y |
MIP-Session-Key 343 9.7 OctetString| M | P | | V | Y |
MIP-Algorithm- 345 9.8 Enumerated | M | P | | V | Y |
Type
MIP-Replay-Mode 346 9.9 Enumerated | M | P | | V | Y |
MIP-MSA-Lifetime 367 9.13 Unsigned32 | M | P | | V | Y |
9.1. MIP-FA-to-MN-MSA AVP
The MIP-FA-to-MN-MSA AVP (AVP Code 326) is of type Grouped and
contains the FA-MN session key. This AVP is conveyed to the FA in an
AMA message. The MN allocates the MIP-FA-to-MN-SPI. The FA creates
an FA-MN authentication extension by using the session key and
algorithm, and the MN verifies that extension by using the same
session key and algorithm. The data field of this AVP has the
following ABNF grammar:
MIP-FA-to-MN-MSA ::= < AVP Header: 326 >
{ MIP-FA-to-MN-SPI }
{ MIP-Algorithm-Type }
{ MIP-Session-Key }
* [ AVP ]
9.2. MIP-FA-to-HA-MSA AVP
The MIP-FA-to-HA-MSA AVP (AVP Code 328) is of type Grouped and
contains the FA-HA session key. This AVP is conveyed to the FA in an
AMA message. The HA allocates the MIP-FA-to-HA-SPI. The FA creates
the FA-HA authentication extension by using the session key and
algorithm, and the HA verifies that extension by using the same key
and algorithm. The AVP’s data field has the following ABNF grammar:
MIP-FA-to-HA-MSA ::= < AVP Header: 328 >
{ MIP-FA-to-HA-SPI }
{ MIP-Algorithm-Type }
{ MIP-Session-Key }
* [ AVP ]
9.3. MIP-HA-to-FA-MSA AVP
The MIP-HA-to-FA-MSA AVP (AVP Code 329) is of type Grouped and
contains the Home Agent’s session key, which it shares with the
foreign agent. This AVP is conveyed to the HA in an HAR message.
The FA allocates the MIP-HA-to-FA-SPI. The HA creates the HA-FA
authentication extension by using the session key and algorithm, and
the FA verifies that extension by using the same session key and
algorithm. The AVP’s data field has the following ABNF grammar:
MIP-HA-to-FA-MSA ::= < AVP Header: 329 >
{ MIP-HA-to-FA-SPI }
{ MIP-Algorithm-Type }
{ MIP-Session-Key }
* [ AVP ]
9.4. MIP-HA-to-MN-MSA AVP
The MIP-HA-to-MN-MSA AVP (AVP Code 332) is of type Grouped, and
contains the HA-MN session key. This AVP is conveyed to the HA in an
HAR for FA COA Mobile IPv4 and in an AMA for collocated COA Mobile
IPv4. The MN allocates the MIP-HA-to-MN-SPI. The HA creates the
HA-MN authentication extension by using the session key and
algorithm, and the MN verifies that extension by using the same key
and algorithm. The AVP’s field has the following ABNF grammar:
MIP-HA-to-MN-MSA ::= < AVP Header: 332 >
{ MIP-HA-to-MN-SPI }
{ MIP-Algorithm-Type }
{ MIP-Replay-Mode }
{ MIP-Session-Key }
* [ AVP ]
9.5. MIP-MN-to-FA-MSA AVP
The MIP-MN-to-FA-MSA AVP (AVP Code 325) is of type Grouped, and
contains the MN-FA session nonce, which the mobile node uses to
derive the MN-FA session key. This AVP is conveyed to the HA in an
HAR message. The FA allocates the MIP-MN-to-FA-SPI. The MN creates
the MN-FA authentication extension by using the session key and
algorithm, and the FA verifies that extension using the same key and
algorithm.
The home agent uses this AVP in the construction of the Mobile IP
"Generalized MN-FA Key Generation Nonce Reply" extension [MIPKEYS].
MIP-MN-to-FA-MSA ::= < AVP Header: 325 >
{ MIP-MN-FA-SPI }
{ MIP-Algorithm-Type }
{ MIP-nonce }
* [ AVP ]
9.6. MIP-MN-to-HA-MSA AVP
The MIP-MN-to-HA-MSA AVP (AVP Code 331) is of type Grouped and
contains the MN-HA session nonce, which the mobile node uses to
derive the MN-HA session key. This AVP is conveyed to the HA in an
HAR message for FA COA Mobile IPv4 and in an AMR for collocated
Mobile IPv4. The HA allocates the MIP-MN-to-HA-SPI. The MN creates
the MN-FA authentication extension using the session key and
algorithm, and the HA verifies that extension using the same session
key and algorithm.
The Home Agent uses this AVP in the construction of the Mobile IP
"Generalized MN-HA Key Generation Nonce Reply" extension [MIPKEYS].
MIP-MN-to-HA-MSA ::= < AVP Header: 331 >
{ MIP-MN-HA-SPI }
{ MIP-Algorithm-Type }
{ MIP-Replay-Mode }
{ MIP-nonce }
* [ AVP ]
9.7. MIP-Session-Key AVP
The MIP-Session-Key AVP (AVP Code 343) is of type OctetString and
contains the Session Key for the associated Mobile IPv4
authentication extension. The HAAA selects the session key.
9.8. MIP-Algorithm-Type AVP
The MIP-Algorithm-Type AVP (AVP Code 345) is of type Enumerated and
contains the Algorithm identifier for the associated Mobile IPv4
authentication extension. The HAAA selects the algorithm type. The
following values are currently defined:
2 HMAC-SHA-1 [HMAC]
9.9. MIP-Replay-Mode AVP
The MIP-Replay-Mode AVP (AVP Code 346) is of type Enumerated and
contains the replay mode the Home Agent for authenticating the mobile
node. The HAAA selects the replay mode.
The following values are supported (see [MOBILEIP] for more
information):
1 None
2 Timestamps
3 Nonces
9.10. MIP-FA-to-MN-SPI AVP
The MIP-FA-to-MN-SPI AVP (AVP Code 319) is of type Unsigned32, and it
contains the Security Parameter Index the FA that and MN use to refer
to the FA-MN mobility security association. The MN allocates the
SPI, and it MUST NOT have a value between zero (0) and 255, which is
the reserved namespace defined in [MOBILEIP].
9.11. MIP-FA-to-HA-SPI AVP
The MIP-FA-to-HA-SPI AVP (AVP Code 318) is of type Unsigned32 and
contains the Security Parameter Index the FA and HA use to refer to
the FA-HA mobility security association. The HA allocates the SPI,
and it MUST NOT have a value between zero (0) and 255, which is the
reserved namespace defined in [MOBILEIP].
9.12. MIP-Nonce AVP
The MIP-Nonce AVP (AVP Code 335) is of type OctetString and contains
the nonce sent to the mobile node for the associated authentication
extension. The mobile node follows the procedures in [MIPKEYS] to
generate the session key used to authenticate Mobile IPv4
registration messages. The HAAA selects the nonce.
9.13. MIP-MSA-Lifetime AVP
The MIP-MSA-Lifetime AVP (AVP Code 367) is of type Unsigned32 and
represents the period of time (in seconds) for which the session key
or nonce is valid. The associated session key or nonce, as the case
may be, MUST NOT be used if the lifetime has expired; if the session
key or nonce lifetime expires while the session to which it applies
is still active, either the session key or nonce MUST be changed or
the association Mobile IPv4 session MUST be terminated.
9.14. MIP-HA-to-FA-SPI AVP
The MIP-HA-to-FA-SPI AVP (AVP Code 323) is of type Unsigned32 and
contains the Security Parameter Index the HA and FA use to refer to
the HA-FA mobility security association. The FA allocates the SPI,
and it MUST NOT have a value between zero (0) and 255, which is the
reserved namespace defined in [MOBILEIP].
10. Accounting AVPs
10.1. Accounting-Input-Octets AVP
The Accounting-Input-Octets AVP (AVP Code 363) is of type Unsigned64,
and contains the number of octets in IP packets received from the
user. This AVP MUST be included in all Accounting-Request messages
and MAY be present in the corresponding Accounting-Answer messages as
well.
10.2. Accounting-Output-Octets AVP
The Accounting-Output-Octets AVP (AVP Code 364) is of type Unsigned64
and contains the number of octets in IP packets sent to the user.
This AVP MUST be included in all Accounting-Request messages and MAY
be present in the corresponding Accounting-Answer messages as well.
10.3. Acct-Session-Time AVP
The Acct-Time AVP (AVP Code 46) is of type Unsigned32 and indicates
the length of the current session in seconds. This AVP MUST be
included in all Accounting-Request messages and MAY be present in the
corresponding Accounting-Answer messages as well.
10.4. Accounting-Input-Packets AVP
The Accounting-Input-Packets (AVP Code 365) is of type Unsigned64 and
contains the number of IP packets received from the user. This AVP
MUST be included in all Accounting-Request messages and MAY be
present in the corresponding Accounting-Answer messages as well.
10.5. Accounting-Output-Packets AVP
The Accounting-Output-Packets (AVP Code 366) is of type Unsigned64
and contains the number of IP packets sent to the user. This AVP
MUST be included in all Accounting-Request messages and MAY be
present in the corresponding Accounting-Answer messages as well.
10.6. Event-Timestamp AVP
The Event-Timestamp (AVP Code 55) is of type Time and MAY be included
in an Accounting-Request message to record the time at which this
event occurred on the mobility agent, in seconds since January 1,
1970, 00:00 UTC.
11. AVP Occurrence Tables
The following tables present the AVPs defined in this document and
their occurrences in Diameter messages. Note that AVPs that can only
be present within a Grouped AVP are not represented in this table.
The table uses the following symbols:
0 The AVP MUST NOT be present in the message.
0+ Zero or more instances of the AVP MAY be present in the
message.
0 - 1 Zero or one instance of the AVP MAY be present in the
message.
1 One instance of the AVP MUST be present in the message.
11.1. Mobile IP Command AVP Table
The table in this section is limited to the Command Codes defined in
this specification.
+-----------------------+
| Command-Code |
|-----+-----+-----+-----+
Attribute Name | AMR | AMA | HAR | HAA |
------------------------------|-----+-----+-----+-----+
Authorization-Lifetime | 0-1 | 0-1 | 1 | 0 |
Auth-Application-Id | 1 | 1 | 1 | 1 |
Auth-Session-State | 0-1 | 0-1 | 1 | 0 |
Acct-Multi-Session-Id | 0-1 | 0-1 | 0 | 0-1 |
Destination-Host | 0-1 | 0 | 0-1 | 0 |
Destination-Realm | 1 | 0 | 1 | 0 |
Error-Message | 0 | 0-1 | 0 | 0-1 |
Error-Reporting-Host | 0 | 0-1 | 0 | 0-1 |