Subject: RE: [mobile-ip] I-D ACTION:draft-ietf-mobileip-aaa-key-08.txt

From: "Carroll, Christopher X" <[email-masked]>
Date: Fri, 27 Jul 2001 12:20:48 -0400

Hi Pat and Junhyuk,

Just a few comments regarding Junhyuk's observations:

The MN-FA key need not be used for MIP registration authentication only.
The MN-FA key is a security association which can be used to enable other
security services such as message encryption or authentication between the
MN and FA.

Junhyuk raises an interesting question that I alluded to in earlier e-mails:
"Does the MN always possess only one MN-HA key or can it possess a series of
MN-HA keys, one associated with each HA that it interfaces with?"  Stated
differently, "Does the AAA potentially pass the same MN-HA key to each HA
when the MN is dynamically assigned a new HAs?"  Finally, "Should the AAAh
generate a new MN-HA key for each dynamic HA assignment?"

In 3GPP2, the MN appears to possess one MN-HA key.  Thus, when the MN is
dynamically assigned to a new HA and registers, it uses the previously
generated MN-HA key (also stored in the AAAh server) to generate the
Mobile-Home Authentication Ext.  When the new HA receives the RRQ and has no
MN-HA key, it requests the MN-HA key from the AAAh and then checks the
Mobile-Home Auth. Ext.  

Therefore, Junhyuk's comment that the HA must accept the initial
registration without checking the MN-HA Auth. Ext. is not completely
accurate in the 3GPP2 environment.  His scenario only applies to the
situation (within 3GPP2) in which the MN has no MN-HA key (when the MN is
initially provisioned).  Note: this may never occur where a service provider
bootstraps the MN-HA key (using an out-of-band method) during initial
provisioning.  If the MN and HA have different MN-HA keys, the MN-HA key
update process is inefficient, but should rarely occur.  Verizon Wireless
will never allow the HA to accept an RRQ that is not authenticated.

Is it acceptable to allow the AAAh to pass the MN-HA key to a new HA?  Yes,
at least in the 3GPP2 environment where the network service provider will
control and trust all of the HAs.  It is extremely unlikely (at least until
Diameter is available) that Verizon Wireless would allow HAs under a private
company or individual's control.  In the 3GPP2 environment, it is likely
unnecessary to update the MN-HA key for every new HA assignment. 

From one perspective, the purpose of the MN-HA key, derived from the MN-AAA
key using a one-way function, is to protect the root MN-AAA key.  If, as
Junhyuk proposes, the MN-AAA auth. Ext. is passed to the HA, the HA must
check the extension using the MN-AAA key - not a good idea.  The MN-AAA key
is the root secret for the system and must reside in one, well-protected
location - the AAA server (also in the MN).  I realize that RADIUS AAA is an
add-on to the original MIPv4 and is somewhat inefficient.  However, I would
rather protect the MN-AAA key and allow the AAAh to pass a modifiable MN-HA
key to a new HA.  If the MN-HA key is compromised, the AAAh can update it.
If the MN-AAA key is compromised, then the service provider must distribute
a new MN-AAA key to potentially millions of MNs.

As an alternative to using the Foreign-Home Auth. Ext., 3GPP2 service
providers will use IPsec between the PDSN/FA and the HA.  I don't beleive it
is necessary to mandate HA-FA authentication especially since other
alternatives exist to protect that link.

regards,

chris

On Fri, Jul 27, 2001 at 09:07:20PM +0900, junhyuk song wrote:
> Hi Pat,
> 
> I don't see the need for MN-FA shared key while using FAC and MN-AAA
authentication.
> The AAAH will verify Mobile Node for Foreign Agent with MN-AAA
authenticatiion defined in RFC3012.  It seems to me using MN-FA Auth and FAC
with MN-AAA Auth together is somewhat redundant.

It isn't redundant since the AAA and the FA may be owned by separate 
administrative domains. Having said that, no where in the draft does it
state that the MN-FA is to be present if the MN-AAA is present.

> Besides, I wish you made separate section for RADIUS consideration in your
draft.

why? This draft discusses how the keys are sent to the mobile node, not
to a RADIUS and/or Diameter device.

The AAA software used is completely irrelevant to this draft (unless I
missed
something).

> Further more the RADIUS based AAA case must be noted for DOS attack
consideration, because HA will blindly procede Mobile IP signalling and AAA
message without MN-HA authentication for the initial RRQ.  Another approach
is clearly defining MN-AAA authentication from HA before AAAH procede to
generate "Key Material" and "Mn-HA shared key".

Right, and this was one of the reasons why we decided to allow the FA to
forward the messages to the AAA infrastructure in Diameter. 3GPP2 decided
to let the HA to the work, and that is simply the wrong approach, and will
lead to DoS attacks. I've brought this up numerous times, and the real fix
is to change how 3GPP2 handles AAA (not necessarily the protocol, but rather
the way it uses RADIUS).

> It also may be helpful to mandate HA-FA authentication between FA and HA.

If keys are generated, yes, but this is not covered by this draft. It seems
like what you are requesting is really in the Diameter Mobile IP
application,
and not in this one.

PatC

---

From: Pat Calhoun <[email-masked]>
Date: Fri, 27 Jul 2001 09:26:37 -0700

Christopher,

I think you missed my original point.

In the Diameter model, the absence of the MN-HA is acceptable because
there is inherent trust between the AAAH and the HA. So, if the mobile is
authenticated on the AAAH, and an authenticated message is sent from the AAAH
to the HA, then the HA will use that as a replacement to the MN-HA.

The issue is how 3GPP2 decided to make use of RADIUS. They didn't have alot
of choices due to the protocol's inability for servers to send unsolicited
messages to clients (but I believe this has been added anyways since then).
So, this is really a RADIUS deficiency, and I see no reason for Mobile IP
to design a secure network for 3GPP2, when the RADIUS (the IETF version,
not w/ 3GPP2's extensions) cannot provide that.

PatC