Subject: [AAA-WG]: [issue] Securing the AAAH-generated session keys

From: "Bob Kopacz" <[email-masked]>
Date: Tue, 5 Mar 2002 15:54:08 -0500

Issue :                 Securing the AAAH-generated session keys
Submitter name:         Bob Kopacz 
Submitter email address:[email-masked] 
Date first submitted:   03-05-2002 
Reference: 
Document:               draft-mobileip-09 
Comment type:           Technical 
Priority:               1 
Section: 

Rationale/Explanation of issue: 

  The draft-mobileip-09 was updated per issue#266.  Issue#266
  addressed the case where the HA was in a foreign network, the
  destination AAAF generated the FA-HA key, and the destination AAAF
  wanted to use CMS to return the key to the FA in a secure manner.
  Because the mobility agents may not support CMS (CMS is a SHOULD for
  clients but a MUST for servers), the issue#266 solution was for the
  destination AAAF (i.e. the HA's AAAF) to set up a DSA with the
  originating AAAF (i.e. the FA's AAAF), and to pass the CMS-encrypted
  FA-HA key to the originating AAAF within a CMS-Encrypted-Data AVP.
  The key is thus hidden as it traverses the home domain and any
  intermediary proxy/relay AAA servers.

  Issue#266 was retricted to the case of CMS-securing the
  AAAF-generated session key.  There is a similar need to CMS-secure
  the AAAH-generated session keys, if there are intervening proxy
  networks between the home network and the mobility agent's network.

  The proposal here is for an AAAH who wants to CMS-secure its
  generated session keys, to set up a DSA with the mobility agent's
  local AAAF, and to pass the CMS-secured keys to the AAAF a la
  issue#266.

  AAAH-generated keys destined for the FA: An AAAH-generated FA-MN key
  (and maybe an AAAH-generated FA-HA key) is returned to the FA in the
  AMA, which possibly traverses intermediary proxies.  The AAAH can
  CMS-secure these keys by setting up a DSA with the FA's local AAAF,
  and passing the CMS-encrypted keys to the AAAF a la issue#266.  The
  AAAH knows the identity of the originating AAAF because this is
  kindly provided in the AMR's MIP-Originating-Foreign-AAA AVP.

  AAAH-generated keys destined for a foreign HA: The AAAH-generated
  HA-MN key is forwarded in the HAR to the HA.  If the HA resides in a
  foreign network, the HAR may traverse intermediary proxies, and the
  AAAH may want to CMS-secure this key.  Unfortunately the AAAH
  doesn't necessarily know who the destination AAAF is.  The problem
  here is that the AAAH wants to set up the DSA before forwarding the
  HAR which carries the encrypted keys.  In this case, I am currently
  stuck and soliciting suggestions.  (One goofy notion, whose only
  virtue is that it works, is this: The AAAH sends a "half-baked" HAR
  which doesn't contain the keys.  The AAAF receives this half-baked
  HAR, extracts the AAAH's identity from the half-baked HAR, sets up a
  DSA with the AAAH, who resends a fully-baked HAR with the
  CMS-encrypted keys.  Unfortunately, this entails another round
  trip.)

Requested change: 

  In section 5.0  Key Distribution Center

    > 5.0  Key Distribution Center
    > 
    > [...]
    > 
    > 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 [CMS].

  Change the first sentence to :

    "If the AAAH does not communicate directly with one or both
    mobility agents,..."

  - - -
  
  In section  5.2  Key Material vs. Session Key

    > 5.2  Key Material vs. Session Key
    > 
    > [...]
    > 
    > The session keys destined for mobility agents may be encoded using
    > the security association available between the AAA server and the
    > agents (e.g. IPSec, TLS, CMS).

  Change the above sentence to:

    "The session keys destined for mobility agents may be encoded using
    the security association available between the AAA server and the
    agents (e.g. IPSec, TLS, CMS), or, if the AAAH suspects a foreign
    mobility agent doesn't support CMS, by using the security
    association available between the AAAH and the AAA server hosting
    the mobility agent."

  - - -

  In section 5.3  Distributing the Mobile-Home Session Key

    > 5.3  Distributing the Mobile-Home Session Key
    > 

    [Need some text here to address the case where the HA is in a foreign
    network, the HA doesn't support CMS, and the AAAH wants to set up a
    DSA with the destination AAAF, and pass the CMS-encrypted HA-MN key
    to the destination AAAF.]

  - - -

  In section 5.4  Distributing the Mobile-Foreign Session Key

    > 5.4  Distributing the Mobile-Foreign Session Key
    > 
    > The Mobile-Foreign session key material is also generated by AAAH
    > (upon request) and is added to the MIP-MN-to-FA-Key AVP, which is
    > added to the HAR, and copied by the home agent into a Generalized MN-
    > FA Key Reply Extension [MIPKEYS] to the Mobile IP Registration Reply
    > message, using the SPI proposed by the Mobile Node in the MN-FA Key
    > Request From AAA Subtype extension. Further, the home agent includes
    > the SPI in the HAA's MIP-FA-to-MN-SPI AVP. The AAAH includes the
    > session key in the MIP-FA-to-MN-Key AVP in the HAA, which contains
    > the session key used by the foreign agent in the computation of the
    > Mobile-Foreign authentication extension.
    > 
    > Upon receipt of the HAA, the Diameter server responsible for key
    > allocation creates the MIP-FA-to-HA Key AVP, using the SPI in the
    > MIP-FA-to-HA-SPI. If the key is generated at the AAAF (home agent in
    > foreign domain), it adds the MIP-FA-to-HA Key AVP to the HAA and
    > sends it to the AAAH. Depending upon where the HA was located the
    > AAAH either generates the MIP-FA-to-HA Key AVP itself or extracts the
    > AVP from the HAA sent by the AAAF. The AAAH adds the MIP-FA-to-HA Key
    > to the AMA.  If the MIP-FA-to-MN-Key AVP was present in the AMA, the
    > foreign agent MUST include the Mobile-Foreign authentication
    > extension in the Registration Reply, using the newly distributed key.

  Append the following paragraph:

    "If the AAAH is returning an FA-HA or FA-MN key to the FA, and the
    AAAH wants to secure these keys because the originating AAAF is not
    a peer (there are intermediate proxies), the AAAH first sets up a
    DSA with the originating AAAF, and passes the FA's key(s) within a
    CMS-Encrypted-Data AVP in the AMA."

---

From: Tony Johansson <[email-masked]>
Date: Tue, 12 Mar 2002 20:03:00 -0800

Hi Bob and All,

I really need help from the working group on this one.

I'm not sure how we can solve this without requiring another round trip, either
based on some clever DSAA result code or with a "half-baked" HAR as describe
below. Unless, we can change the functionality and say that a user can only
belong in one AAAH. Then it would be possible to keep info in the AAAH about
the allocated HA and AAAF for CMS encryption of the HA-MN key without any extra
round trips, when the MN moves to other AAAFs and requests to keep the HA.

/Tony

---

From: "Bob Kopacz" <[email-masked]>
Date: Sat, 16 Mar 2002 12:30:06 -0500

Hi Tony,

> -----Original Message-----
> From: Tony Johansson [mailto:[email-masked]]
> Sent: Friday, March 15, 2002 5:19 PM
> To: Bob Kopacz
> Cc: Johan Johansson; David Spence; aaa-wg
> Subject: Re: [AAA-WG]: [issue] Need more explanation about handling MN
> handoffs
> >
> > What do you think? I've got an even worse idea which I will also write
> > up and send along.
> 
> Okay, I'm may looking forward to it ;-)

Or you may not.  Here it is.

Suppose we made another requirement: that mobility agents, like servers,
MUST support the CMS application.

This, in conjunction with a session-stateful AAAH, simplifies the
problem of securing session keys, i.e.:

1. While the AAAFs come and go during a mobile session, the HA is
constant.

2. The session-stateful AAAH always knows the identity of the FA and the
HA, so the AAAH can set up DSAs with these MAs and send CMS-encrypted
session keys.

3. For securing the FA-HA key that the destination AAAF may generate,
this can be done by a the AAAF passing the HA-FA and FA-HA keys to the
foreign HA.  The foreign HA can set up a DSA with the FA (rather than
having the destination-AAAF set up a DSA with the originating-AAAF),
and then the foreign HA can return the FA-HA key via the HAA, as either
a FA-HA-Key AVP or a CMS-Encrypted-Data AVP.

I don't know if this is a practical burden to place on the mobility
agents.  It's just a thought.

Bob K.