Subject: RE: [mobile-ip] Concerns/comments for aaa-keys and gen-key

From: George Tsirtsis <[email-masked]>
Date: Mon, 1 Oct 2001 11:56:41 -0400

-----Original Message-----
From: Pat Calhoun [mailto:[email-masked]]
Sent: Sunday, September 30, 2001 3:39 PM
To: Michael Thomas
Cc: [email-masked]; Charles E. Perkins; Erik Nordmark;
Pat Calhoun
Subject: Re: [mobile-ip] Concerns/comments for aaa-keys and gen-key

...

> Is there a way
>    to get the AAA to supply fresh key material on demand?
>    If so, is the performance penalty going to be acceptible?
>    If not, is the expectation that one or both of the
>    ends of the SA supply entropy? If it's only one side,
>    what happens if their random number generator is not
>    very good, like oh say open("/dev/null")?

Unfortunately, MIP doesn't have the ability for an unsolicited MIP message
to be sent to the mobile. So, using today's protocol, the answer is no.

GT> I have a different concern with a possible solution that may solve this
problem. 
We are implementing challenge/response with MN-AAA extensions and Radius as
AAA. As a Mobile Node (MN) comes in contact with a new FA, it receives an
Foreign Agent Advertisement (FAA) with a Challenge to which it responds with
a MIP Registration Request (RREQ) that includes MN-AAA authenticator. The FA
gets key material from AAA server and returns it to the Mobile Node (MN)
with the registration reply (RREP) so that an MN-FA key can be constructed.
The link layer happens to provide link up/link down triggers so that if the
MN looses contact with the FA we know it immediately. If the MN regains
contact in a short time, the FA senses it also immediately. 

->The problem with a standards based MIP client would be that on
reconnection and although the MN receives an FAA with a challenge, the
advertised FA is recoginsed as one that the MN has already registered with
and does not bother to register again thus, one can not check its MN-FA key
and verify the user is still the same.

No matter what the particular scenario is, however, I think this does not
make sense for any challenge/response protocol. The behaviour should be that
if you get a challenge you MUST respond to it. So, the proposed solution is:

"If a Mobile Node receives a *unicast* FAA WITH a Challenge then it MUST
send a Registration Request with an appropriate Response or face loss of
connectivity". Note that this does not mandate that all FAAs must now be
unicasted...but it does allow a network administrator to target a specific
mobile, challenge it individually and get its credetials.
On top of that, the above proposal would also make re-keying possible since
the FA can insert new Key material in the Registration Reply.

Thoughts?

George

---

From: Pat Calhoun <[email-masked]>
Date: Tue, 2 Oct 2001 07:37:31 -0700

> the FA can insert new Key material in the Registration Reply.

To address both your issues:

1. RFC 3012 is pretty clear that the MN MUST include the challenge response if the
   challenge was present in an advertisement. No way around this one, so I don't
   think there is an issue (unless I misinterpreted your comment).

2. If the FA inserts new key material in the registration reply, it must also
   add the necessary authentication extension, which must match the key generated
   by the MN via the included key material. Furthermore, the HA must also add the
   necessary MN-HA key material (which it receives from the AAAH) as well as the
   MN-HA authentication extension.

Hope this helps,

PatC