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

From: "Bob Kopacz" <[email-masked]>
Date: Tue, 15 Jan 2002 14:40:04 -0500

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.

---

From: Mark Eklund <[email-masked]>
Date: Tue, 15 Jan 2002 15:16:48 -0500

Bob,

I concur with your description of this Issue and the solution.

-mark

---

From: "Fredrik Johansson" <[email-masked]>
Date: Wed, 16 Jan 2002 09:15:34 +0100

I don't like the idea of "All AAAFs in that foreign realm MUST have an
agreed upon format". This seems like a major source for interoperablity
problems. I belive the format and thus the AVP should be standardized, or
you will limit yourself to use only one vendor for all AAAF's.

To me, having a HAA-to-AMA-Data AVP which is just a blob with a format which
has to be agreed upon from case to case depending on what data you would
like to convey, it's just another format for a vendor specific AVP.

If we should have a way to send data from AAAF1 to AAAF2 I suggest making
the HAA-to-AMA-Data AVP a grouped AVP and force the AAAH to copy the AVPs
included in the HAA-to-AMA-Data AVP into the AMA. We can then use this AVP
to send the FA to HA key (which should be in a standardized format).

my 2c
/Fredrik

>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]]On Behalf Of
>Bob Kopacz
>Sent: den 15 januari 2002 20:40
>To: aaa-wg
>Subject: [AAA-WG]: [issue] Returning AAAF-Generated FA-HA Key to FA
>
>