Subject: RE: [AAA-WG]: Proposed Text for Issue 91

From: "Martin Julien (ECE)" <[email-masked]>
Date: Tue, 24 Jul 2001 10:10:00 +0200

Hi Pat,

Thanks for the text, it is what I was expecting.
However, a few things to change.

1- The MIP-Replay-Mode AVP should NOT be part of the MIP-HA-to-FA-Key AVP.

2- The MIP-Replay-Mode AVP should NOT be part of the MIP-MN-to-FA-Key AVP.

3- The MIP-Peer-SPI AVP should be included in the MIP-MN-to-FA-Key AVP.

4- The MIP-MN-to-FA-Key and the MIP-MN-to-HA-Key AVPs should rather include
the MIP-Session-Key-Material AVP instead of the MIP-Session-Key AVP, right?
At least, according to the aaa-key-07 draft, it would make more sense.
Also, they should include the AAA-SPI.

That also means that for all the other "key" AVPs, the real MIP-Session-Key
is intended to be placed in the AVP directly. So, for example,
I should be expecting the MIP-Session-Key in the MIP-HA-to-FA-Key
and the MIP-FA-to-HA-Key AVPs to be the same, right?

5- In 6.10, could you change the number so that they match with the
aaa-key-07 draft, if you don't mind, i.e. from 1 to 3?

Regards,
Martin

> -----Original Message-----
> From: Pat Calhoun [mailto:[email-masked]]
> Sent: Tuesday, July 17, 2001 3:29 PM
> To: [email-masked]
> Subject: [AAA-WG]: Proposed Text for Issue 91
> 
> 
> All,
> 
> Below is my proposed text for this issue. I'd *really* like some
> comments on this ASAP, as my deadline to get the drafts out is 
> tomorrow. The changes aren't that major, and include:
> 
> 1. Changing the Mobile keys to be Grouped AVPs
> 3. Added text in sub-sections 5.x to state that the mobile proposes
>    its keys in the MIP AAA keys subtypes, and the HA uses these SPIs
>    in the creation of the MIP AAA key reply extensions.
> 4. Added text in 5.x stating that the HA is responsible for creating
>    the SPI used in the FA-HA key
> 5. Added two new AVPs, that the HA includes in the HAA. These AVPs
>    contain the SPIs that the FA will use with the MN and the HA. These
>    SPIs are used by the AAAH to create the grouped key AVPs that are
>    sent to the foreign in the AMA.
> 
> btw, I am not using my normal nroff environment, so the formatting MAY
> be a tad off. I will be out of contact today between 9 and 5 
> pacific, and
> will respond to comments upon my return.
> 
> Comments most appreciated,
> 
> PatC
> ----
> 
> 
> 5.0  Key Distribution Center
> 
>    The mobile node and mobility agents use registration keys 
> to compute
>    authentication extensions applied to registration messages, as
>    defined in [4]: Mobile-Foreign, Foreign-Home and Mobile-Home.  If
>    registration keys are requested the AAA server(s) MUST create them
>    after the Mobile Node is successfully authenticated and authorized.
> 
>    If the AAAH does not communicate directly with the foreign 
> agent, and
>    it does not wish for intermediate proxies to have access to the
>    session keys, they SHOULD be protected using the CMS security
>    application [9].
> 
>    The Authorization-Lifetime AVP contains the number of 
> seconds before
>    registration keys destined for the Home Agent and/or Foreign Agent
>    expire.  A value of zero indicates infinity (no timeout).
> 
>    AAA support for key distribution departs slightly from the existing
>    SPI usage, as described in [4]. The SPI values are used as key
>    identifiers, meaning that each registration key has its own SPI
>    value; nodes that share a key also share an SPI. The Mobile Node
>    proposes SPIs for use in computing the Mobile-Foreign and 
> Mobile-Home
>    authentication extensions, via the Mobile IP AAA Key Request
>    extensions [15], while the Home Agent allocates the Mobile-Foreign,
>    Mobile-Home and Foreign-Home SPIs.
> 
>    Once the registration keys have been distributed, subsequent Mobile
>    IP registrations need not invoke the AAA infrastructure until the
>    keys expire.  These registrations MUST include the Mobile-Home
>    authentication extension.  In addition, subsequent 
> registrations MUST
>    also include Mobile-Foreign authentication extension if the Mobile-
>    Foreign key was generated and distributed by AAA; similarly for
>    subsequent use of the Foreign-Home authentication extensions.
> 
>    Each registration key that is generated by AAA will generally be
>    distributed to two parties; for instance, a Mobile-Foreign key goes
>    to both a mobile node and a foreign agent.  The methods by 
> which the
>    key is encoded will depend upon the security associations available
>    to the AAA server and each recipient of the key.  These 
> methods will
>    often be different for the two recipients, so that the registration
> 
> 
> 
> Calhoun, Perkins          expires December 2001               
>  [Page 26]
> 
> 
> 
> 
> 
> Internet-Draft                                                
>  June 2001
> 
> 
>    key under consideration has to be encoded twice.
> 
>    See sections 6.0 for details about the format of the AVPs used to
>    transport the registration keys.
> 
> 
> 5.1  Distributing the Mobile-Home Registration Key
> 
>    If the mobile node does not have a Mobile-Home 
> registration key, then
>    the AAAH is likely to be the only entity trusted that is 
> available to
>    the mobile node.  Thus, the AAAH has to generate the Mobile-Home
>    registration key, and encode it for eventual consumption by the
>    mobile node and home agent.
> 
>    If the home agent is in the home domain, then AAAH can directly
>    encode the Mobile-Home registration key into a MIP-HA-to-MN-Key AVP
>    and include that AVP in the HAR message for delivery to the home
>    agent.
> 
>    If, on the other hand, the home agent is to be allocated in the
>    visited domain, the AAAH does not transmit the HAR to the 
> home agent,
>    but instead transmits the HAR to the AAAF. When the AAAF 
> receives the
>    HAR, it first allocates a home agent, and then issues the HAR for
>    that home agent.
> 
>    The AAAH also has to arrange for the key to be delivered to the
>    mobile node.  Unfortunately, the AAA server only knows 
> about Diameter
>    messages and AVPs, and the mobile node only knows about Mobile IP
>    messages and extensions [4].  For this purpose, AAAH encodes the
>    Mobile-Home registration key into a MIP-MN-to-HA-Key AVP, using its
>    security association with the mobile node, which is added 
> to the HAR
>    message, and delivered either to a local home agent, or to the AAAF
>    in the case where the home agent is in the visited 
> network. The AAAH
>    has to rely on the home agent (that also understands Diameter) to
>    transfer the keying information into a Mobile IP Generalized MN-HA
>    Key Reply extension [15] in the Registration Reply 
> message, using the
>    SPI proposed by the Mobile Node in the MN-HA Key Request From AAA
>    Subtype 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.
> 
>    After the HAA message is parsed by the AAAH, and 
> transformed into an
>    AMA, the AMA message containing the MIP-Reg-Reply AVP will 
> eventually
>    be received by the the foreign agent. The foreign agent 
> can then use
>    that AVP to recreate a Registration Reply message, containing the
>    Generalized MN-HA Key Reply extension, for delivery to the mobile
>    node.
> 
> 
> 
> 
> Calhoun, Perkins          expires December 2001               
>  [Page 27]
> 
> 
> 
> 
> 
> Internet-Draft                                                
>  June 2001
> 
> 
>    In summary, the AAAH generates the Mobile-Home registration key and
>    encodes it into a MIP-HA-to-MN-Key AVP and a MIP-MN-to-HA-Key AVP.
>    These AVPs are delivered to a home agent by including them in a HAR
>    message sent from either AAAH or AAAF. The home agent 
> decodes the key
>    for its own use.  The home agent also copies the encoded 
> registration
>    key from the MIP-MN-to-HA-Key AVP into a Generalized MN-HA 
> Key Reply
>    extension appended to the Mobile IP Registration Reply 
> message. This
>    Registration Reply message MUST also include the Mobile-Home
>    authentication extension, created using the newly allocated Mobile-
>    Home registration key. The home agent then encodes the Registration
>    Reply message and extensions into a MIP-Reg-Reply AVP included as
>    part of the HAA message to be sent back to the AAA server.
> 
> 
> 5.2  Distributing the Mobile-Foreign Registration Key
> 
>    The Mobile-Foreign registration key is also generated by AAAH (upon
>    request), so that it can be encoded into a MIP-MN-to-FA-Key AVP,
>    which is added to the HAR, and copied by the home agent into a
>    Generalized MN-FA Key Reply Extension [15] to the Mobile IP
>    Registration Reply message, using the SPI proposed by the 
> Mobile Node
>    in the MN-FA Key Request From AAA Subtype extension. Further, the
>    home agent includes the SPI in the HAA's MIP-FA-to-MN-SPI AVP. Most
>    of the considerations for distributing the Mobile-Foreign
>    registration key are similar to the distribution of the Mobile-Home
>    Registration Key.
> 
>    Upon receipt of the HAA, if MN-FA keying was requested the AAAH
>    creates the MIP-FA-to-MN-Key AVP, using the SPI in the 
> MIP-FA-to-MN-
>    SPI, and includes the AVP in the AMA. If the 
> MIP-FA-to-MN-Key AVP was
>    present in the AMA, the foreign agent MUST include the 
> Mobile-Foreign
>    authentication extension in the Registration Reply, using the newly
>    distributed key.
> 
> 
> 5.3  Distributing the Foreign-Home Registration Key
> 
>    If the home agent is in the home domain, then AAAH has to generate
>    the Foreign-Home registration key.  Otherwise, it is generated by
>    AAAF.
> 
>    In either case, the AAA server encodes the registration key into a
>    MIP-HA-to-FA-Key AVP and includes that AVP as part of the 
> HAR message
>    sent to the home agent, and waits for the HAA message to 
> be returned.
> 
>    Upon receipt of the HAR, the home agent recovers the Foreign-Home
>    registration key, allocates an SPI to be used with the 
> key, and uses
>    this key to create a Foreign-Home authentication extension to the
> 
> 
> 
> Calhoun, Perkins          expires December 2001               
>  [Page 28]
> 
> 
> 
> 
> 
> Internet-Draft                                                
>  June 2001
> 
> 
>    Registration Reply message. The allocated SPI is included in the
>    HAA's MIP-FA-to-HA SPI AVP.
> 
>    Upon receipt of the HAA, the Diameter server responsible for key
>    allocation adds the MIP-FA-to-HA Key AVP, using the SPI in the MIP-
>    FA-to-HA-SPI, and includes the AVP in the AMA.
> 
> 
> 5.4  Key Distribution Example
> 
>    Figure 9 provides an example of subsequent Mobile IP message
>    exchange, assuming that AAAH distributed registration keys for all
>    three MN-FA, FA-HA and HA-MN authentication extensions.
> 
>    Mobile Node                Foreign Agent                 Home Agent
>    -----------                -------------                 ----------
> 
>    Reg-Req(MN-HA-Auth, MN-FA-Auth)-------->
> 
>                               Reg-Req(MN-HA-Auth, FA-HA-Auth)-------->
> 
>                               <--------Reg-Rep(MN-HA-Auth, FA-HA-Auth)
> 
>    <--------Reg-Rep(MN-HA-Auth, MN-FA-Auth)
> 
>                    Figure 9: Mobile IP Message Exchange
> 
> 
> 6.0  Key Distribution Center (KDC) AVPs
> 
>    The Mobile-IP protocol defines a set of security 
> associations shared
>    between the Mobile Node, Foreign Agent and Home Agents. These three
>    security associations (Mobile-Home, Mobile-Foreign, and Foreign-
>    Home), can be dynamically created by the AAAH. This 
> requires that the
>    AAAH create Mobile-IP Registration Keys, and that these keys be
>    distributed to the three mobile entities, via the Diameter 
> Protocol.
>    AAA servers supporting the Diameter Mobile IP Application MUST
>    implement the KDC AVPs defined in this document. In other 
> words, AAA
>    servers MUST be able to create three registration keys: the Mobile-
>    Home, Mobile-Foreign, and Foreign-Home keys.
> 
>    The names of the KDC AVPs indicate the two entities sharing the
>    security association defined by the encrypted key material; the
>    intended receiver of the AVP is the first named entity.  So, for
>    instance, the MIP-MN-to-HA-Key AVP contains the Mobile-Home key
>    encrypted in a way that allows it to be recovered by the 
> mobile node.
> 
>    If strong authentication and confidentiality of the 
> registration keys
> 
> 
> 
> Calhoun, Perkins          expires December 2001               
>  [Page 29]
> 
> 
> 
> 
> 
> Internet-Draft                                                
>  June 2001
> 
> 
>    is required, it is recommended that the CMS security 
> application [9]
>    be used.
> 
>    The following table describes the Diameter AVPs defined in 
> the Mobile
>    IP application, their AVP Code values, types, possible flag values
>    and whether the AVP MAY be encrypted.
> 
>                                              +---------------------+
>                                              |    AVP Flag rules   |
>                                              
> |----+-----+----+-----|----+
>                     AVP  Section             |    |     
> |SHLD| MUST|MAY |
>     Attribute Name  Code Defined  Value Type |MUST| MAY | 
> NOT|  NOT|Encr|
>     
> -----------------------------------------|----+-----+----+-----|----|
>     MIP-Algorithm-   345  6.9     Enumerated | M  |  P  |    
> |  V  | Y  |
>       Type                                   |    |     |    
> |     |    |
>     MIP-FA-to-HA-Key 328  6.2     Grouped    | M  |  P  |    
> |  V  | Y  |
>     MIP-FA-to-HA-SPI 318  6.12    Unsigned32 | M  |  P  |    
> |  V  | Y  |
>     MIP-FA-to-MN-Key 326  6.1     Grouped    | M  |  P  |    
> |  V  | Y  |
>     MIP-FA-to-MN-SPI 319  6.11    Unsigned32 | M  |  P  |    
> |  V  | Y  |
>     MIP-HA-to-FA-Key 329  6.3     Grouped    | M  |  P  |    
> |  V  | Y  |
>     MIP-HA-to-MN-Key 332  6.4     Grouped    | M  |  P  |    
> |  V  | Y  |
>     MIP-MN-to-FA-Key 325  6.5     OctetString| M  |  P  |    
> |  V  | Y  |
>     MIP-MN-to-HA-Key 331  6.6     OctetString| M  |  P  |    
> |  V  | Y  |
>     MIP-Peer-SPI     342  6.7     Unsigned32 | M  |  P  |    
> |  V  | Y  |
>     MIP-Replay-Mode  346  6.10    Enumerated | M  |  P  |    
> |  V  | Y  |
>     MIP-Session-Key  343  6.8     OctetString| M  |  P  |    
> |  V  | Y  |
> 
> 
> 6.1  MIP-FA-to-MN-Key AVP
> 
>    The MIP-FA-to-MN-Key AVP (AVP Code 326) is of type Grouped, and
>    contains the Foreign Agent's session key, which it shares with the
>    Mobile Node. Its Data field has the following ABNF grammar:
> 
>       MIP-FA-to-MN-Key ::= < AVP Header: 326 >
>                            { MIP-Peer-SPI }
>                            { MIP-Algorithm-Type }
>                            { MIP-Session-Key }
>                          * [ AVP ]
> 
> 
> 6.2  MIP-FA-to-HA-Key AVP
> 
>    The MIP-FA-to-HA-Key AVP (AVP Code 328) is of type Grouped, and
>    contains the Foreign Agent's session key, which it shares with the
>    Home Agent. Its Data field has the following ABNF grammar:
> 
>       MIP-FA-to-HA-Key ::= < AVP Header: 328 >
> 
> 
> 
> Calhoun, Perkins          expires December 2001               
>  [Page 30]
> 
> 
> 
> 
> 
> Internet-Draft                                                
>  June 2001
> 
> 
>                            { MIP-Peer-SPI }
>                            { MIP-Algorithm-Type }
>                            { MIP-Session-Key }
>                          * [ AVP ]
> 
> 
> 6.3  MIP-HA-to-FA-Key AVP
> 
>    The MIP-HA-to-FA-Key AVP (AVP Code 329) is of type Grouped, and
>    contains the Home Agent's session key, which it shares with the
>    Foreign Agent. Its Data field has the following ABNF grammar:
> 
>       MIP-HA-to-FA-Key ::= < AVP Header: 329 >
>                            { MIP-Algorithm-Type }
>                            { MIP-Replay-Mode }
>                            { MIP-Session-Key }
>                          * [ AVP ]
> 
> 
> 6.4  MIP-HA-to-MN-Key AVP
> 
>    The MIP-HA-to-MN-Key AVP (AVP Code 332) is of type Grouped, and
>    contains the Home Agent's session key, which it shares with the
>    Mobile Node. Its Data field has the following ABNF grammar:
> 
>       MIP-HA-to-MN-Key ::= < AVP Header: 332 >
>                            { MIP-Algorithm-Type }
>                            { MIP-Replay-Mode }
>                            { MIP-Session-Key }
>                          * [ AVP ]
> 
> 
> 6.5  MIP-MN-to-FA-Key AVP
> 
>    The MIP-MN-to-FA-Key AVP (AVP Code 325) is of type Grouped, and
>    contains the Mobile Node's session key, which it shares with the
>    Foreign Agent. The Home Agent uses this AVP in the construction of
>    the Mobile IP "Unsolicted MN-FA Key from AAA Subtype" 
> extension [15].
>    The SPI in the extension's FA SPI field is allocated by the Home
>    Agent, but it SHOULD take into consideration the SPI 
> requested by the
>    Mobile Node in the "MN-FA Key Request From AAA Subtype" extension.
> 
>       MIP-MN-to-FA-Key ::= < AVP Header: 325 >
>                            { MIP-Algorithm-Type }
>                            { MIP-Replay-Mode }
>                            { MIP-Session-Key }
>                          * [ AVP ]
> 
> 
> 
> 
> Calhoun, Perkins          expires December 2001               
>  [Page 31]
> 
> 
> 
> 
> 
> Internet-Draft                                                
>  June 2001
> 
> 
> 6.6  MIP-MN-to-HA-Key AVP
> 
>    The MIP-MN-to-HA-Key AVP (AVP Code 331) is of type Grouped, and
>    contains the Mobile Node's session key, which it shares 
> with the Home
>    Agent. The Home Agent uses this AVP in the construction of 
> the Mobile
>    IP "Unsolicted MN-HA Key from AAA Subtype" extension [15]. 
> The SPI in
>    the extension's HA SPI field is allocated by the Home Agent, but it
>    SHOULD take into consideration the SPI requested by the Mobile Node
>    in the "MN-HA Key Request From AAA Subtype" extension.
> 
>       MIP-MN-to-FA-Key ::= < AVP Header: 331 >
>                            { MIP-Algorithm-Type }
>                            { MIP-Replay-Mode }
>                            { MIP-Session-Key }
>                          * [ AVP ]
> 
> 
> 6.7  MIP-Peer-SPI AVP
> 
>    The MIP-Peer-SPI AVP (AVP Code 342) is of type Unsigned32, and
>    contains the Security Parameter Index to use to reference 
> the key in
>    the associated MIP-Session-Key AVP. The SPI created MUST NOT be a
>    value between zero (0) and 255, which is the reserved namespace
>    defined in [4].
> 
> 
> 6.8  MIP-Session-Key AVP
> 
>    The MIP-Session-Key AVP (AVP Code 343) is of type OctetString and
>    contains the Session Key to be used between two Mobile IP entities.
> 
> 
> 6.9  MIP-Algorithm-Type AVP
> 
>    The MIP-Algorithm-Type AVP (AVP Code 345) is of type 
> Enumerated, and
>    contains the Algorithm identifier used to generate the associated
>    Mobile IP authentication extension. The following values are
>    currently defined:
> 
>       1   Prefix+Suffix MD5 [4]
>       2   HMAC-MD5 [13]
>       3   SHA-1 [17]
> 
> 
> 6.10  MIP-Replay-Mode AVP
> 
>    The MIP-Replay-Mode AVP (AVP Code 346) is of type Enumerated and
>    contains the replay mode the Home Agent should use when
> 
> 
> 
> Calhoun, Perkins          expires December 2001               
>  [Page 32]
> 
> 
> 
> 
> 
> Internet-Draft                                                
>  June 2001
> 
> 
>    authenticating the Mobile Node.
> 
>    The following values are supported (see [4] for more information):
> 
>       0   None
>       1   Timestamps
>       2   Nonces
> 
> 
> 6.11  MIP-FA-to-MN-SPI AVP
> 
>    The MIP-FA-to-MN-SPI AVP (AVP Code 319) is of type Unsigned32, and
>    contains the Security Parameter Index the Foreign Agent is 
> to use to
>    refer to the session key it shares with the Mobile Node. The SPI
>    created MUST NOT be a value between zero (0) and 255, which is the
>    reserved namespace defined in [4]. This AVP MAY be added in the HAA
>    message by the Home Agent for the AAAH's use in MIP-Peer-SPI AVP of
>    the MIP-FA-to-MN-Key AVP.
> 
> 
> 6.12  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 Foreign Agent is 
> to use to
>    refer to the session key it shares with the Home Agent. The SPI
>    created MUST NOT be a value between zero (0) and 255, which is the
>    reserved namespace defined in [4]. This AVP MAY be added in the HAA
>    message by the Home Agent for the AAAH's use in MIP-Peer-SPI AVP of
>    the MIP-FA-to-HA-Key AVP.
>

---

From: Pat Calhoun <[email-masked]>
Date: Tue, 24 Jul 2001 05:44:26 -0700

I agree with all your comments, and thanks for the summary. It makes
it easier when I need to make the change :)

PatC

---

From: Guenter Schaefer <[email-masked]>
Date: Tue, 24 Jul 2001 15:24:57 +0200

Dear participants of the AAA-WG,

please excuse me for coming back to an issue that you may assume
resolved, but that still is somehow unclear to me:

 In case of a handover of a mobile node from one FAold to an FAnew,
 how are the internal SPI databases updated conceptually at the
 two foreign agents and at the home agent?
 And how is it assured that SPIs remain unique between FAnew and HA?

If the AAAF communicates an already established set of session keys
K_FAold_MN and K_FAold_HA to the new foreign agent FAnew, it
may happen (maybe with a low probability) that the SPI corresponding 
to K_FAold_HA is already used for another key between FAnew and HA.

Am I missing something here? 

If such an "SPI-collision" would occur, how could this issue be
resolved?

I would appreciate any comment on this, with kind regards,

Guenter Schaefer

P.S.: Please excuse me for coming into your discussion "out of 
      nowhere". We (at TKN, Technical University of Berlin, Germany) 
      are currently studying the Mobile IP related AAA internet 
      drafts in the context of a joint project with Siemens 
      Corporation. Special focus is on authentication performance
      during handover.

------------------------------------------------------------------------
Guenter Schaefer, Institute of Telecommunication Systems,
Technical University of Berlin, Einsteinufer 25, 10587 Berlin, Germany, 
Phone: +49 30 314 23836, Fax: - 23818, Email: [email-masked]

---

From: Pat Calhoun <[email-masked]>
Date: Tue, 24 Jul 2001 06:37:23 -0700

>  And how is it assured that SPIs remain unique between FAnew and HA?

Because currently any handoff requires AAA interactions. So, the Home
Agent will be contacted, and will re-use (or generate new) SPIs, which
are returned to the new Foreign Agent. The draft states that once fast
handoff becomes popularized, extensions to Diameter could be introduced.

> Am I missing something here? 

That functionality was removed from the protocol.... did you find references
to text in the mobile ip draft that claims support for the AAAF distributing
local keying information?

> If such an "SPI-collision" would occur, how could this issue be

This is obviously a MIP issue, and one that they will have to resolve in
the face of upcoming Context Transfer work in seamoby, because oFA will
transfer its MIP SA to nFA.

>       Corporation. Special focus is on authentication performance

Ah, well handoff performance wasn't addressed in the application. There
is text that states that once fast handoff (and/or context transfer) is
completed, some Diameter extensions will be necessary.

PatC

---

From: Guenter Schaefer <[email-masked]>
Date: Tue, 24 Jul 2001 16:20:03 +0200

Dear Mrs. Calhoun,

thank you very much for your quick clarification.

Pat Calhoun wrote:
> 
> That functionality was removed from the protocol.... did you find
> references to text in the mobile ip draft that claims support for 
> the AAAF distributing local keying information?

My confusion maybe comes from the fact, that I was working with
an already outdated version of the draft
(draft-ietf-aaa-diameter-mobileip-06.txt).  

Section 2.1 was stating:

"If the MIP-Previous-FA-Host AVP is found in the request, the Diameter
 client requests that the server return the registration key that was
 assigned to the previous Foreign Agent for use with the Mobile Node
 and Home Agent. The registration key is identified through the use of
 the User-Name AVP."

I have just checked the latest version available at the IETF web-page
(draft-ietf-aaa-diameter-mobileip-07.txt). This passage is 
still there. However, I currently can not see any other reason
for the MIP-Previous-FA-Host AVP than to re-use an existing
security association between oFA-HA for nFA-HA. 

So if the idea of speeding up local handovers has been postponed 
for further study, maybe all references and explanations regarding
the MIP-Previous-FA-Host AVP are superfluous (e.g. section
4.5).

With best regards,

Guenter Schaefer

---

From: Pat Calhoun <[email-masked]>
Date: Tue, 24 Jul 2001 07:22:50 -0700

> Dear Mrs. Calhoun,

hmmmm... wrong gender :(

> (draft-ietf-aaa-diameter-mobileip-06.txt).  

Ah, then you should be reviewing -07.

> the MIP-Previous-FA-Host AVP are superfluous (e.g. section

Thanks for the catch. So, the passage in 2.1 needs to be removed,
as well as the second paragraphs in sections 4.5 and 4.6. These
should have been removed, but somehow were missed.

> With best regards,

Thanks for the info,

PatC