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

From: "Bob Kopacz" <[email-masked]>
Date: Fri, 2 Nov 2001 11:29:08 -0500

Hi Mark,

We haven't been thinking much about this much (nothing good is coming to
mind), but here's some feedback:

Idea#1: If the AAAF received an AMR from the FA, and if the AAAF offers
to allocate the HA in the home network, and if the AAAH accepts the
offer, then require the HAR to be sent to the AAAF which sent the AMR.
Then there is only one AAAF involved, and the problems go away (we can
just use your HAA-to-AMA-data AVP idea).  AAAF1 is the guy that
offered to allocate the HA, so let him be the guy that has to pony up
the HA.

Idea#2: This is your idea#2, to use CMS (of which my understanding is
fairly limited) to somehow encrypt the FA-HA key.  Your thought then, in
smaller steps that I can understand, would be to:

1. Convey AAAF1's identity in the HAR sent to AAAF2.
2. AAAF2 forms a CMS security association with AAAF1.
3. AAAF2 sends back the HA-FA key, CMS-encrypted, in the HAA.
4. AAAH may also form a CMS security assocation with FA, to
   protect the other keys.
5. In the AMA sent by the AAAH to AAAF1, there are two CMS encrypted
   bundles:
   a. One from AAAF2 to AAAF1 carrying the FA-HA key,
   b. One from AAAH to FA, carrying the other keys.

And the question here is whether CMS can carry multiple encrypted
bundles with different origins and destinations, right?

And a couple (probably ignorant) questions:

If there were two AAAFs involved, i.e. the picture is

        FA -> AAAF1 -> AAAH
                         |
        HA <- AAAF2 <----/

Question#1: Is there any problem with AAAF1 offering to allocate a HA in
the foreign network, but AAAF2 being unable to later allocate the
offered HA?

Question#2: If AAAF1 offers to allocate an HA, and sends the identity of
the offered HA in Pat's new "Candidate-HA-Host" AVP, is there any
problem with AAAF2 being able to offer this specific HA (e.g. routing
or whatever)?

Bob K.

> -----Original Message-----
> From: Mark Eklund [mailto:[email-masked]]
> Sent: Tuesday, October 30, 2001 5:25 PM
> To: Bob Kopacz
> Cc: Mark Eklund; [email-masked]
> Subject: RE: [AAA-WG]: ISSUE: MIP-FA-to-HA being added to the AMA by the
> AAAF
>
>
> Bob Kopacz writes:
>  > 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,
>  > >
>  > > 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.
>  >
>  > 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.
>
> 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
>
>  >
>  > > -mark
>  > >
>  > > Mark Eklund writes:
>  > >  > 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: Mon, 5 Nov 2001 14:34:31 -0500

> offered to allocate the HA, so let him be the guy that has to pony up

I like this idea.  If there is a AAAF2 that has to deal out the HA
servers, then the AAAF can just proxy the HAR to that AAAF2.

Of course this leads to the question of who generates the key the AAAF
or the AAAF2?

 > bundles with different origins and destinations, right?

I scanned the CMS specs and it looks possible that you could do this.
The AAAH would then have to know that all CMS encrypted data not
destined for it would have to be forwarded to the AAAF.  Personally, I
think this option becomes much more complex than Idea#1.

 > the foreign network, but AAAF2 being unable to later allocate the

I don't see any problems.  This would cause a HAA to be sent back that
looked similar to something a HA would reply with if it had run out of
space.  I would assume the Result-Code AVP would be
DIAMETER_ERROR_HA_NOT_AVAILABLE.

 > problem with AAAF2 being able to offer this specific HA (e.g. routing

This would seem an implementation detail.  If we use Idea #1, this
wouldn't be a problem.

-mark

---

From: Pat Calhoun <[email-masked]>
Date: Mon, 5 Nov 2001 11:27:08 -0800

> Of course this leads to the question of who generates the key the AAAF

Ah, well for inter-domain it is the AAAH.

> think this option becomes much more complex than Idea#1.

bullet item #2 above seems very complex given the current architecture. So for
3rd parties, the AAAH allocates all the keys.

PatC

---

From: "Bob Kopacz" <[email-masked]>
Date: Wed, 7 Nov 2001 07:49:54 -0500

Hi Mark,

> From: Mark Eklund [[email-masked]]
> Sent: Monday, November 05, 2001 2:35 PM
> To: Bob Kopacz

A problem is ensuring that the AAAH's generated HAR is received by the
first AAAF.

Here's a picture:

        HA --- AAAF2 --- ...
           \                 \
            \                 -- AAAH
        FA---\ AAAF1 --- ... /

Suppose that:
1. AAAF1 and AAAF2 are two AAA servers in the same foreign realm.
2. AAAF1 and AAAF2 are both peers of HA (it isn't strictly necessary
   that HA be a peer of AAAF1).
3. The FA sends his AMR to AAAF1.
4. AAAF1 offers to allocate an HA in the visited network,
   and AAAH accepts the offer. 
5. AAAF1 offers HA's identity in Pat's new Candidate-HA-Host AVP.
6. AAAH send the HAR with Destination-Host=HA's identity.
7. If AAAF1 receives the HAR, things are hunky-dory,
   but because of routing, AAAF2 could just as well receive
   the HAR.

One way to ensure that AAAF1 receives the HAR is to target
the HAR to AAAF1 (Destination-Host=AAAF1's identity) rather
than to HA, and for AAAH to echo the Candidate-HA-Host AVP
in the HAR.  Then AAAF1 could do the FA-HA key generation,
and forward the HAR to HA (or proxy the HAR to AAAF2 if
HA is not a peer of AAAF1).

Bob K.