Subject: Re: [mobile-ip] Comments on draft-song-mobile-ipv4-auth-secgenera tion-00.txt

From: "Carroll, Christopher X" <[email-masked]>
Date: Thu, 28 Jun 2001 13:18:38 -0400

Hi Junhyuk, Dongkie, Chae Yong, and Raymond,

I have the following comments regarding your draft MIPv4 key generation
proposal:

Your proposal utilizes a Key Agreement protocol which is similar to the
methods used in TIA TR-45 and GSM cellular telephone networks to create
SESSION keys for privacy and authentication.  Also, Bootstrapping the root
key (MN-AAA key, A-key, or GSM K key) is a difficult problem, i.e.,
distributing secret keys to millions of handsets must be done securely and
efficiently.  GSM / 3GPP distributes keys via SIMs (smart cards), while TIA
TR-45 / 3GPP2 primarily utilizes manufacturer pre-load and an out-of-band
distribution network to populate the network's HLR/AC (equivalent to AAA).

However, in those networks, the root key (A-key or GSM K key) is never
updated/modified by the visited network.  The root keys for these networks
are jealously guarded by the Home Service provider.  I suspect the MIPv4
service providers will want to protect the MN-AAA and MN-HA keys to the same
degree.  Unfortunately, your proposal enables a potentially devastating
Denial-of-Service attack in which a Rogue FA creates a mis-synchronization
of the MN-AAA and MN-HA keys between the MN and home network (AAA and HA).
Even if every FA acts properly, a hacker can create his own FA that
continuously initiates MN-AAA and MN-HA key updates with any MN within it's
vacinity.  One device, strategically placed at an airport or in the center
of a city, could change the root keys in thousands of MNs.  How will the
service provider re-syncronize the MN-AAA or MN-HA key?  Perhaps by the
expensive process of manually re-loading the keys or distributing new smart
cards.  Perhaps the user could log onto a protected (SSL) website and
download new keys (if they're allowed access).  

Your proposed MN-AAA key chaining is inherently susceptable to
synchronization problems between the MN and AAA.  Even the 3GPP AKA protocol
has elaborate procedures for re-synchronization of sequence numbers.  How do
you propose to re-synchronize MN-AAA keys when there's a mismatch?  How
would the network know whether a fraudulent access attempt or MN-AAA key
mismatch occurred?

One possible solution to this problem could be to use a Mutual
Authentication scheme between the MN and FA (or between the MN and AAA) to
ensure that the MN only updates these keys with a valid FA - however, this
may be impractical because the MN and FA must share a common secret in the
first place (Chicken-before-the-egg problem).  Let's not talk about Public
key because MNs may not have the processing power to use Certificates and
service providers may not have the expertise to deal with PKI.

The MN-AAAh key appears to be the root key for MIPv4 in which a
Radius/Diameter AAA server is used.  It appears that the MN-AAAh key is
intended to be a subscription lifetime key (like the A-key and K in
TR-45/3GPP2 and GSM/3GPP networks).  It is dangerous to allow a visited
system  to update such a key during the subscription lifetime - such a
procedure should be initiate and controlled by the home system (AAAh).
(Note: your root key update procedure doesn't even enable secure recovery if
the MN-AAA key data base were compromised because the hacker/criminal will
only need to intercept the FAC to generate the new MN-AAA key).  

The MN-HA key may not be a subscription lifetime key, but it could be.
However, MN-HA key generation can be efficiently performed based on the
MN-AAA key which implies that AAAh must be involved in the process.  Your
Dynamic / session generation of the MN-HA key appears inefficient from a
key management perspective because the AAAh must generate and distribute a
new MN-HA key for every system access.  In the draft Perkins/Calhoun 06
proposal, a new MN-HA key is generated only when necessary.  Thus, even when
dynamic HA assignment occurs, the AAAh generates and distributes the new
MN-HA key for the new HA.  It also issues the MN-HA key update to the MN.
It appears that the draft 06 proposal could allow the AAAh (and MN) to
manage the MN-HA keys for multiple HA simultaneously.  The MN simply needs a
queue in which to store the different MN-HA keys or the AAAh could update
one MN-HA key during each dynamic HA assignment.  From my perspective the
current Perkins/Calhoun proposal reduces the amount of MN-HA key generation
and distribution while maintaining the proper security.

It is likely most efficient to generate the MN-FA key as a session key
because the MN may interact with countless FAs (impractical for MN to store
MN-FA key for all FAs).  In fact, I proposed a similar procedure to the
3GPP2 TSG-P Subcommittee several months ago.  However, dynamic generation of
the MN-FA key based on the FAC may not be significantly more efficeint than
having the MN-FA generated based on randomness provided by the AAAh.

I have a cryptographic concern with your method of generating a new MN-AAA
key based on the previous MN-AAA key.  This key generation chaining may be
vulnerable to some type of cryptanalysis.

In general, your proposed key generation scheme appears unacceptable because
it may expose MIPv4 networks to a devastating Denial-of-Service attack.
Like many security schemes that rely on synchronization, your key generation
scheme appears too unstable to be reliable.  However, I do beleive that your
MN-FA key generation proposal has some merit.

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: "junhyuk song" <[email-masked]>
Date: Fri, 29 Jun 2001 15:11:25 +0900

Hi Chris,
 
Thank you for giving us very long insightful comments, it took me a couple of hours to read it through.
I agree with you some of your comments.  
Actually I myself believe distributing key by IKE like "key material" mechanism of draft-ietf-mobileip-aaa-keys-06.txt  is the best security solution.
Because in the security point of view, it gives master authority to AAA, and MN and any other entity, doesn't really have to care about KEY stuff.

What we prpoposed is the interim solution, before we are eventually able to use such new Mobile IP extensions and DIAMETER.
We will make necessary changes to our upcoming revision.

So meanwhile, please read my comment below.

 ----- Original Message ----- 
 From: "Carroll, Christopher X" <[email-masked]>
 To: <[email-masked]>
 Cc: "Flynn, Gerry J" <[email-masked]>
 Sent: Friday, June 29, 2001 2:18 AM
 Subject: Re: [mobile-ip] Comments on draft-song-mobile-ipv4-auth-secgeneration-00.txt

> distribution network to populate the network's HLR/AC (equivalent to AAA).
 
 I agree.

> download new keys (if they're allowed access).  
 
The master MN-AAA shared key never change in our Internet Draft.
Only the session MN-AAA shared key is dynamically generated based on FAC.
 
Speaking of DOS attack, are you implying that FA could do the DoS attack to HA with junk MN-AAA or MN-HA key?
I believe it is the native problem that exist unless enforcing FA-HA securecy.  In your example you mentioned that someone could change the root MN-AAA key in the airport, We DO NOT CHANGE initial MN-AAA key. We just update the it with new one. We always refer the intial MN-AAA key to create new one. Only each MN and each HA just remember the new key, it should always store the initial key. If someone failed to sync with AAA, the others could still have their MN-AAA key. All MN-AAA keys could be different. The Initial MN-AAA key is still intact.
 
> would the network know whether a fraudulent access attempt or MN-AAA key
 
 There is no synchronization problems between MN and AAA, 
 because AAA alway create the session MN-AAA shared key based on Master MN-AAA shared key and FAC
 
> service providers may not have the expertise to deal with PKI.
 
 I agree MN-FA is not practical at all.
 
> only need to intercept the FAC to generate the new MN-AAA key).  
 
First 3GPP2 does not enforce any life time for MN-AAA key what so ever.
And once again, the master MN-AAAH key never updated, it only used for creating session MN-AAA key.

(Note:  Hacker will not be able to compromise session MN-AAA key by FAC.
This is simply because our solution has the same security assumption of MN-AAA authentication.  In other words, even if Hacker intercept FAC to derive MN-HA shared key or even MN-AAA shared key, it costs the same amount of money and time to compromise MN-AAA shared key used in MN-AAA athenticator.   If so it can be compromised anyway, it is same to MN-AAA authentication. )

> and distribution while maintaining the proper security.
 
 Speaking of key lifetime and key management perspective, we are working on the next revision.  Our new revision has better Key management than current Internet Draft.  In a nutshell, MN and AAAH has pre-fixed MN-HA shared key life time, and the lifetime will be sent with MN-HA shared key to HA by AAA message.  So, when MN generates MN-HA shared key, MN will timestamp it.  That timesamp is the same timestamp used to RRQ Identification. HA and AAA can derive the life time of MN-HA out of timestamp and the pre-fixed lifetime from AAA message.
Key life time and key management perspective, we are working on the next revision.

Well, I thought we are talking about our Internet Draft, but since you keep specifically refering to other Internet Draft.  Let me compare our darft and draft-ietf-mobileip-aaa-keys-06.txt.  Our solution works better for RADIUS based AAA in terms of DOS attack.

The problem I have for draft-ietf-mobileip-aaa-keys-06.txt is that it only may works for DIAMETER based AAA.
For example, it lets MN to send RRQ with MN-HA authenticator made "0" MN-HA shared key. 
So upon receiving of RRQ, HA must ask AAAH and fetch "Key Material" and "MN-HA shared key".
And then HA will made binding table, other necessary processing, and made RRP with MN-HA Authenticator with newly assigned MN-HA shared key.
But problem is HA does all of this work with no knowledge of whether MN is legimate or not, since it didn't perform MN-HA authentication. And it does not require or enforce FA-HA authentication.
Someone, may argue that since there is MN-HA shared key was found in AAAH, it means that it is legimate RRQ, 
 but that key may be supposed to be given to some other HA.  That means that solution is vulnerable to DoS attack too.

> having the MN-FA generated based on randomness provided by the AAAh.
 
 I agree, the randomness generated by the AAAh will be more secure, 
 but I cannot agree with you on the 3GPP2 TSG-P network case.
Becuase the FAC is 128 bit, randomness provided by PDSN.
And it depends on the Random number generator of PDSN, it is supposed to be unique in each RRQ.
RFC3012, state that if it is not unique number for the user, it will simply discard it.

> vulnerable to some type of cryptanalysis.
 
 Once again, we are not proposing to generate new MN-AAA master key, it is session MN-AAA key.
And if it can be compromised then, the MN-AAA authenticator has the same security concern.  
I think the cryptocgraphic concern about the cryptanylysis should be resolved by some other context, but it 
 is out of boundary of this document(In my undertanding, all plain-text form of AAA access request/response 
 messages are vulnerable to cryptanaysis what you refering to)
  
> MN-FA key generation proposal has some merit.
 
 I am not sure what DOS attack you are implying to.
Other internet draft has the same DOS issue in case of RADIUS based AAA.
It could be solved only by using the FA-HA authentication.
And,  Please don't say "unacceptable" you haven't seen our revision yet.

 Regards,
JH SONG, CY Chong