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

From: "Bob Kopacz" <[email-masked]>
Date: Fri, 1 Feb 2002 10:26:43 -0500

Hi Tony,

> From: "Tony Johansson" <[email-masked]>
> To: "Bob Kopacz" <[email-masked]>
> Cc: "Mark Eklund" <[email-masked]>; <[email-masked]>
> Subject: Re: [AAA-WG]: [issue] Returning AAAF-Generated FA-HA Key to FA
> Date: Wednesday, January 30, 2002 10:20 PM
>
> Hi Bob,
>
> Thanks for your comments I think we are getting somewhere here:)

I agree.

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

This seems like a good idea.

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

But it is still ok for the AAAF2 to send the plain old
MIP-FA-to-HA-Key AVP if he doesn't feel the need for encryption?

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

(1) One more worry: the key lifetime.  Currently this is a single
MIP-Key-Lifetime AVP which contains the lifetime that applies to all
the keys.

a. Retaining this notion would mean that the AAAH and AAAF2
would have to agree on the key lifetime, presumably the AAAH would
specify the key lifetime and the AAAF2 would have to accept that as
applying to the AAAF2-generated keys.

b. Would it make sense for the AAAF2 to specify the key-lifetime for
the keys that he generates?  And if so, the AAAF2 could feed this
information back to AAAF1/FA by including the  MIP-Key-Lifetime AVP
as a member of the MIP-FA-to-HA-Key/MIP-Encrypted-FA-to-HA-Key AVPs.

Note that the MIP-Key-Lifetime AVP is currently disallowed in the
HAA message, so if the AAAH doesn't generate any keys, the AAAF2
couldn't convey the MIP-Key-Lifetime AVP for the FA-HA key, at
least not as a "standalone" (non-member) AVP.

(2) Also, section 1.2 of the mobile-ip draft says:

   "The expiration time of the
   authorization (and session keys, if allocated by the AAA server) is
   communicated through the Authorization-Lifetime AVP in the AA-Mobile-
   Node-Answer from the AAAH."

Now that we have the MIP-Key-Lifetime AVP, it is probably not true
that the Authorization-Lifetime AVP indicates the expiration time of
the session keys, right?  So the sentence should be rephrased to
remove the parenthesized phrase.

(3) Also, the sentence in section 5.0 that mentions CMS-securing the
keys should expand to include AAAH and/or AAAF2:

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

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

This is still unclear to me.  I will have to talk with a coworker that
understands CMS much better than me.

> > > Comments please...
> > > Tony

Bob K.

---

From: Tony Johansson <[email-masked]>
Date: Fri, 01 Feb 2002 16:52:16 -0800

Hi Bob

Please find my comments embedded...

> MIP-FA-to-HA-Key AVP if he doesn't feel the need for encryption?

For all other keys the AAAH is the KDC and will decide if those keys should be
encrypted or not. So, like in this case when the AAAF2 is the KDC for the FA-HA key
I don't see why we should reasoning in any other same way. Thus, it's up to the
AAAF2 to decide if the FA-HA key need to be encrypted or not.

> applying to the AAAF2-generated keys.

IMHO, I think this is the right way. Since the AAAH is the owner of the MN, I don't
see why we should complicate things even more by letting the AAAF2 decide on another
time for the FA-HA key.

> remove the parenthesized phrase.

Yes I agree, could you please submit a new issue for this. So, we don't forget it.

>     access to the session keys, they SHOULD be protected using the CMS

Yes, I'm working on some proposed text, which will cover this. I hope to have the
proposal ready later today.

Regards,

/Tony

---

From: Tony Johansson <[email-masked]>
Date: Fri, 01 Feb 2002 17:32:38 -0800

Bob,

> AAAF2 to decide if the FA-HA key need to be encrypted or not.

Hmmm, sorry for the confusing text that I just sent out in the previous mail :) What I
meant to say is simply "yes"

/Tony