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

From: "Bob Kopacz" <[email-masked]>
Date: Wed, 30 Jan 2002 08:01:53 -0500

Hi Tony,

> From: Tony Johansson [[email-masked]]
> Sent: Monday, January 28, 2002 6:46 PM
> To: Bob Kopacz
> Cc: [email-masked]
> Subject: Re: [AAA-WG]: [issue] Returning AAAF-Generated FA-HA Key to FA
> 
> 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?
 
Your idea to use CMS security is probably a better idea.  A proprietary
solution wouldn't work very well inter-realm.  And using CMS is more in
the spirit of the mobileip-draft, where its one comment in section 5.0
about securing keys is "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."

> 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 ?

Here's some thoughts, but bear in mind my limited understanding of CMS.

(1) Maybe AAAF2 should initiate the security relationship with AAAF1,
rather than the other way around.  That is, AAAF2 sends the DSAR before
responding with the HAA.  My thinking here is, in the case where the AAAH
wants to secure its generated keys with the FA, it is the sender of the
CMS-secured data that initiates the DSAR.

(2) The above scheme requires the CMS big gun.  In the mobile-ip draft,
the AAAH has the option of securing its generated keys via CMS, or sending
them in the clear.  So maybe CMS should be an option for the
AAAF2-generated key.  That is, AAAF2 could send the FA-HA-Key secured (per
your proposal), or could instead just send a plain old MIP-FA-to-HA-Key
AVP if the AAAF2 didn't feel the need to secure the key.

(3) In the above HAA-to-AMA-Data AVP, the diameter identity of the AAAF2
is provided.  If the AAAF1 wants to send a DSAR to AAAF2, it might also be
necessary to include AAAF2's realm in the HAA-to-AMA-Data AVP, so that
AAAF1 can fill in both the Destination-Realm and Destination-Host of the
DSAR, for routing.

(4) "Originating-Foriegn-Home-Key-Distr-Host" is one heck of name.  With
the thought of minimizing the creation of new AVPs, could we just use the
"Origin-Host" and "Origin-Realm" AVPs as members of HAA-to-AMA-Data?  The
idea is, when "Origin-Host" and "Origin-Realm" are members of a grouped
AVP, they represent the originator of that AVP.  So AAAF2 could fill in
his identity as the Origin-Host member of HAA-to-AMA-Data.

(5) Also in the interest of not unnecessarily creating new AVPs, maybe
just use the existing MIP-FA-to-HA-Key AVP instead of the new
HAA-to-AMA-Data AVP.  The idea here is that nowadays Diameter allows
grouped AVPs to have variable member AVPs.  So the MIP-FA-to-HA-Key AVP
could contain different sets of member AVPs that represent either
encrypted or non-encrypted FA-HA information.  That is, the
MIP-FA-to-HA-Key AVP could be something like:

  MIP-FA-to-HA-Key ::= < AVP Header: 328 >   // non-encrypted case
                       { MIP-FA-to-HA-SPI }    
                       { MIP-Algorithm-Type }
                       { MIP-Session-Key }
                     * [ AVP ]

  MIP-FA-to-HA-Key ::= < AVP Header: 328 >   // encrypted case
                       { Origin-Realm } // = AAAF2's realm, if necessary 
                       { Origin-Host } // = AAAF2's host, if necessary
                       { CMS-Encrypted-Data }
                           //(or {MIP-Session-Key-Material}?)
                     * [ AVP ]

(6) If the AAAF2 wanted to send back a CMS-encrypted version of the FA-HA
key, then the single AMA sent from the AAAH to AAAF1 could contain two
sets of CMS-secured AVPs, with two different sources and destinations.
That is, the AMA could contain FA-HA key data, CMS-secured between AAAF2
and AAAF1, and also could contain FA-MN key data, CMS-secured betweeen
AAAH and FA.  Can CMS/AMAs piggyback stuff this way?

> 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.

---

From: Tony Johansson <[email-masked]>
Date: Wed, 30 Jan 2002 19:17:46 -0800

Hi Bob,

Thanks for your comments I think we are getting somewhere here:)

please find my comments embedded...

Regards,

Tony

Bob Kopacz wrote:

> the spirit of the mobileip-draft,

> where its one comment in section 5.0

> CMS-secured data that initiates the DSAR.

Right. Since it is the AAAF2 that will create the FA-HA Key and also the one that
will decide if the key needs to be encrypted or not. However, there is no way for
the AAAF2 to know from which domain this MN is requesting to keep the HA (the
only thing the AAAF2 know is that it has no pending AMR for this user from one of
its FAs). So, for the AAAF2 to really be able to decide if the FA-HA key needs to
be encrypted or not  it needs to know the originating domain.

So, what about introduce the following new AVP:

Originating-Foreign-AAA ::= < AVP Header: YYY >
                       { Origin-Realm } // = AAAF1's realm
                       { Origin-Host }  // = AAAF1's host-name

The Originating-Foreign-AAA AVP would be added in the AMR by the AAAF1 in the
case that the Home-Address-Allocatable-Only-in-Home-Realm flag are set to
zero...(i.e. in all cases when the HA is not allocated in the home domain).

So, if the Originating-Foreign-AAA AVP is present in the AMR the AAAH must copy
it into the HAR. The AAAF2 would then have the necessary info for the above..

>                            //(or {MIP-Session-Key-Material}?)

I don't think this would be such a good idea to try to reuse that same AVP. I
think we need new grouped AVP for the encryption case since we need a completely
new set of mandatory AVPs. So what about the following:

 MIP-Encrypted-FA-to-HA-Key ::= < AVP Header: YYY>
                       { CMS-Encrypted-Data }
                     * [ AVP ]

The FA-HA key would be encrypted in the CMS-Encrypted-Data AVP with AAAF1 SA. The
originator info is part of the CMS envelop-data header. So, I don't think we need
to add an Origin-Realm AVP and an Origin-Host AVP. Upon receiving the HAA the
AAAH only has to copy the MIP-Encrypted-FA-to-HA-Key AVP to the AMA back to the
AAAF1 (i.e. in the same fashion as when  the FA-HA Key is distributed in clear
text, which is describe in the draft today).