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

From: "Carroll, Christopher X" <[email-masked]>
Date: Mon, 2 Jul 2001 14:47:44 -0400

Hi JH SONG and CY Chong,

I guess the main question between us is "What is the SA between the MN and
AAAh?"

From my perspective, the MN-AAA key (and associated policy info such as
algorithms to be used, life timers, etc...) is effectively the SA between
the MN and AAAh.  However, in your proposal, a new level is added to the MIP
cryptographic key hierarchy:  Master/Initial MN-AAA key - session MN-AAA key
- MN-HA and MN-FA key.  I recommend that you clearly define the
Master/Initial MN-AAA key within your proposal (and clearly define the
subordinate session MN-AAA key).

My confusion regarding your MN-AAA key generation is based on the following
sections in your proposal:

In section 1, you state "based on the assumption that the SA between the
Mobile Node and Home AAA is strong, it is possible to use that SA to create
SAs between the MN and its HA.  This document specifies the method to
dynamically update the shared secret used for MN-AAA extension and create
shared secret used for MN-HA extension..."  The inference appears to be that
"SA" is equivalent to "shared secret"  which implies that the MN-AAA key is
the MN-AAA SA.

According to Section 6 of your proposal, you state "Since the MN-AAA shared
secret is dynamically updated for every MIP registration AFTER IT ASSIGNED
FIRST TIME, therefore the risk of exposing the MN-AAA shared secret is
minimal."  This implies that the Initial MN-AAA key is modified.

In Appendix A, you state "the MS shall update its pre-assigned MN-AAA shared
secret by ...."  This implies that the Initial MN-AAA key is modified. 

I recommend that you clarify these sections to reflect your intent to
maintain a static root Secret/SA between the MN and AAAh.

Let me address the merits of your proposal (as I currently understand it):

My primary question is "What is the value of an additional level in the MIP
cryptographic key hierarchy?"  If a session MN-AAA key is generated, based
on a Master MN-AAA key, is the system security improved?  Possibly, but is
it necessary.  I suppose that an attacker doesn't have the opportunity to
observe the challenge/response based on the Master MN-AAA key which prevents
a possible cryptanalysis.  However, a large key (e.g. 128 bits) should
provide adequate security.

Your Master MN-AAA key proposal is also similar to TR-45 authentication in
which a secondary key, Shared Secret Data A (SSD-A), is derived from the
root A-key.  SSD-A, not the A-key, is used to calculate the authentication
response.  However, SSD-A is used to enable more efficient roaming
authentication between the home and visited network.  SSD-A is considered a
temporary (semi-permanent) key that is sent to a visited network to enable
Mobile Station (MS) authentication while the MS uses the visited network.
SSD-A can be used to calculate multiple authentication responses.  When the
MS leaves the visited network, the home system can then Update SSD to a new
value.  The advantage of SSD-A is that network access authentication
requests do not continuously have to be routed back to the home system
(expensive in SS7 networks), i.e. they are calculated in the visited
network, while the root A-key is not revealed to the visited network.  GSM
networks use crypto-triplets to enable visited network authentication
without revealing the root GSM key.  If you were proposing a method of
enabling Local/Visited network MIP authentication (in which the
authentication calculation was performed locally by the FA or local AAA), I
think your session MN-AAA key proposal could have added value.

With regard to the MN-HA key, is it efficient to update the MN-HA key during
every Registration?  If the AAAh must send a new MN-HA key to the HA during
each registration, why not send the whole Registration Request via the AAAh
(and skip sending it via the FA-HA link)?  From my perspective, updating the
MN-HA key per registration adds no significant security enhancement as long
as the MN-HA key is long enough (e.g. 128 bits).  However, it is valuable to
have a method of initially loading or deriving the MN-HA key (via Key
Agreement) and also updating the MN-HA key if compromised.  The
Perkins/Calhoun proposal allows the service provider to decide when to
derive/update MN-HA key which appears more efficient.

With regard to your concern that draft-ietf-mobileip-aaa-keys-06 will only
apply to Diameter, I agree with your concern and will likely propose that
the Perkins/Calhoun procedure be added to the 3GPP2 version of Radius AAA in
the next revision of IS-835 (3GPP2 Packet Data/Mobile IP).

In conclusion, I recommend the following:

1) You should expressly define and distinguish Master/Initial MN-AAA key and
session MN-AAA key in your proposal.

2) I would prefer stronger justification of the need for creating an
additional level in the MIP cryptographic key hierarchy.        

Let me know what you think?

regards,

chris

-----Original Message-----
From: junhyuk song [mailto:[email-masked]]
Sent: Friday, June 29, 2001 2:11 AM
To: [email-masked]
Subject: Re: [mobile-ip] Comments on
draft-song-mobile-ipv4-auth-secgeneration-00.txt

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

 > 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).
 
 I agree.

 > 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).  
 
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.
 
> 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?
 
 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
 
> 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.
 
 I agree MN-FA is not practical at all.
 
> 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).  
 
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. )

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

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

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

> 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]
> **********************************************************************
>