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

From: "junhyuk song" <[email-masked]>
Date: Wed, 27 Jun 2001 13:26:55 +0900

Hi All,

We recently submitted a draft on "MIPv4 Authentication Shared Secret Generation (draft-song-mobileip-mipv4-auth-secgeneration-00.txt)  

Regards,
JH SONG

---

From: Pat Calhoun <[email-masked]>
Date: Wed, 27 Jun 2001 06:54:47 -0700

Authors,

I am trying to understand this draft, and have a couple of questions.

As you know, draft-ietf-mobileip-aaa-keys-06.txt, which has already been through WG
last call and is about to be published as an RFC, describes a similar mechanism
to what is proposed in the above mentioned draft. They key difference, from what I
can tell, is that the nodes in question generate keys based on the FA challenge,
instead of having the AAA infrastructure generate the keying material.

Is this the only difference?

The issue I have with this scheme is that the FA challenge is local to the
foreign domain, and does not necessarily have any entropy. So, a malicious
foreign agent could simply advertise a static challenge, and the mobile's
keys would be created using the static challenge value. This issue here is
that it exposes long term material to the foreign agent (and its administrators)
which could be useful in key discovery attacks. The advantage with the
AAAH creating the session keys, as described in draft-ietf-mobileip-aaa-keys-06.txt
is that the long term keys are never exposed, and since only short term key
material is sent to the foreign agent, security exposure is minimized.

My 2 cents,

PatC

---

From: "junhyuk song" <[email-masked]>
Date: Thu, 28 Jun 2001 10:26:21 +0900

Hi Pat!

I finally caught  your attention.
Read my comment below.

----- Original Message ----- 
From: "Pat Calhoun" <[email-masked]>
To: <[email-masked]>
Sent: Wednesday, June 27, 2001 10:54 PM
Subject: [mobile-ip] Comments on draft-song-mobile-ipv4-auth-secgeneration-00.txt

> Is this the only difference?

That is the one of the key difference, your proposal requires new Mobile IP extension while our proposal doesn't.
Besides,  this document propose to dynamically update MN-AAA shared seceret based on FAC.   MN-HA shared secreet is created based on newly generated MN-AAA shared key.

> material is sent to the foreign agent, security exposure is minimized.

I don't understand what do you mean by that?
FA is vouched by veirification infrastructure (AAA) right?

Now, let's say there is what you called malicious foregin agent.
I still don't see how to derive the long term material used for making MN-HA by sending static FAC.
Even FA somehow compromises MN-AAA shared key used in creating MN-HA shared key, 
its initial MN-AAA shared key is secure. 
Because MN-HA shared secret is made of newly created MN-AAA shared key (New long term key) with FAC, and MN NAI.  Not initial MN-AAA shared key. 

PS.  In RFC-3012, it is not clear whether Foreign Agent includes MN-AAA extension to the RRQ and relay to HA after MN-AAA authentication by verification infrastructure. Can you calarify that?

---

From: "Chae-yong Chong\(정재영\)" <[email-masked]>
Date: Thu, 28 Jun 2001 10:58:24 +0900

Hi Pat,

Read my comments.

----- Original Message ----- 
From: "Pat Calhoun" <[email-masked]>
To: <[email-masked]>
Sent: Wednesday, June 27, 2001 10:54 PM
Subject: [mobile-ip] Comments on draft-song-mobile-ipv4-auth-secgeneration-00.txt

> Is this the only difference?

This does not introduce "NEW" extensions which require to modify Mobile Node and FA(HA too?)
If there is a way to achive enough security without adding or modifying already defined protocol,
it is desirable to use that. 

> material is sent to the foreign agent, security exposure is minimized.

You said that some FA could use the static FAC. If so, what is the
purpose of the FAC. In my understand, FAC is used to pretect replay attack. If some FA does use
static FAC all the time, it must provide some other means to protect it. Or that FA give up the 
replay attack protecting service provided by FAC extension. If so, why we should do for this FA.
Should we do another jobs to help that FA which maybe does not want to use the FAC extension's capability?