Subject: RE: [mobile-ip] Mobile IPv4 Authentication Internt Draft revision 0.1

From: "Carroll, Christopher X" <[email-masked]>
Date: Fri, 6 Jul 2001 14:46:33 -0400

Hi Junhyuk, 
Some initial comments on your revision: 
The current proposal is so different from your original proposal that it
probably should not be considered a revision. The only common theme between
your current and initial proposal appears to be the concept of using the FAC
(randomness generated by a visited network) to derive the MN-HA key (and
MN-FA key). 
I must reiterate my significant concern that your proposal allows any
visited network to control the derivation of a home network security
association (SA) - the MN-HA key. Why open the door for possible
manipulation of the MN-HA key by a fraudulent/Rogue FA? 
It appears that your primary concern with the Perkin/Calhoun proposal is the
possible inefficiency of using explicit messages to generate a unique MN-HA
key for each dynamically assigned HA.  Unfortunately, there is always a
trade-off between security and efficiency. Apparently you believe that
generation of the MN-HA key from the FAC is more efficient, however you must
concede that it is less secure than allowing the home network to control the
MN-HA key generation. 
Are you sure that MN-HA key derivation based on the FAC is more efficient?
In your proposal, the MN-HA key is generated every time the MN initially
registers in a new system at least. Thus, the MN-HA key must be
requested/passed to the HA from the AAAh for each new "MIP session". In the
Perkins/Calhoun proposal, the MN-HA key may be Update once/month, once/year,
or even once while still providing adequate security (based on at least a
90-bit key). How often do you envision that dynamic HA assignment will
occur? The Perkins/Calhoun proposal requires MN-HA key update only when an
new HA is assigned to the MN. 
Although not described in the Perkins/Calhoun proposal, it appears that the
MN could store multiple MN-HA keys (for multiple HAs) simultaneously. Thus,
when the MN is dynamically re-assigned to an HA in which an MN-HA key was
previously derived, the MN need not perform a new key update. The MN might
use a FIFO queue to hold up to 10 MN-HA keys (for 10 different HAs). Each HA
could retain the MN-HA key associated with a particular MN (based on the
MN's NAI and an internal lifetimer). If the MN is assigned an HA for which
it has no MN-HA key, it initiates a MN-HA key Update, puts the new key in
the queue, and bumps out the oldest assigned MN-HA key (Note: the queue
could likely be much larger! - holding dozens of MN-HA keys for dozens of
HAs). 
The generic Perkins/Calhoun approach or my MN-HA key queuing approach
appears equally scalable, but more efficient than automatically generating a
new MN-HA key during each new MIP session. 
The entropy issue in your proposal is not significant where the secret key
and randomness used to generate a subordinate key is large enough. The
Perkins/Calhoun proposal defines the "Key Material" to be at least 64-bits
which is large enough. A larger random variable may be more secure, but
64-bits is more than enough to ensure MN-HA key freshness. The purpose of
using randomness for key agreement is to ensure that derived key is unique.
The security of the key agreement algorithm is based on the properties of
the algorithm (i.e. one-wayness) and the size (security strength) of the
root secret key. 
Finally - I arrive at the security issues associated with using the FAC to
generate the MN-HA key. There is always a danger in using a
procedure/protocol that was originally intended for one purpose for another.
If you use the FAC only to generate the MN-FA key or some other local
key(s), I have no objection to such an approach because those keys provide
security for the visited network only. Both 3GPP and 3GPP2 use locally
generated keys for local session privacy and authentication (IK and CK for
3GPP is generated in the UIM). The home network doesn't care (to a certain
degree) whether the roamer/visitor uses proper security procedures, because
the home network always gets payed for the access (fraudulent or not based
on the Roaming Agreement between the home and visited service provider).
However, the home network provider is very concerned about giving away
possible authentication information to visited network which could cost the
home network. 
In your proposal, the MN-HA key == HMAC-MD5 (MN-AAA key, FAC, MN NAI, MN-AAA
key). The only variable is the FAC which is control by the FA! You appear to
rely heavily on the fact that the MN will use a timestamp in the RRQ to
eventually protect the MN-HA key Update. Where does the MN get system time
from? In cdma2000, the MN may us the broadcast network time (with or without
NTP) which implies that a Rogue FA, impersonating the network, can also
manipulate the MNs own timestamp and trick the MN into pre-computing RRQs
for the future. If the Rogue FA can predict the FAC used by a legitimate FA
(i.e. the legitimate FA updates FAC infrequently), then the rogue FA can act
as a clone MN and obtain access to the target network in the future. This
attack won't work against the Perkins/Calhoun proposal unless the Rogue FA
can predict the randomness used in the "Key Material" which is impractical
(however the MN-HA key would have to be updated to prevent it). The attack
is relatively sophisticated, but perhaps government X wants to monitor
packets sent to a citizen (or official) of government Y. Government X would
only need to trick the MN into precomputing RRQs (it wouldn't care about
cloning) in order to re-route packet traffic to the its own FA in the
future. 
I admit that the above attack requires the MN to generate timestamps based
on the 3GPP2(cdma2000) network system time and/or NTP(spoofed by a
fraudulent FA).  Also in the cloning scenario, the fraudulent FA would have
to predict the legitimate FA's FAC. However, my concern is that these are
only an initial potential attacks based on analyzing your proposal for less
than one day. 
It is not good security practice to allow a third party to manipulate the SA
between two entities unless that third party can be completely trusted.
In Appendix B you define MN-FA key generation - the current proposal
specifies that the MN-FA == HMAC-MD5 (MN-HA key, FA IP address, FAC, NAI).
Because the MN-FA is now dependent on the MN-HA key, it appears that a new
MN-HA key must be generated for each MIP session (as you call it) in order
to update the MN-FA key. Doesn't this defeat the purpose of the MN-HA
Optional Lifetime feature? Can the FAC used to generate the MN-FA and MN-HA
key be different ? 
Let me know what you think. 
regards, 
chris 

**********************************************************************
Christopher Carroll                                Office: 508-330-3401
Senior Member Technical Staff                  fax: 508-330-3403
Verizon Wireless                               cellular: 781-424-4131
Chair TR-45 Adhoc Authentication Group
email:  [email-masked]
**********************************************************************

---

From: "Chae-yong Chong" <[email-masked]>
Date: Mon, 9 Jul 2001 15:59:53 +0900

Hi Carroll.
Plaes read my comments bellow

----- Original Message ----- 
From: "Carroll, Christopher X" <[email-masked]>
To: <[email-masked]>
Cc: "Flynn, Gerry J" <[email-masked]>
Sent: Saturday, July 07, 2001 3:46 AM
Subject: RE: [mobile-ip] Mobile IPv4 Authentication Internt Draft revision 0.1

> concede that it is less secure than allowing the home network to control the

Okay, we consider using the other factor in calculating MN-HA share key not 
FAC itself. If we use MN-AAA authenticator instead of FAC that cause the same
problem which you mentioned? FAC is definitely under the control of FA, but
MN-AAA authenticator is not directly. How about this scheme?

> new HA is assigned to the MN. 

If the MN-HA key is updated just once every month or year, what is difference of
static MN-HA key. Its long using the MN-HA key might cause entropy problem. 

> could likely be much larger! - holding dozens of MN-HA keys for dozens of

If it is feasible, how about using just dozens of static MN-HA share key for every
HA. Do you think one home network got the thousand of HA? I don't think so.
Just use 10 static MN-HA shared secret and each shared secret is assigned 
to the last digit of HA's IP address. How about use this schem? Maybe this
scheme is lack of key update. But if you consider the same MN-HA key for one
month or even one year, what is difference between static and monthly or yearly
update

> possible authentication information to visited network which could cost the

I think that roaming agreement might consider some sort of security issues. 
If you consider, 3GPP or 3GPP2 it means commercial service. Its roaming
agreement is critical to their business. I think FA's random FAC generationg 
capability is must stated in the roaming agreement. In this case we would not
worry about the malicious FA. 

> cloning) in order to re-route packet traffic to the its own FA in the

Again We will revise our draft to use some portion of MN-AAA authenticator
not the FAC itself. 

> only an initial potential attacks based on analyzing your proposal for less

I think you confuse the MN and TE time. Mobile Node concerns only about
the MN's time. It's time will be based only MN's local timer such as PC bios. There is
no requirement for MN to adjust its time on the base of time server. Morever in my understand,
TE just adjust its time via the air signalling message. It can not spoof by the malicious
FA.

> Optional Lifetime feature? Can the FAC used to generate the MN-FA and MN-HA

Again, Pat/Calloun's method also based on the MN-AAA authentication that could
be hacked by a mallicious FA. If some malicous FA could crack the MN-HA shared
key with a specific FAC, it also do for MN-AAA shared secret. If MN-AAA authenticaiton
is cracked, it's over. That means why you always comment about the MN-HA shared
key generation not the hacking MN-AAA shared secret.

> Let me know what you think. 

Regards,
chae-yong

---

From: Pat Calhoun <[email-masked]>
Date: Tue, 10 Jul 2001 09:04:14 -0700

> static MN-HA key. Its long using the MN-HA key might cause entropy problem. 

the cost of updating the master key on the mobile, and the ability for
dynamic home agent assignment.

> month or even one year, what is difference between static and monthly or yearly

right but static MN-HA keys do not allow for dynamic HA assignment.

> worry about the malicious FA. 

right, but in the IETF we cannot assume the security assumptions that 3GPP(2)
make. We have to assume an open network.

> key generation not the hacking MN-AAA shared secret.

I personally think that anything can be hacked, given enough time and
resources. The key here is to use an MN-AAA key that is sufficiently 
strong.

Let's look at the flip side, where an unprotected agent advertisement is
sent by a malicious mobile on a network, advertising itself as a Foreign
Agent, and sending bogus FACs, and the sequence number set to zero (0).
This would cause the mobile to update is key.... not the intended effect.

PatC