Subject: [AAA-WG]: ISSUE: MIP-FA-to-HA being added to the AMA by the AAAF

From: Mark Eklund <[email-masked]>
Date: Thu, 25 Oct 2001 12:34:49 -0400

Submitter name: Mark Eklund
Submitter email address: [email-masked]
Date first submitted: 25-Oct-01
Reference: http://www.merit.edu/mail.archives/aaa-wg/2001-10/msg00031.html
Document: mobileip
Comment type: Technical
Priority: 1
Section: 2.4, 5.3, 8.1
Rationale/Explanation of issue: 

When the HA is in the foreign network and a FA-HA key is requested,
the AAAF generates the key.  The AAAF is then responsible for adding
the MIP-FA-to-HA Key to the AMA.  This means that the AAAF must
maintain a list containing all MIP-FA-to-HA Key AVPs and their
matching Accounting-Multi-Session-Id AVPs.  When each AMA is received,
the AAAF must then consult the list and when it finds a matching
Accounting-Multi-Session-Id, add the MIP-FA-to-HA Key AVP to the AMA.

Requested change: 

Instead of requiring the AAAF to add the MIP-FA-to-HA Key AVP to the
AMA, send the MIP-FA-to-HA Key back in the HAA.  The AAAH then can
move the MIP-FA-to-HA Key from the HAA to the AMA.

Add [MIP-FA-to-HA-Key] to the HAR ABNF in section 2.4.
Change MIP-Feature-Vector column HAR = 0-1 to section 8.1
Change MIP-FA-to-HA-Key column HAA = 0-1 to section 8.1

Change the final paragraph of section 5.3 to

   Upon receipt of the HAA, the Diameter server responsible for key
   allocation creates the MIP-FA-to-HA Key AVP, using the SPI in the
   MIP-FA-to-HA-SPI.  If the key is generated at the AAAF, it adds the
   MIP-FA-to-HA Key AVP to the HAA and sends it to the AAAH.
   Depending upon where the HA was located the AAAH either generates the
   MIP-FA-to-HA Key AVP itself or extracts the AVP from the HAA sent
   by the AAAF.  The AAAH adds the MIP-FA-to-HA Key to the AMA.

-mark

---

From: Mark Eklund <[email-masked]>
Date: Fri, 26 Oct 2001 13:38:01 -0400

All,

Because of concerns about the AAAH having access to the FA-HA key when
the HA is in the foreign domain, the solution offered by this issue
doesn't work.  How about a similar answer, but one that allows
security?

Add the AVP MIP-HAA-to-AMA-Data which is opaque data of type
OctetString.  This AVP is added to the HAA by the AAAF.  On receipt of
a successful HAA, the AAAH must move this AVP from the HAA to the AMA.

This allows the AAAF to put any needed key information in the HAA and
have it available in the AMA.  If the AAAF is worried about security,
it can encrypt this information in any way it wants.

-mark

---

From: "Bob Kopacz" <[email-masked]>
Date: Mon, 29 Oct 2001 08:11:10 -0500

Hi Mark,

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> Mark Eklund
> Sent: Friday, October 26, 2001 1:38 PM
> To: Mark Eklund
> Cc: [email-masked]
> Subject: Re: [AAA-WG]: ISSUE: MIP-FA-to-HA being added to the AMA by the
> AAAF
> 
> All,
> 

One little snag.  When Pat was at the bakeoff last Thursday, I asked if,
when the AAAF has offered to allocate an HA in the foreign network, if
the AAAH needs to send the HAR to the AAAF which sent the AMR (the FA's
AAAF), or if the HAR can be sent to any old AAAF in the foreign domain.
Because I wanted to know whether the AAAH should include a Destination-Host
AVP in the HAR, or just the Destination-Realm.  The answer was that
the HAR could go to any AAAF, so don't include the Destination-Host AVP
in the HAR.

What this means is that the MIP-HAA-to-AMA-Data AVP, if encrypted,
must be decrypted by the FA's AAAF, if the FA's AAAF is a different
server from the HA's AAAF.

I guess this also means that it doesn't do the HA's AAAF any good
to cache the generated key and multi-session-id, since he may not
be the guy who receives the AMA.

---

From: Mark Eklund <[email-masked]>
Date: Tue, 30 Oct 2001 17:24:55 -0500

> be the guy who receives the AMA.

I've been thinking about this.  I see several options.

1. Allow the AAAH to generate the keys for the foreign domain.
   * There is likely a security problem with this.

2. Use CMS to somehow encrypt the AVP and return it.
   * I don't think CMS will work that way.  The second AAAF has to
     be told the first AAAF in the HAR.  The AAAH has to copy the
     secure AVP to the AMA.  If the AAAH has a security association
     with the FA, I'm not certain you could mix and match security
     associations.

3. Do the MIP-HAA-to-AMA-Data as I have suggested above.
   * This would mean that all the AAAF in the same domain would have a
     common format for what the MIP-HAA-to-AMA-Data AVP contains and
     if there is a form of encryption, that they would have handle
     decryption through a proprietary method.

4. Make no changes to Diameter and require a global database between
   all AAAF's in that foreign domain.
   * A viable solution, but the AAAF's would have to share a
     proprietary database.

5. Allow the MIP-HAA-to-AMA-Data avp to be sent and copied from the
   HAA to the AMA.
   * This has the same security concerns as #1.

I'm leaning toward a combination of 4 and 5.  If the foreign domain is
not concerned about security of its FA-HA key, then it can use 5.
Otherwise, it will need to use a proprietary database.

-mark