Subject: [mobile-ip] Re-registration after unicast Challenge and re-keying (was:RE: [m obile-ip] Concerns/comments for aaa-keys and gen-key)

From: George Tsirtsis <[email-masked]>
Date: Wed, 3 Oct 2001 06:00:41 -0400

New subject since this is slightly different thread...

Pat, please see below

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

On Mon, Oct 01, 2001 at 11:56:41AM -0400, George Tsirtsis wrote:
> 
> -----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.

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

GT> Pat, unfortunately this is not exactly the case...I quote RFC3012:
"  Whenever the Agent Advertisement contains the Challenge extension, if
   the mobile node does not have a security association with the Foreign
   Agent, then it MUST include the Challenge value in a MN-FA Challenge
   extension to the Registration Request message.  If, on the other
   hand, the mobile node does have a security association with the
   foreign agent, it SHOULD include the Challenge value in its
   Registration Request message...."

The above says that a challenge response MUST be included in the
registration request if one is sent (and only if MN-FA keys does not
exist...otherwise it is a SHOULD). The spec does not say anywere that the
mobile node MUST register if it receives an foreign agent advertisement with
a challenge, which actually makes sense if the FAAs are broadcasted
periodically...In fact I am afraid that if the MN has registered in the past
and already has a MN-FA key...it will not register again unless either its
registration lifetime expires or it changes FA. So, still the FA can not
challenge the MN as it wishes even if it sends a unicast FAA+Challenge to
it. Do you see the problem?

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.

GT> Yes, and that is why I am arguing that the process must be possible to
be initiated by the FA (i.e.: the network operator). FA sends new challenge
(maybe with a flag indicating that MN-AAA authenticator should be used
instead of the MN-FA one)...If we can make the MN re-register at this stage
re-keying will happen naturally and according to existing mechanisms.

If what I am suggesting is not clear let me know and I will put a couple of
message flows down.

Regards
George