Subject: Re: [MOBILE-IP] Challenge / Response with co-located FA

From: Woo-June Kim <[email-masked]>
Date: Fri, 6 Oct 2000 23:28:08 +0900

Fredrik,

The mobile node itself just generates a random number to use as the challenge. The response can only be correctly calculated by the mobile if it knows the correct key and algorithm. The AAA is simply using this fact to check the mobile's identity in a round-about manner. The challenge value itself is not something that must be generated in some special manner. 

cheers

>BlankHi
>
>I have a question concerning how Challenge / Response is supposed to work
>when a mobile node registers using a co-located foreign agent.
>
>Since the mobile node does not receive an advertisement with a challenge
>from a FA it cannot calculate a response to be used in a MN-AAA
>Authentication extension, i.e., the Home Agent cannot use a Radius server to
>authenticate the MN.
>
>Have there been any thoughts in this area, or perhaps a solution in an
>earlier thread that I've missed? Thankful for any pointers.
>
>Regards
>/Fredrik
>-----------------------------------------
>Fredrik Johansson
>
>W: +46 (0)8 725 5916
>M: +46 (0)70 786 5035
>mailto:[email-masked]
>http://www.ipunplugged.com
>
>
>
>

---

From: Fredrik Johansson <[email-masked]>
Date: Wed, 11 Oct 2000 08:30:18 +0300

Hi,

the mobile node generates the challenge and send the request to the home
agent. The home agent will then include the same challenge in the
registration reply, is it up to the implementation of the co-located foreign
agent to remove the challenge before giving it to the mobile client so it is
not misstaken for a new challenge that can be sent in the registration reply
for use in the next registration?

/Fredrik

> -----Original Message-----
> From: IP Routing for Wireless/Mobile Hosts (mobile-ip)
> [mailto:[email-masked]]On Behalf Of Woo-June Kim
> Sent: den 6 oktober 2000 17:28
> To: [email-masked]
> Subject: Re: [MOBILE-IP] Challenge / Response with co-located FA
>
>
> Fredrik,
>
> The mobile node itself just generates a random number to use as
> the challenge. The response can only be correctly calculated by
> the mobile if it knows the correct key and algorithm. The AAA is
> simply using this fact to check the mobile's identity in a
> round-about manner. The challenge value itself is not something
> that must be generated in some special manner.
>
> cheers
>
> >BlankHi
> >

---

From: "[email-masked]" <[email-masked]>
Date: Wed, 11 Oct 2000 06:39:45 -0700

Well, perhaps I am missing something here, but I really don't see the need for
challenge/response support in a co-located MN. The challenge is useful to FAs
to provide replay protection. Since MNs already have a replay protection
scheme with the Home Agent, the challenge doesn't provide anything additional.

PatC

---

From: Fredrik Johansson <[email-masked]>
Date: Wed, 11 Oct 2000 16:01:59 +0300

Hi Pat,

It was not to provide replay protection but to enable the home agent to
authenticate the user towards a Radius server using CHAP. In the radius
request a challenge and  a response is needed. Using the MN-HA
Authentication extension does not provide a challenge.

Or is there another way of doing this?

/Fredrik

> From: [email-masked] [mailto:[email-masked]]
> Sent: den 11 oktober 2000 16:40
> To: Fredrik Johansson
> Cc: [email-masked]

---

From: "[email-masked]" <[email-masked]>
Date: Wed, 11 Oct 2000 07:02:25 -0700

Ahh... sorry. I thought your question was in regards to the challenge
extension, and not the MN-AAA authentication extension.

In any case, for the latter, it does require that the former be present, and
the mobile can generate its own challenge (hmmmm.... quite insecure, isn't
it). I am also tempted to say that the Home Agent should return an new error
code with a challenge value, and force the Mobile Node to re-register.

Unfortunately, the soon to be RFC doesn't discuss co-location.

PatC

---

From: Charlie Perkins <[email-masked]>
Date: Wed, 11 Oct 2000 19:22:37 -0700

Hello,

The statement has been made that the Registration Request does
not contain a challenge.  This isn't correct.  The "Identification" field
of the Registration Request message serves exactly the function
of a challenge, from the standpoint of the home agent.  I reckon it
would be fairly easy to establish a security association between the
mobile node and the home agent that would enable RADIUS to
be used by the home agent, but there are details that would have
to be worked out.

Regards,
Charlie P.

---

From: Fredrik Johansson <[email-masked]>
Date: Thu, 12 Oct 2000 09:15:12 +0300

Thanks Pat,

That is exactly my opinion. My first intuition was that it is not secure for
the mobile node to create its own challenge. It will open up for DoS attacks
against the radius server since the home agent will not reject any
registration request but will try to authenticate them all towards the
radius server.

We've been thinking about the solution where the home agent rejects the
first request.

If the mobile node try to register to the home agent without the challenge
extension. The home agent will return a registration reply with the error
code "missing challenge", and includes a challenge in the reply. The mobile
node will try to register again now including the received challenge. The
home agent MUST check that the received challenge is the same as the one
sent in the previous reply to this mobile node. When the home agent has
authenticated the mobile node, it sends a registration reply with a new
challenge that the mobile node MUST use in the next periodic registration.

If a registration reply gets lost on its way to the mobile node, the mobile
node will try again with the same challenge and now the home agent will
reject the request with the error code "stale challenge". And return a new
challenge in the reply, thus causing the mobile node to try again.

This requires some changes in how the home agent handles registration
request. First if the home agent is configured to authenticate its users
towards a radius server it has to return a new challenge in the reply. It
MUST also keep a copy of the last challenge sent to the mobile node so it
can compare it against the one recieved in the next registration reply. The
implementation of the co-located foreign agent has to inteprete the recieved
challenge as a new one instead of an old one as menitioned earlier in this
thread.

Open issues:
* how will the home agent know if it is a co-located foreign agent or an
regular foreign agent it is dealing with, i.e. how will it know when it
should return the old challenge to the foreign agent or a new challenge to
the co-located foreign agent?

Pros & Cons:
* Challenge response is available for a mobile node regisering as a
co-located foreign agent which will enable radius authentication.

* The first registration will need 2 RTT.

I'm not that familiar with the procedures when a draft becomes an RFC, but
if there is time, I believe something should be mentioned in the draft about
how it will work with a co-located foreign agent.

/Fredrik

> From: [email-masked] [mailto:[email-masked]]
> Sent: den 11 oktober 2000 17:02
> To: Fredrik Johansson
> Cc: [email-masked]; [email-masked]
> Subject: RE: [MOBILE-IP] Challenge / Response with co-located FA
>
>

---

From: Fredrik Johansson <[email-masked]>
Date: Thu, 12 Oct 2000 09:55:03 +0300

Hi Charlie

That is true that the "Identification" field contains a challenge, but that
is from the mobile node towards the home agent. What we're looking for is
the oposite direction, from the home agent to the mobile node.

In order to authenticate the user towards a Radius server using CHAP, a
challenge and a reponse is needed. Thus we need something like the MN-AAA
Authentication extension.

By doing the authentication with a Radius server, the mobile node will only
need to keep one shared secret between the mobile node and ANY home agent on
the home network, since when authenticated with the Radius server, the home
agent will retrieve the subscriber data for that mobile node. This will make
home agent discovery easier since a new home agent can be deployed on the
home network without having to configure the mobile node with yet another
shared key.

Regards
/Fredrik

> From: Charlie Perkins [mailto:[email-masked]]
> Sent: den 12 oktober 2000 05:23
> To: Fredrik Johansson

---

From: "[email-masked]" <[email-masked]>
Date: Thu, 12 Oct 2000 07:33:01 -0700

> home network without having to configure the mobile node with yet another
Just out of curiosity, is there really a demand to do home agent allocation
using RADIUS? I know of no such activity... Would it not instead make more
sense to make use of RADIUS?

If the Mobile Node has no SA with the HA, how will the MN-HA authentication
extension be computed/generated?

PatC

PatC

---

From: Fredrik Johansson <[email-masked]>
Date: Thu, 12 Oct 2000 16:45:50 +0300

See comments below...

> [mailto:[email-masked]]On Behalf Of
> [email-masked]
> Sent: den 12 oktober 2000 17:33

You're not using radius for home agent allocation, you use the regular home
agent discovery mechanism, but the choosen home agent will receive the MN-HA
key from the radius server. The mobile node will have the same secret will
all the home agents within its home network. But don't pay to much attention
to this, it was just an example where it can be used.

what I'm intrested in is to be able to authenticate the client using RADIUS,
i.e. there is a need for a challenge / response mechanism when using
co-located foreign agent as well as when using a regular foreign agent.

Rgds
/Fredrik

---

From: "Charles E. Perkins" <[email-masked]>
Date: Thu, 12 Oct 2000 08:21:58 -0700

> the oposite direction, from the home agent to the mobile node.

This is done as follows:

When the home agent sends a Registration Reply to the mobile node,
that Registration Reply also has an Identification field.  That
field can have bits that the mobile node is required to return in
the Identification field of the next Registration Request.
Those bits would be the challenge you desire.

> Authentication extension.

You need MN-AAA authentication extension if you are asking AAA to
authorize the registration instead of the HA.  I don't think there
is any direct relationship between "challenge" and "MN-AAA".  If you
would like to arrange things so that the AAA supplies the bits to
be inserted into the Identification field of the Registration Reply,
I think that should work fine.  It doesn't have to be standardized
by the mobile-ip working group, but it might be a matter of interest
to the aaa-wg.

Regards,
Charlie P.

> > Woo-June Kim

---

From: Fredrik Johansson <[email-masked]>
Date: Fri, 13 Oct 2000 16:30:34 +0300

> From: [email-masked] [mailto:[email-masked]]
> Sent: den 12 oktober 2000 18:22
> To: Fredrik Johansson

I don't agree, if you're using timestamps, the mobile node will set its time
in the low-order 32 bits and a random number in the high-order 32 bits. The
home agent will return the 64 bits as is if the request is within the
timeframe or it will return the low-order 32 bits from the request and its
own time in the high-order 32 bits if outside the timeframe. If rejected the
mobile node will adjust its time and send a new request with it new time in
the low-order 32 bits and a new random number in the high-order 32 bits.

If the home agent can act as follows, the challenge extension is not needed
when registered as co-located foreign agent:
1. When a challenge extension is present in the request, it will use it as
the challenge to use toghether with the MN-AAA authentication extension.
I.e. the registration is via a foreign agent.

2. If no challenge extension is present, the home agent will use the high
order 32 bits from the identification field as challenge toghether with the
MN-AAA authentication extension. Thus the mobile node will create its own
challenge.

The important thing is that both nodes know which field to use as a
challenge when trying to verify the authenticity of the user. The mobile
node is the only one that can know if it is registered as a co-located
foreign agent or not.
> by the mobile-ip working group, but it might be a matter of interest

I don't know, I believe there is a relation since ? 6 in the
challenge/response draft states "If the mobile node does not include a
Mobile-Foreign Authentication [8] extension, then it MUST include the MN-AAA
Authentication extension whenever the Challenge extension is present,"

But that is no problem if the home agent treats the request according to the
suggestion above.

Regards
/Fredrik