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

From: Thomas Panagiotis-PTHOMAS1 <[email-masked]>
Date: Fri, 1 Feb 2002 08:31:57 -0600

Hi,

Tony Johansson wrote:
> However, there is no way for the AAAF2 to know from which domain
> this MN is requesting to keep the HA...

I thought Destination-Realm in HAR = Originating-Realm in AMR, no?

If AAAF1 and AAAF2 are in the same domain, how bad would it be to
assume that they share a key? We can then maybe adopt the mechanism
used to convey the key from AAAH to MN, i.e. have AAAF2 send only
the key material to AAAF1. Just a thought...

-Panos

> -----Original Message-----
> From: Tony Johansson [mailto:[email-masked]]
> Sent: Wednesday, January 30, 2002 9:18 PM
> To: Bob Kopacz
> Cc: Mark Eklund; [email-masked]
> Subject: Re: [AAA-WG]: [issue] Returning AAAF-Generated FA-HA 
> Key to FA
> 
> 
> Hi Bob,
> 
> Thanks for your comments I think we are getting somewhere here:)
> 
> please find my comments embedded...
> 
> Regards,
> 
> Tony
> 
> Bob Kopacz wrote:
> 
> > 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.
> 
> 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..
> 
> 
> 
> >
> >
> > (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 ]
> >
> 
> 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).
> 
> 
> 
> 
> >
> > (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: Fri, 01 Feb 2002 11:55:21 -0800

Hello Thomas,

> I thought Destination-Realm in HAR = Originating-Realm in AMR, no?

Well, in the HAR sent from the AAAH to the AAAF2, there is no info for the
AAAF2 telling from which domain the MN is issuing the request. So, if the
AAAF1 is in foreign1.com issuing AMR to AAAH in home.com, which then issues
the HAR to AAAF2 in foreign2.com. Upon receiving the HAR the AAAF2 wouldn't
know that the MN is in foriegn1.com....

>
>
> If AAAF1 and AAAF2 are in the same domain

We still need a mechanism for the AAAF2 to know if AAAF1 is in the same
domain. So, I think we need a something like the Originating-Foreign-AAA
AVP.

Regards,

Tony

---

From: Tony Johansson <[email-masked]>
Date: Mon, 04 Feb 2002 14:52:52 -0800

All,

Here is proposed text for the handling of the FA-HA Key based on the discussion
last week.

Comments, please...

Regards,

/Tony

-----------------------------------------------------------------------------------

   * New text to section - 1.4 Allocation of Home Agent in Foreign Network

"The Diameter Mobile IP application allows a Home Agent to be   allocated in a
foreign network, as required in [3, 16]. When a foreign agent detects that the
mobile node has a home agent address  equal to 0.0.0.0 or 255.255.255.255 in
the Registration Request  message, it MUST add a MIP-Feature-Vector AVP with
the Home-Agent- Requested flag set to one. If the home agent address is equal
to 255.255.255.255, then the foreign agent also MUST set the
Home-Address-Allocatable-Only-in-Home-Realm flag equal to one. If the home
agent address is set to 0.0.0.0, the foreign agent MUST set the
Home-Address-Allocatable-Only-in-Home-Realm flag equal to zero.

When the AAAF receives an AMR message with the Home-Agent-Requested  flag set
to one, and the Home-Address-Allocatable-Only-in-Home-Realm flag equal to zero,
the AAAF MAY set the Foreign-Home-Agent-Available flag in the
MIP-Feature-Vector AVP to inform the AAAH that it is willing and able to assign
a Home Agent for the Mobile Node. When doing so, the AAAF MUST include the
MIP-Candidate-Home-Agent-Host AVP and the MIP-Originating-Foreign-AAA-AVP. The
MIP-Candidate-Home-Agent-Host AVP contains the identity of the home agent that
would be assigned to the mobile node and the MIP-Originating-Foreign-AAA AVP
contains the identity of the AAAF.

In the event that the mobile node requests a home agent in the foreign network,
and the AAAF authorizes its use, the AAAF MUST set the
Home-Agent-In-Foreign-Network bit in the MIP-Feature-Vector AVP. This could
happen when the AAA request is sent to "extend" a mobile node's current
session.

When the AAAH receives an AMR message, it first checks the authentication data
supplied by the mobile node, according to the MIP-Reg-Request AVP and
MIP-MN-AAA-Auth AVP, and determines whether to authorize the mobile node.  If
the AMR indicates that the AAAF has offered to allocate a home agent for the
mobile node, then the AAAH  must decide whether its local policy would allow
the user to have a Home Agent in the foreign network. If so, and after checking
authorization from the data in the AMR message, the AAAH sends the HAR message
to the AAAF that does not contain the MIP-Home-Agent-Address, but includes the
Destination-Host AVP set to the value of the AMR's
MIP-Candidate-Home-Agent-Host AVP.

If the HA hasn't yet been allocated by the foreign domain, the HAR sent by the
AAAH back to the foreign realm will not necessarily be received by the same
AAAF which sent the AMR. Therefore the AAAH MUST always copy the
MIP-Originating-Foreign-AAA-AVP from the AMR message to the HAR message. In
cases when another AAAF, which may not reside in the same domain, receives the
HAR, thus the new AAAF will use the MIP-Originating-Foreign-AAA-AVP for policy
decisions, such as determining if the FA-HA Key should be encrypted or not."

   * Section 2.1 and section 2.3, add  [ MIP-Originating-Foreign-AAA ] to ABNF

   * Section 2.2 and 2.4, add [ MIP-Encrypted-FA-to-HA-Key ] to ABNF

   * Add MIP-Originating-Foreign-AAA in section 4 as:

"4.11 MIP-Originating-Foreign-AAA AVP

   The MIP-Originating-Foreign-AAA AVP (AVP Code ZZZ) if of type
   Grouped, and contains the identity of the AAAF which issues the AMR
   to the AAAH. The MIP- Originating-Foreign-AAA AVP MUST only be used in
   cases when the home agent is or may be allocated in a foreign domain. If
present
   in the AMR, the AAAH MUST copy the MIP-Originating-Foreign-AAA AVP
   into the HAR.

      MIP-Originating-Foreign-AAA ::= < AVP Header: ZZZ >
                             { Origin-Realm }
                             { Origin-Host }
                           * [ AVP ]"

   * New text to section - 5.4  Distributing the Foreign-Home Session Key

" If the home agent is in the home realm, then the AAAH has to generate the
Foreign-Home session key. Otherwise, it is generated by AAAF.

In the cases when the AAAH generates the Foreign-Home session key, 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 in the AAAH until the HAA is
received.

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.

Upon receipt of the HAA, the AAAH adds the MIP-FA-to-HA Key AVP, using the SPI
in the MIP-FA-to-HA-SPI, and includes the AVP in the AMA.

In the cases when the AAAF generates the Foreign-Home session key (home agent
in foreign domain), the AAAF will, upon receipt of the HAR message, generate
the Foreign-Home session key and include the session key in the
MIP-HA-to-FA-Key AVP as part of the HAR message forwarded to the home agent.
The corresponding session key that is to be sent to the foreign agent is cached
in the AAAF until the HAA is received.

Upon receipt of the HAA, the AAAF creates the MIP-FA-to-HA Key AVP, using the
SPI in the MIP-FA-to-HA-SPI. The AAAF then checks if the Foreign-Home session
key destined for the foreign agent needs to be encrypted.

If the session key needs to be encrypted, the AAAF will include a
MIP-Encrypted-FA-to-HA Key AVP, which will include the MIP-FA-to-HA Key AVP,
protected using the CMS application [9] with the AAAF as originator and the
recipient copied from the MIP-Originating-Foreign-AAA AVP. The
MIP-Encrypted-FA-to-HA Key AVP MUST only be used if both the originator and the
recipient supports the CMS application.

Upon reception of the HAA, the AAAH will copy the MIP-FA-to-HA Key AVP or the
MIP-Encrypted-FA-to-HA Key AVP into the AMA.

If the MIP-Encrypted-FA-to-HA Key AVP was present in the AMA, the AAAF MUST
decrypt the AVP using the CMS application [9].

If a Foreign-Home session key was present in the AMA, the foreign agent MUST
include the Mobile-Foreign authentication extension in the Registration Reply,
using the newly distributed key. "

   * Add MIP-Encrypted-FA-to-HA-Key AVP in section 6 as:

" 6.3  MIP-Encrypted-FA-to-HA-Key AVP

   The MIP-Encrypted-FA-to-HA-Key AVP (AVP Code YYY) is of type Grouped,
   and contains the Foreign Agent's session key encrypted in a CMS-
   Encrypted-Data AVP [9]. Its Data field has the following ABNF
   grammar:

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

---

From: "Bob Kopacz" <[email-masked]>
Date: Mon, 4 Feb 2002 23:05:54 -0500

Hi Tony,

Here's a little feedback.

> From: "Tony Johansson" <[email-masked]>
> To: <[email-masked]>
> Cc: "Thomas Panagiotis-PTHOMAS1" <[email-masked]>; 
>     "Bob Kopacz" <[email-masked]>; 
>     "Mark Eklund" <[email-masked]>
> Subject: Re: [AAA-WG]: [issue] Returning AAAF-Generated FA-HA Key to FA
> Date: Monday, February 04, 2002 5:55 PM
> 
> All,
> 

You may want to mention that it is the AAAH that decides the key lifetime
for all of the keys, even if the FA-HA key is generated by the destination
AAAF.

> recipient supports the CMS application.

(1) How does the destination AAAF know if the origin AAAF supports the CMS
application?  It seems there are two ways: (a) When the destination AAAF
sends his DSAR, it is unsuccessful, or (b) the origin AAAF can signal that
it doesn't support the CMS security application by NOT sending the
MIP-Originating-Foreign-AAA AVP, thus not inviting a DSA.

(2) However, since both of the AAAFs are servers, isn't it a requirement
that they support the CMS application?  Section 1 "Introduction" of the
CMS draft says that "Diameter servers: MUST support DSA messages; MAY
support PDS messages"

(3) In order to allow the two AAAF's to set up a security assocation, the
CMS draft needs a minor editing change, to remove a restriction.  Section
1.6 "Who can authorize users" of the CMS security draft says that
"However, it is important to note that one of participants of a DSA
(specifically the one in the home network) MUST belong to the same realm
as the user being authorized (the realm portion of the Network Access
Identifier found in the User-Name AVP), otherwise an answer is returned
with the Result-Code AVP set to DIAMETER_AUTHORIZATION_REJECTED." Neither
of the AAAFs is in the home realm, but my understanding is that CMS would
still work.

(4) Did you want to say that the AAAF, after receiving the HAA from the HA
but before sending the HAA to the AAAH, sets up the DSA with the
originating AAAF, if the FA-HA key needs to be encrypted?

>       MIP-FA-to-HA-Key ::= < AVP Header: YYY >
        ^^^^^^^^^^^^^^^^
        MIP-Encrypted-FA-to-HA-Key

---

From: "Bob Kopacz" <[email-masked]>
Date: Tue, 5 Feb 2002 10:03:35 -0500

Hi Tony,

A few more comments.  Again bear in mind my CMS limitations.

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

(1) I think the way that CMS works is that the CMS-Encrypted-Data AVP is a
standalone AVP (not a member of a grouped AVP).  When the destination
decrypts the CMS-Encrypted-Data AVP, one or more AVPs are revealed.  In
this case, when the originating AAAF decrypts the CMS-Encrypted-Data AVP,
he will find a MIP-FA-to-HA-Key AVP.  So instead of returning a
MIP-Encrypted-FA-to-HA-Key AVP in the HAA, the destination AAAF would
return a CMS-Encrypted-Data AVP.

(2) Therefore do we even need the new MIP-Encrypted-FA-to-HA-Key AVP? The
only reason I can think of why we might need it would be this: I have a
recollection (which may be wrong so I may be all wet here) that CMS
pre-defines which AVPs are to be encrypted and which are not.  If so, then
we might need a MIP-Encrypted-FA-to-HA-Key AVP, but its member AVPs would
be the same as the MIP-FA-to-HA-Key AVP.  The rule would be that the
MIP-FA-to-HA-Key AVP wouldn't be encrypted, and the
MIP-Encrypted-FA-to-HA-Key AVP would be encrypted.  But I'd rather not
have to manufacture a AVP for this purpose, I'd rather have the
originating AAAF decrypt the CMS-Encrypted-Data AVP and say "Gosh, look, a
MIP-FA-to-HA-Key AVP, I know just what to do with this".

(3) In the case where the originating AAAF and the destination AAAF are
the same server, and the AAAF wants to encrypt the FA-HA-key, then the
same mechanism would be used to return the encrypted key to himself, but
the setup of the security association with himself could be skipped.  That
is, the destination AAAF would encrypt the FA-HA-key with his public key
in the HAA, and the originating (same) AAAF would decrypt the FA-HA-key
with his private key.  True?

(4) The node which sends the CMS-Encrypted-Data (destination AAAF) is not
the same as the node which originates the AMA (AAAH).  Are there any
assumptions/requirements in CMS that the originator of a
message's CMS-Encrypted-Data AVP be the same as the originator of the
message?

Bob K.

---

From: Tony Johansson <[email-masked]>
Date: Tue, 05 Feb 2002 10:59:24 -0800

Bob Kopacz wrote:

> sends his DSAR, it is unsuccessful,

Right, that was the idea since the AAAF supports DSA messages (as you mention in bullet 2
below). Thus, the destination AAAF would check if security association and encryption can
be establish between the two AAAF nodes.

> or (b) the origin AAAF can signal that

> CMS draft says that "Diameter servers: MUST support DSA messages; MAY

See above..

> of the AAAFs is in the home realm, but my understanding is that CMS would

Hmmm, you are right. So could we change the text in the CMS application so that any two
nodes can set up security associations?

> originating AAAF, if the FA-HA key needs to be encrypted?

Yes, I will make the text more explicit.

> >       MIP-FA-to-HA-Key ::= < AVP Header: YYY >

Check.

---

From: "Bob Kopacz" <[email-masked]>
Date: Tue, 5 Feb 2002 14:19:50 -0500

Hi Tony,

> Hmmm, you are right. So could we change the text in the CMS 
> application so that any two nodes can set up security associations?

To my understanding, yes.  My take on the "one of participants ... 
MUST belong to [the user's home realm]" is that this is not a CMS 
protocol restriction, but is a comment by an editor who, at the time, 
probably didn't envision a case such as yours, where both ends of the security
association are outside of the home realm.

This is an aside, but being one of low CMS IQ, it SEEMS that any node
can send another node CMS-secured data without first setting up a
security association, as long as the CMS-originating node knows
the CMS-destination's public key.  The destination node would just go 
ahead and successfully decrypt the data using his private key.

Bob K.

---

From: Tony Johansson <[email-masked]>
Date: Tue, 05 Feb 2002 13:25:38 -0800

Bob,

By reading your comments below and thinking a little bit more. I agree with
you I think we can  discard the MIP-Encrypted-FA-to-HA-Key AVP and instead
only use the CMS-Encrypted-Data AVP.

So, what about change the text proposal for section 5.4 to the following:

"5.4  Distributing the Foreign-Home Session Key

If the home agent is in the home realm, then the AAAH has to generate the
Foreign-Home session key. Otherwise, it is generated by AAAF.

In the cases when the AAAF generates the Foreign-Home session key (home agent
in foreign domain), the AAAF will, upon receipt of the HAR message, generate
the Foreign-Home session key and include the session key in the
MIP-HA-to-FA-Key AVP as part of the HAR message forwarded to the home agent.
The corresponding session key that is to be sent to the foreign agent is
cached in the AAAF until the HAA is received.

If the session key needs to be encrypted, the AAAF will check if a security
association can be established using DSA messages defined in the CMS
application [9] with the originating host found in the
MIP-Originating-Foreign-AAA AVP. If the DSA establishment is successful, the
AAAF will encrypt the MIP-FA-to-HA Key AVP in a CMS-Encrypted-Data AVP with
the AAAF as originator and the recipient copied from the
MIP-Originating-Foreign-AAA AVP. This CMS-Encrypted-Data AVP is included by
the AAAF in the HAA destined for the AAAH. Otherwise, if the DSA establishment
fails, the AAAF MUST return a Result-Code AVP with
DIAMETER_ERROR_NO_FOREIGN_HA_SERVICE.

If the session key does not need to be encrypted, the AAAF will add
MIP-FA-to-HA Key to the HAA, upon reception from HA and forward the HAA to the
AAAH .

Upon reception of the HAA, the AAAH MUST copy either the MIP-FA-to-HA Key AVP
if present or the CMS-Ecrypted-data AVP if present and not destined for the
AAAH into the AMA.

I blieve this also covers your last bullet (4). However, we still need to
change the CMS application to allow any to AAA servers to exchange DSA
messages, regardless if they belong to the users home domain or not. Since the
DSA message exchange in this case needs to be done between two AAAF servers
where non of them belongs to the user home domain.

/Tony