tech-invite   World Map     

3GPP     Specs     Glossaries     Architecture     IMS     UICC       IETF     RFCs     Groups     SIP     ABNFs       Search

RFC 4004

 
 
 

Diameter Mobile IPv4 Application

Part 3 of 3, p. 38 to 53
Prev RFC Part

 


prevText      Top      Up      ToC       Page 38 
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.

Top      Up      ToC       Page 39 
                                            +--------------------------+
                                            |       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:

Top      Up      ToC       Page 40 
         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.

Top      Up      ToC       Page 41 
   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]

Top      Up      ToC       Page 42 
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.

Top      Up      ToC       Page 43 
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.

Top      Up      ToC       Page 44 
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 |
      MIP-Candidate-Home-Agent-Host | 0-1 | 0   | 0-1 | 0   |
      MIP-Home-Agent-Host           | 0-1 | 0   | 0-1 | 0   |
      MIP-Originating-Foreign-AAA   | 0-1 | 0   | 0-1 | 0   |
      MIP-FA-Challenge              | 0-1 | 0   | 0   | 0   |
      MIP-FA-to-MN-MSA              | 0   | 0-1 | 0   | 0   |
      MIP-FA-to-HA-MSA              | 0   | 0-1 | 0   | 0   |
      MIP-HA-to-FA-MSA              | 0   | 0   | 0-1 | 0   |
      MIP-HA-to-MN-MSA              | 0   | 0-1 | 0-1 | 0   |

Top      Up      ToC       Page 45 
      MIP-MN-to-FA-MSA              | 0   | 0   | 0-1 | 0   |
      MIP-MN-to-HA-MSA              | 0   | 0-1 | 0-1 | 0   |
      MIP-FA-to-HA-SPI              | 0   | 0   | 0   | 0-1 |
      MIP-HA-to-FA-SPI              | 0   | 0   | 0   | 0-1 |

      MIP-FA-to-MN-SPI              | 0   | 0   | 0   | 0-1 |
      MIP-MN-to-FA-SPI              | 0   | 0   | 0   | 0-1 |

      MIP-HA-to-MN-SPI              | 0   | 0   | 0   | 0-1 |
      MIP-MN-to-HA-SPI              | 0   | 0   | 0   | 0-1 |
      MIP-Feature-Vector            | 0-1 | 0-1 | 1   | 0   |
      MIP-Filter-Rule               | 0   | 0+  | 0+  | 0   |
      MIP-Home-Agent-Address        | 0-1 | 0-1 | 0-1 | 0-1 |
      MIP-MSA-Lifetime              | 0   | 0-1 | 0-1 | 0   |
      MIP-MN-AAA-Auth               | 1   | 0   | 0   | 0   |
      MIP-Mobile-Node-Address       | 0-1 | 0-1 | 0-1 | 0-1 |
      MIP-Reg-Reply                 | 0   | 0-1 | 0   | 0-1 |
      MIP-Reg-Request               | 1   | 0   | 1   | 0   |
      Origin-Host                   | 1   | 1   | 1   | 1   |
      Origin-Realm                  | 1   | 1   | 1   | 1   |
      Origin-State-Id               | 0-1 | 0-1 | 0-1 | 0-1 |
      Proxy-Info                    | 0+  | 0+  | 0+  | 0+  |
      Redirect-Host                 | 0   | 0+  | 0   | 0+  |
      Redirect-Host-Usage           | 0   | 0-1 | 0   | 0-1 |
      Redirect-Max-Cache-Time       | 0   | 0-1 | 0   | 0-1 |
      Result-Code                   | 0   | 1   | 0   | 1   |
      Re-Auth-Request-Type          | 0   | 0-1 | 0   | 0   |
      Route-Record                  | 0+  | 0   | 0+  | 0   |
      Session-Id                    | 1   | 1   | 1   | 1   |
      User-Name                     | 1   | 0-1 | 1   | 0-1 |
      ------------------------------|-----+-----+-----+-----|

Top      Up      ToC       Page 46 
11.2.  Accounting AVP Table

   The table in this section is used to represent which AVPs defined in
   this document are to be present in the Accounting messages, as
   defined in [DIAMBASE].

                                           +-------------+
                                           | Command-Code|
                                           |------+------+
      Attribute Name                       |  ACR |  ACA |
      -------------------------------------|------+------+
      Accounting-Input-Octets              |  1   |  0-1 |
      Accounting-Input-Packets             |  1   |  0-1 |
      Accounting-Output-Octets             |  1   |  0-1 |
      Accounting-Output-Packets            |  1   |  0-1 |
      Acct-Multi-Session-Id                |  1   |  0-1 |
      Acct-Session-Time                    |  1   |  0-1 |
      MIP-Feature-Vector                   |  1   |  0-1 |
      MIP-Home-Agent-Address               |  1   |  0-1 |
      MIP-Mobile-Node-Address              |  1   |  0-1 |
      Event-Timestamp                      | 0-1  |   0  |
      -------------------------------------|------+------+

12.  IANA Considerations

   This section contains the namespaces that have either been created in
   this specification or had their values assigned to existing
   namespaces managed by IANA.

12.1.  Command Codes

   This specification assigns the values 260 and 262 from the Command
   Code namespace defined in [DIAMBASE].  See section 5 for the
   assignment of the namespace in this specification.

12.2.  AVP Codes

   This specification assigns the values 318 - 348 and 363 - 367 from
   the AVP Code namespace defined in [DIAMBASE].  See sections 7, 9, and
   10 for the assignment of the namespace in this specification.

12.3.  Result-Code AVP Values

   This specification assigns the values 4005 - 4008 and 5024 - 5025
   from the Result-Code AVP (AVP Code 268) value namespace defined in
   [DIAMBASE].  See section 6 for the assignment of the namespace in
   this specification.

Top      Up      ToC       Page 47 
12.4.  MIP-Feature-Vector AVP Values

   There are 32 bits in the MIP-Feature-Vector AVP (AVP Code 337) that
   are available for assignment.  This document assigns bits 1 - 9, as
   listed in section 7.5.  The remaining bits should only be assigned
   via Standards Action [IANA].

12.5.  MIP-Algorithm-Type AVP Values

   As defined in section 9.8, the MIP-Algorithm-Type AVP (AVP Code 345)
   defines the value 2.  All remaining values, except zero, are
   available for assignment via Designated Expert [IANA].

12.6.  MIP-Replay-Mode AVP Values

   As defined in section 9.9, the MIP-Replay-Mode AVP (AVP Code 346)
   defines the values 1 - 3.  All remaining values, except zero, are
   available for assignment via Designated Expert [IANA].

12.7.  Application Identifier

   This specification uses the value two (2) to the Application
   Identifier namespace defined in [DIAMBASE].  See section 4 for more
   information.

13.  Security Considerations

   This specification describes a Mobile IPv4 Diameter Application for
   authenticating and authorizing a Mobile IPv4 mobile node.  The
   authentication algorithm used is dependent on the transforms used
   within the Mobile IPv4 protocol, and [MIPCHAL].  This specification,
   in conjunction with [MIPKEYS], also defines a method by which the
   home Diameter server can create and distribute session keys and
   nonces for use in authenticating and integrity-protecting Mobile IPv4
   registration messages [MOBILEIP].  The key distribution is
   asymmetric, as communication with the mobile node occurs via the
   Mobile IPv4 protocol [MIPKEYS, MOBILEIP], where as communication to
   the Home Agent and Foreign Agent occurs via the Diameter protocol.
   Where untrusted Diameter agents are present, end-to-end security MUST
   be used.  The end-to-end security takes the form of TLS or IPSec
   security associations between the AAAH and the FA and between the
   AAAH and the HA.  These connections will be authenticated with the
   use of public keys and certificates; however, the identities that
   appear in the certificates must be authorized and bound to a
   particular Mobile IPv4 Diameter session before the AAAH can safely
   begin distribution of keys.

Top      Up      ToC       Page 48 
   Note that the direct connections are established as a result of
   Diameter redirect messages.  For example, in Figure 3, the FA gets a
   redirect response containing the Redirect-Host AVP of the AAAH.  This
   is the identity that should be matched against the certificate
   presented by the AAAH when the secure connection is established.  In
   this case, the network of Diameter proxies and redirect agents is
   trusted with the task of returning the correct AAAH identity to the
   FA.

   The AAAH must also make an authorization decision when the FA
   establishes the connection.  If the AAAH and the redirect server are
   one and the same, then the AAAH may have observed and noted the
   original AMR message that contained the identity of the FA and so may
   authorize the establishment of a TLS or IPSec connection from the
   same entity.  Otherwise, the AAAH would need to maintain a list of
   all authorized visited domains (roaming partners) and authorize TLS
   or IPSec connections based on this list.  Note that establishment of
   the connection is only the first step, and the AAAH has another
   opportunity to deny service upon receipt of the AMR message itself.
   At this step, the AAAH can check the internal AVPs of the AMR to
   ensure that the FA is valid; for example, it can check that the
   Mobile IP COA is equal to the IP address used as the endpoint of the
   TLS or IPSec connection.  However, such a policy would prevent the FA
   from using different interfaces for AAA and Mobile IP tunnel packets
   and may not be desirable in every deployment situation.

   A similar set of considerations applies to the connection between
   AAAH and HA when those entities are in different administrative
   domains.  However, here the roles are reversed because it is the AAAH
   that contacts the HA via the HAR.  The identity of the candidate HA
   is given to the AAAH in the AMR, and the AAAH should expect to
   receive the same identity in the public key certificates during TLS
   or IPSec negotiation.  The HA may authorize individual connections by
   acting as its own redirect server, or it may maintain a list of
   trusted roaming partners.

   This application creates and distributes a single session key for
   each pair of MSAs between two entities; e.g., the same session key is
   used for the MN-HA MSA and the HA-MN MSA.  This is safe to do from a
   security perspective, as the session keys are only used with keyed
   hash functions to generate authenticator values that protect the
   integrity of each Mobile IP control message.  Mobile IP messages have
   built-in replay protection with the use of timestamps or nonces
   [MOBILEIP], and, due to the nature of the protocol, requests are
   always different bitwise from responses, at least in the message type
   code.  This avoids problems that might arise in other situations

Top      Up      ToC       Page 49 
   where an attacker could mount a replay or reflection attack if the
   same key were used (for example) to encrypt otherwise unprotected
   traffic on more than one connection leg in the network.

   Nonces are sent to the mobile node, which are used to generate the
   session keys via the HMAC-SHA-1 one-way function.  Because the nonces
   and authentication extensions may be observed by anyone with access
   to a clear-text copy of the Registration Reply, the pre-shared key
   between the mobile node and the home Diameter server would be
   vulnerable to an offline dictionary attack if it did not contain
   enough entropy.  To prevent this, the pre-shared key between the
   mobile node and the home Diameter server SHOULD be a randomly chosen
   quantity of at least 96 bits.

   Because the session key is determined by the long-term secret and the
   nonce, the nonce SHOULD be temporally and globally unique; if the
   nonce were to repeat, then so would the session key.  To prevent
   this, a nonce is strongly recommended to be a random [RANDOM] value
   of at least 128 bits.  The long-term secret between the MN and AAAH
   MUST be refreshed periodically, to guard against recovery of the
   long-term secret due to nonce reuse or other factors.  This is
   accomplished by using out-of-band mechanisms, which are not specified
   in this document.

   Note that it is not recommended to set the MIP-MSA-Lifetime AVP value
   to zero, as keeping session keys for a long time (no refresh)
   increases the level of vulnerability.

14.  References

14.1.  Normative References

   [ABNF]         Crocker, D. and P. Overell, "Augmented BNF for Syntax
                  Specifications: ABNF", RFC 2234, November 1997.

   [DIAMBASE]     Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and
                  J. Arkko, "Diameter Base Protocol", RFC 3588,
                  September 2003.

   [IANA]         Narten, T. and H. Alvestrand, "Guidelines for Writing
                  an IANA Considerations Section in RFCs", BCP 26, RFC
                  2434, October 1998.

   [MOBILEIP]     Perkins, C., "IP Mobility Support for IPv4", RFC 3344,
                  August 2002.

Top      Up      ToC       Page 50 
   [MIPCHAL]      Perkins, C. and P. Calhoun, "Mobile IPv4
                  Challenge/Response Extensions", RFC 3012, November
                  2000.

   [NAI]          Aboba, B. and M. Beadles, "The Network Access
                  Identifier", RFC 2486, January 1999.

   [HMAC]         Krawczyk, H., Bellare, M., and R. Canetti, "HMAC:
                  Keyed-Hashing for Message Authentication", RFC 2104,
                  February 1997.

   [MIPKEYS]      Perkins, C. and P. Calhoun, "Authentication,
                  Authorization, and Accounting (AAA) Registration Keys
                  for Mobile IP", RFC 3957, March 2005.

   [AAANAI]       Johansson, F. and T. Johansson, "Mobile IPv4 Extension
                  for Carrying Network Access Identifiers", RFC 3846,
                  June 2004.

   [IPSEC]        Kent, S. and R. Atkinson, "Security Architecture for
                  the Internet Protocol", RFC 2401, November 1998.

   [TLS]          Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen,
                  J., and T. Wright, "Transport Layer Security (TLS)
                  Extensions", RFC 3546, June 2003.

   [KEYWORDS]     Bradner, S., "Key words for use in RFCs to Indicate
                  Requirement Levels", BCP 14, RFC 2119, March 1997.

14.2.  Informative References

   [MIPREQ]       Glass, S., Hiller, T., Jacobs, S., and C. Perkins,
                  "Mobile IP Authentication, Authorization, and
                  Accounting Requirements", RFC 2977, October 2000.

   [CDMA2000]     Hiller, T., Walsh, P., Chen, X., Munson, M., Dommety,
                  G., Sivalingham, S., Lim, B., McCann, P., Shiino, H.,
                  Hirschman, B., Manning, S., Hsu, R., Koo, H., Lipford,
                  M., Calhoun, P., Lo, C., Jaques, E., Campbell, E., Xu,
                  Y., Baba, S., Ayaki, T., Seki, T., and A. Hameed,
                  "CDMA2000 Wireless Data Requirements for AAA", RFC
                  3141, June 2001.

   [EVALROAM]     Aboba, B. and G. Zorn, "Criteria for Evaluating
                  Roaming Protocols", RFC 2477, January 1999.

   [MIPNAI]       Calhoun, P. and C. Perkins, "Mobile IP Network Access
                  Identifier Extension for IPv4", RFC 2794, March 2000.

Top      Up      ToC       Page 51 
   [RANDOM]       Eastlake, D., 3rd, Schiller, J., and S. Crocker,
                  "Randomness Requirements for Security", BCP 106, RFC
                  4086, June 2005.

15.  Acknowledgements

   The authors would like to thank Nenad Trifunovic, Haseeb Akhtar, and
   Pankaj Patel for their participation in the pre-IETF Document Reading
   Party; Erik Guttman for his very useful proposed text; and to Fredrik
   Johansson, Martin Julien, and Bob Kopacz for their very useful
   contributed text.

   The authors would also like to thank the participants of 3GPP2's
   TSG-X working group for their valuable feedback, and the following
   people for their contribution in the development of the protocol:
   Kevin Purser, Thomas Panagiotis, Mark Eklund, Paul Funk, Michael
   Chen, Henry Haverinen, and Johan Johansson.  General redirect server
   text due to Pasi Eronen was borrowed from Diameter-EAP.

   Pat Calhoun would like to thank Sun Microsystems, as most of the
   effort put into this document was done while he was in their employ.

Authors' Addresses

   Questions about this memo can be directed to:

   Pat Calhoun
   Cisco Systems, Inc.
   170 West Tasman Drive
   San Jose, CA 95134
   USA

   Phone: +1 408-853-5269
   EMail: pcalhoun@cisco.com


   Tony Johansson
   Bytemobile, Inc.
   2029 Stierlin Court
   Mountain View, CA 94043

   Phone: +1 650-641-7817
   Fax:   +1 650-641-7701
   EMail: tony.johansson@bytemobile.com

Top      Up      ToC       Page 52 
   Charles E. Perkins
   Nokia Research Center
   313 Fairchild Drive
   Mountain View, CA 94043
   USA

   Phone: +1 650-625-2986
   Fax:   +1 650-625-2502
   EMail: Charles.Perkins@nokia.com


   Tom Hiller
   Lucent Technologies
   1960 Lucent Lane
   Naperville, IL 60566
   USA

   Phone: +1 630-979-7673
   EMail: tomhiller@lucent.com


   Peter J. McCann
   Lucent Technologies
   1960 Lucent Lane
   Naperville, IL 60563
   USA

   Phone: +1 630-713-9359
   Fax:   +1 630-713-1921
   EMail: mccap@lucent.com

Top      Up      ToC       Page 53 
Full 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.

   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.

Intellectual Property

   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.

Acknowledgement

   Funding for the RFC Editor function is currently provided by the
   Internet Society.