Subject: [Fwd: Re: [AAA-WG]: [issue] Returning AAAF-Generated FA-HA Key to FA]

From: Tony Johansson <[email-masked]>
Date: Tue, 29 Jan 2002 09:25:48 -0800

I seems to have some problems with my mail-box, sorry if you receive
this twice.

/Tony

-------- Original Message --------
Subject: Re: [AAA-WG]: [issue] Returning AAAF-Generated FA-HA Key to FA
Date: Mon, 28 Jan 2002 15:46:29 -0800
From: Tony Johansson <[email-masked]>
To: Bob Kopacz <[email-masked]>
CC: [email-masked]
References: <[email-masked]>

Hello Bob and All,

I agree that it could be good to have a way of encrypting the FA-HA Key
as
you describe below, and even more for the case where you move through a
third domain ( i.e. the AAAF1 and AAAF2 belongs to two different
networks).
However, I really think that we need to find a more interoperability
approve approach. I'm not sure that we just can say that the
HAA-toAMA-Data
AVP is of type OctetString and may be used,  to convey the FA-HA key
information in some proprietary format and security method which is
agreed-upon by all AAAF servers in the foreign network...

You mention CMS security below and I agree, couldn't we make use of the
CMS
security for this case?

So, what about the following (I'm not a CMS security expert, so please
correct me if this is not really possible or to complex...):

Instead, make the HAA-toAMA-Data AVP of type grouped :

HAA-toAMA-Data AVP ::= < AVP Header: TBD >
                     { Originating-Foriegn-Home-Key-Distr-Host }
                     { CMS-Encrypted-Data }
                   * [ AVP ]

The CMS-Encrypted-Data AVP would contain the FA-HA Key encrypted and the
Originating-Foriegn-Home-Key-Distr-Host AVP (lack of better name:) would
contain the Host NAI of the AAAF2, see Figure below

The message flow would then be the following:

(Please view in a fixed-width font such as Courier.)

           1.amr->         1.amr->
        FA --------> AAAF1 1------------> AAAH
             <-6.ama |  ^    <-4.ama        |
                     |  |                   |  ^
                     |  |                   |  |
              5.dsar |  |5.dsaa       2.har |3.haa
                     |  |                |  |
                     |  |                V  |
                     |  |                   |
             <-2.har v  |     <-2.har       |
        HA <-------- AAAF2 <---------------/
            3.haa->         3.haa->

Thus, the AAAF2 would create the HAA-to-AMA AVP with its Host name and
the
FA-HA Key encrypted using its digital certificate. Upon receiving the
HAA
the AAAH would add the HAA-to-AMA AVP into the AMA. Upon receipt of the
AMA
the AAAF1 would identify the Originating-Foriegn-Home-Key-Distr-Host AVP
in
the HAA-to-AMA AVP and issue a DSAR to the AAAF2 and request for the
digital certificate, which the AAAF1 then would use to decrypt the FA-HA
Key....

Could this be a way forward ?

Comments please...

Tony

Bob Kopacz wrote:

> Issue : Returning AAAF-Generated FA-HA Key to FA
> Submitter name: Bob Kopacz
> Submitter email address: [email-masked]
> Date first submitted: 01-15-2002
> Reference:
> Document: mobileip
> Comment type: Technical
> Priority: 1
> Section: 2.2, 2.4, 5.4, 8.1, Issue#203
> Rationale/Explanation of issue:
>
>   [The following is based on some issue#203-related emails
>   exchanged with Mark Eklund.  The proposal I'm contributing here
>   is also Mark's, as I understand it]
>
>   When the HA is in the foreign network and a FA-HA key is
>   requested, the AAAF, rather than the AAAH, generates the key.
>
>   Here's the diagram of the issue:
>
>                amr->           amr->
>           FA --------> AAAF1 -------------> AAAH
>                <-ama           <-ama          |
>                                               |  ^
>                                               |  |
>                                           har | haa
>                                            |  |
>                                            V  |
>                                               |
>                 <-har           <-har         |
>           HA <-------- AAAF2 <---------------/
>                 haa->           haa->
>
>   In the above diagram, FA & HA & AAAF1 & AAAF2 are all in the same
>   visited network.  AAAF1 and AAAF2 may be the same server, or may
>   be different servers.
>
>   In the above diagram, AAAF2 generates the FA-HA key.
>
>   The problem is that this key must somehow be returned to the FA
>   via AAAF1.  The proposal here is to pass the key back to the FA
>   via the the HAA and AMA messages.  AAAF2 may be concerned about
>   security, so may want the FA-HA key to be passed encrypted so
>   that AAAH and intervening servers can't figure it out, but AAAF1
>   can somehow decrypt it.
>
>   The details are:
>
>   1. A new HAA-to-AMA-Data AVP, of type octetstring, is created.
>   The purpose of this AVP is convey information from the HA's AAAF
>   (AAAF2) to the FA's AAAF (AAAF1).  All AAAFs in that foreign
>   realm MUST have an agreed upon format and security method for
>   this AVP to be used.  (It may be possible to use CMS security
>   to somehow encrypt this AVP, but it is unclear just how, as it
>   involves the AAAH copying a secure AVP from the HAA to the AMA,
>   and the AMA may carry both AAAH-FA and AAAF1-AAAF2 secured
>   AVPs)
>
>   2. When the FA-HA key is generated by AAAF2, this key must
>   somehow be conveyed to AAAF1.  There are two ways to do this:
>   a. Use the MIP-HAA-to-AMA-Data AVP, or
>   b Have a common database among AAAFs in the foreign network,
>   wherein AAAF2 may deposit the FA-HA key, which is later retrieved
>   by AAAF1, in a proprietary manner not described in the Diameter
>   documents.
>
>   3. If the HAA-to-AMA-Data AVP is present in the HAA, the AAAH
>   treats it as opaque data and passes it in the AMA.
>
>   4, If AAAF1 receives the HAA-to-AMA-Data AVP in the AMA, AAAF1
>   will use this AVP to recreate the FA-HA key, and replace this AVP
>   by a MIP-FA-to-HA-Key AVP in the AMA sent to the FA.
>
> Requested change:
>
>   This issues supercedes issue#203, which also addresses the
>   problem of returning an AAAF-Generated FA-HA Key to the FA, but
>   didn't quite work in the case where there was a 2nd AAAF
>   involved.
>
>   In section 2.2. Add [HAA-to-AMA-Data] to the AMA ABNF.
>
>   In section 2.4. Add [HAA-to-AMA-Data] to the HAA ABNF.
>
>   In section 6, define the following new AVP:
>
>       6.x HAA-to-AMA-Data AVP
>
>       The HAA-to-AMA-Data AVP (AVP Code TBD) is of type OctetString and
>       may be used, when the HA is allocated in the foreign network and
>       the HA's AAAF generates the FA-HA key, to convey the FA-HA key
>       information (in some proprietary format and security method which
>       is agreed-upon by all AAAF servers in the foreign network) back
>       to the FA's AAAF.
>
>   In section 8.1. Add a row for the new HAA-to-AMA-Data AVP, with these
>   occurrence rules: AMR 0, AMA 0-1, HAR 0, HAA 0-1.
>
>   Replace section 5.4 by
>
>       If the home agent is in the home realm, then AAAH has to generate
>       the Foreign-Home session key. Otherwise, it is generated by the
>       AAAF receiving the HAR.
>
>       If the AAAH generates the Foreign-Home session key, then the AAAH
>       includes the session key in the MIP-HA-to-FA-Key AVP, and
>       includes the AVP as part of the HAR message sent to the home
>       agent. The corresponding session key that is to be sent to the
>       foreign agent is cached on the AAAH until the HAA is received, at
>       which time the AAAH adds the MIP-FA-to-HA Key AVP to the AMA,
>       using the SPI in the MIP-FA-to-HA-SPI.
>
>       Upon receipt of the HAR, the home agent recovers the Foreign-Home
>       session key, allocates an SPI to be used with the key. The
>       allocated SPI is included in the HAA's MIP-FA-to-HA SPI AVP.
>
>       If the AAAH doesn't generate the Foreign-Home session key, then
>       upon receipt of the HAA, the AAAH extracts and passes the
>       MIP-FA-to-HA-SPI AVP (if present in the HAR) in the AMA, and
>       extracts and passes the HAA-to-AMA-Data AVP (if present in the
>       HAR) in the AMA.
>
>       If the AAAF receives an AMA which contains a HAA-to-AMA-Data AVP,
>       the AAAF will recreate the FA-HA key, generate a MIP-FA-to-HA-Key
>       AVP, and pass the MIP-FA-to-HA-Key AVP to the FA.
>
>       Alternatively, if the AAAF generates the Foreign-Home session
>       key, the AAAFs in the foreign network may have a common database
>       among AAAFs, wherein the HA's AAAF may deposit the FA-HA key,
>       which is later retrieved by the FA's AAAF, in a proprietary
>       manner not described in the Diameter documents.