Subject: [AAA-WG]: ISSUE 266: ready for closure?

From: Tony Johansson <[email-masked]>
Date: Thu, 21 Feb 2002 14:56:37 -0800

All,

Here is the text proposal for issue 266 based on the outcome of the
previous thread discussion regarding issue 266: "Returning
AAAF-Generated FA-HA Key to FA".

This proposal is based on CMS in case of encryption and the fact the we
are allowed to issue DSA messages between two servers, even in the case
where non of the servers belong to the users home domain (see
http://www.merit.edu/mail.archives/aaa-wg/thismonth/msg00042.html).
Stephen, Jari and other CMS knowledge people please let me know if you
have any comments / objection to the usage of CMS in the case of
encryption of the FA-HA Key below.

Comments / objections

/Tony

....................................................................................................................................

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 [MIPREQ, CDMA2000].
   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.

      ..............

4.11 MIP-Originating-Foreign-AAA AVP

   The MIP-Originating-Foreign-AAA AVP (AVP Code TBD) 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 ]

       ..............

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 check if a
   security association can be established using DSA messages defined in

   the CMS application [CMS] 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.

   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.

   .........

---

From: "Bob Kopacz" <[email-masked]>
Date: Mon, 25 Feb 2002 10:04:55 -0500

Hi Tony,

(1) One thought: If the AAAH wants to hide an AAAH-generated key being
sent to the FA (or foreign HA), the AAAH sets up a CMS security
assocation with the FA (or foreign HA), not with the AAAF.  If the
destination AAAF wants to hide the FA-HA key, shouldn't it then just
do the same, i.e. set up a CMS security assocation with the FA, rather
than adding protocol and setting up a CMS security assocation with the
originating AAAF?  Otherwise, an AAAH wanting to hide an FA-HA key and
an AAAF wanting to hide an FA-HA key invoke different solutions.
When, in the course of the mailing list dialogue, the HAA-to-AMA-Data
AVP was superseded by CMS, this thought hadn't occurred to me.

(2) If this thought was adopted, then we wouldn't need the
MIP-Originating-Foreign-AAA AVP, since the destination AAAF would be
setting up his DSA with the FA.  However, the destination AAAF would
need to know the FA's DiameterIdentity and the FA's Realm, so the DSAR
could be routed.  In the HAR, the MIP-Foreign-Agent-Host AVP conveys
the FA's DiameterIdentity but not the FA's Realm.  So maybe the
MIP-Foreign-Agent-Host AVP should be replaced by a MIP-Foreign-Agent
grouped AVP, with two members representing the FA's DiameterIdentity
and the FA's Realm.

The rest of my comments are inline.

> From: Tony Johansson [[email-masked]]
> Sent: Thursday, February 21, 2002 5:57 PM
> To: [email-masked]
> Subject: [AAA-WG]: ISSUE 266: ready for closure?
>    
> All, 
>    
> This proposal is based on CMS in case of encryption and the fact the
> we are allowed to issue DSA messages between two servers, even in the
> case where non of the servers belong to the users home domain (see

(3) I don't quite understand how the mobile node "requests" a home
agent in the foreign network.  Maybe the word "request" is what
confuses me.

That is, the MN can request that a HA be assigned by sending an HA IP
address of all zeroes or all ones. 255.255.255.255 means the HA must
be allocated in the home network, while 0.0.0.0 means the HA can be
allocated in either the local foreign network or the home network. But
neither case indicates a preference for a foreign HA over a home
network HA.

Maybe "requests" means the MN specifies the real IP address of a real
HA.  In that case the MN is just specifying the HA's IP address, but
not indicating whether the HA is in the home realm or a foreign realm.

(4) I don't understand how the originating AAAF intelligently sets the
Home-Agent-In-Foreign-Network flag. 

That is, suppose the MN sends a "real" HA IP address (not all zeroes
or all ones).  The AAAF only sees an IP address.  The AAAF doesn't
know just from the HA's IP address whether that represents an HA in
the home network, or an HA in another foreign network.  And maybe
doesn't even know if the IP address is in his own network.  So how
does the AAAF set the Home-Agent-In-Foreign-Network flag?

It seems that the AAAF would send the MIP-Originating-Foreign-AAA AVP
if there is the possibility that the originating AAAF might be part of
a DSA.  That can happen if either: (a) the AAAF is offering to provide
the HA and is sending the MIP-Candidate-Home-Agent-Host AVP, or (b)
the MN has specifed a "real" HA IP address (not 0.0.0.0 or
255.255.255.255).  If the MIP-Originating-Foreign-AAA goes away, then
this is moot.  The rule would be that the AAAH always manufactures and
sends the new grouped MIP-Foreign-Agent in the HAR.

> HAR message to the AAAF that does not contain the MIP-Home-Agent- 
                     ^^^^
Technically, the HAR is sent the HA, since the HAR's Destination-Host
is the HA.

> determining if the FA-HA Key should be encrypted or not. 

If the destination AAAF sets up the DSA with the FA, then the above
AVP definition goes away.

(5) Add a section header here, preceding the paragraph that follows:

5.4.1 Home Agent in the home network

> is cached in the AAAH until the HAA is received. 

(6) Replace the last sentence by:

"The corresponding session key and algorithm that is to be sent to the
foreign agent is cached in the AAAH until the HAA is received."

> using the SPI in the MIP-FA-to-HA-SPI, and includes the AVP in the 

(7) Add a section header here:

5.4.2 Home Agent in the foreign domain

> be sent to the foreign agent is cached in the AAAF until the HAA is 

(8) Replace the last sentence by:

"The corresponding session key and algorithm that is to be sent to the
foreign agent is cached in the AAAF until the HAA is received."
> with DIAMETER_ERROR_NO_FOREIGN_HA_SERVICE. 

(9) Since CMS is a new protocol being rolled out, couldn't the
destination AAAF attempt to set up this DSA (because the AAAF
"prefers" to hide the FA-HA key), and if the DSA fails, then have the
fallback option to send the FA-HA key in the clear.  Rather than what
the final sentence requires ("if the DSA establishment fails, the AAAF
MUST return a Result-Code AVP with DIAMETER_ERROR_NO_FOREIGN_HA_SERVICE.")

> MIP-FA-to-HA Key to the HAA, upon reception from HA and forward the 

(10) Add the following sentence:

"In either case, the AAAF removes the MIP-FA-to-HA-SPI AVP from the
HAA returned to the AAAH."

> Registration Reply, using the newly distributed key. 

Bob K.

---

From: Tony Johansson <[email-masked]>
Date: Mon, 25 Feb 2002 15:19:15 -0800

Hi Bob,

Well, we must still make it possible encrypt the FA-HA Key between the
two AAAFs involved, since there is only a SHOULD for Diameter clients to
support DSA. Furthermore, how often do we really see the scenario where
the home AAAF and the FA don't trust each other so that it is not enough
to encrypt between the two AAAF servers?!

/Tony

Bob Kopacz wrote:

>  Hi Tony,(1) One thought: If the AAAH wants to hide an AAAH-generated
> key being
> AVP was superseded by CMS, this thought hadn't occurred to me. (2) If
> this thought was adopted, then we wouldn't need the

---

From: Tony Johansson <[email-masked]>
Date: Mon, 25 Feb 2002 19:25:33 -0800

Hi Bob,

Please find comments embedded..

/Tony

Bob Kopacz wrote:

> > node's current session. (3) I don't quite understand how the mobile
> node "requests" a home
> confuses me. That is, the MN can request that a HA be assigned by
> sending an HA IP
> network HA. Maybe "requests" means the MN specifies the real IP
> address of a real
> [Tony] Correct. This is in the case that the MN specifies the real IP
> a real HA.
>
> Home-Agent-In-Foreign-Network flag. That is, suppose the MN sends a
> "real" HA IP address (not all zeroes
> [Tony] E.g. the AAAF could use a DNS look up to find out the HAs realm
> and host name.
>
> [Tony] That will not work, since the FA may not support DSA. See Base
> section 2.0. So, if we need an AVP that can carry iether the
> originating AAAF or the FA depending on the support of DSA or not...
>
> [Tony] Okay I will clarify that.
>
> > >     ..............>
> > (5) Add a section header here, preceding the paragraph that
> follows: 5.4.1 Home Agent in the home network > In the cases when the
> AAAH generates the Foreign-Home session key,
> > is cached in the AAAH until the HAA is received. (6) Replace the
> last sentence by: "The corresponding session key and algorithm that is
> to be sent to the
> [Tony] Check.
> > AMA. (7) Add a section header here: 5.4.2 Home Agent in the foreign
> domain > In the cases when the AAAF generates the Foreign-Home session
> key
> > received. (8) Replace the last sentence by: "The corresponding
> session key and algorithm that is to be sent to the
> [Tony] Check
> > with DIAMETER_ERROR_NO_FOREIGN_HA_SERVICE. (9) Since CMS is a new
> protocol being rolled out, couldn't the
> 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
> > (10) Add the following sentence: "In either case, the AAAF removes
> the MIP-FA-to-HA-SPI AVP from the
> [Tony] Check.

---

From: Tony Johansson <[email-masked]>
Date: Mon, 25 Feb 2002 22:34:39 -0800

Bob Kopacz wrote:

> DIAMETER_ERROR_NO_FOREIGN_HA_SERVICE.")

That sounds very dangerous to me. I would rather return the Result-Code
AVP with DIAMETER_ERROR_NO_FOREIGN_HA_SERVICE, which would instead force
the nodes to be reconfigured to send the FA-HA key in clear text.

/Tony

---

From: "Bob Kopacz" <[email-masked]>
Date: Tue, 26 Feb 2002 12:10:12 -0500

Hi Tony,
   
> > an AAAF wanting to hide an FA-HA key invoke different solutions. When,
> > in the course of the mailing list dialogue, the HAA-to-AMA-Data AVP
> > was superseded by CMS, this thought hadn't occurred to me. 
> 
> Hi Bob, 
> 
> two AAAFs involved, since there is only a SHOULD for Diameter clients
> to support DSA. 
> 
> /Tony 

Your note that clients are not required to support CMS is a good one,
so I'm back on track with you.  Forget my "One thought".

But now I've got another problem:

Because clients are not required to support CMS, the proposed
issue#266 solution (for the case where the HA is in a foreign realm
and the destination-AAAF generates the FA-to-HA key and wants to hide
it) is to set up a DSA between the originating-AAAF and the
destination-AAAF, and pass the FA-to-HA-Key as encrypted CMS data.
And the FA trusts his local AAAF, so no hiding is required for the
final hop. All is good.

Question: This "client might not support CMS" problem affects all the
keys that might need to be hidden, not just the FA-HA key, right?

That is, suppose we have the simple case where we have an FA in
foreign domain talking to his local AAAF, and the HA is in the home
network.  

Suppose the AAAH wants send FA-to-xx keys back to the FA via the AMA,
but wants to hide them, as the AMA may be traversing intermediate
networks.

If so, my understanding is that the AAAH would set up a DSA with the
FA and pass the CMS-encrypted keys to the FA, which may not work
because the FA doesn't do CMS.

If the solution is to have the AAAH instead set up a DSA with the
originating-AAAF and pass the hidden keys ala Issue#266, then this is
ok, but would need to be added to the draft-mobileip.

This also applies in another case: if the AAAH is generating an 
HA-to-MN-Key for the HA in a foreign network, and wants to hide it.

Bob K.

---

From: "Bob Kopacz" <[email-masked]>
Date: Tue, 26 Feb 2002 12:32:42 -0500

Hi Tony,

> > "real" HA IP address (not all zeroes or all ones).  The AAAF only sees
> > an IP address.  The AAAF doesn't know just from the HA's IP address
> > whether that represents an HA in the home network, or an HA in another
> > foreign network.  And maybe doesn't even know if the IP address is in
> > his own network.  So how does the AAAF set the
> > Home-Agent-In-Foreign-Network flag? 
> 

If this is what the AAAF would have to do to correctly set the
Home-Agent-In-Foreign-Network flag, then maybe we should just get rid
of this flag altogether.  Or change it to a flag that is not set by
the originating-AAAF, but instead by the AAAH.

The reason is that, if the AAAF is using DNS to find out the HA's
realm and host name, the AAAF is just duplicating work the AAAH has to
do anyway: When the AAAH receives the AMR with the a specified HA IP
address, the AAAH has to map this IP address into the HA's realm and
DiameterIdentity, which will be used as the Destination-Realm and
Destination-Host of the HAR.  The AAAH may be able to do this a lot
easier than the AAAF, as a session-stateful AAAH may just have this
information at hand.

Bob K.

---

From: Tony Johansson <[email-masked]>
Date: Tue, 26 Feb 2002 19:14:16 -0800

> so I'm back on track with you.  Forget my "One thought".

Good, so do we agree on the solution for issue #266 (with the editorial
changes you sent earlier)?

---

From: "Bob Kopacz" <[email-masked]>
Date: Thu, 28 Feb 2002 08:13:53 -0500

Hi Tony,

> -----Original Message-----
> From: Tony Johansson [mailto:[email-masked]]
> Sent: Tuesday, February 26, 2002 10:14 PM
> To: Bob Kopacz
> Cc: [email-masked]
> Subject: Re: [AAA-WG]: ISSUE 266: ready for closure?
> 
> Bob Kopacz wrote:
> 
> > >

Yes.

I do think that at some point we need another (separate) issue, to
indicate that the AAAH solves his key-hiding in a similar way, i.e.
setting up a DSA with the AAAF rather than the FA or HA.

Bob K.