Subject: RE: [mobile-ip] MIPv4: MN-AAA authenticator and challenges

From: [email-masked]
Date: Wed, 7 May 2003 19:16:05 -0500

Hello Bjorn,

I am by no means a crypto expert, but here is my understanding:

I'm under the impression that the purpose of the MN-FA-challenge is for
protection against replay attacks, and by being included in the portion of
the message that is subject to the digest computation, that purpose is
fullfilled.

So why is the challenge field included in the computation of the MN-AAA
authenticator? I think the reason is for creating an authenticator that can
be verified at the other end (AAA), via a standard CHAP mechanism. Here is
why I think so:

You have a AAA server, which is off the shelf, does not know a thing about
mobile IP. It will receive an access-request, and in order for the server
to perform CHAP authentication, that request will need to present three
values: the CHAP_id, the CHAP_pwd, the CHAP_challenge. The AAA will
retrieve the secret_key, and will perform the computation:

(1)                 MD5(CHAP_id, secret_key, CHAP_challenge)

The result of that computation needs to be identical to the CHAP_pwd for
the access-request to succeed.

So things are rigged to facilitate this operation:

At the mobile, you do the following computation:

(2)      MD5(MSB(FA-chal) + Key + MD5(MipMsgAbove) + LS237B(FA-chal))

At the FA, or the HA, you do the following:

(3)           CHAP_id                     = MSB(FA-chal)
(4)           CHAP_pwd                = MN-AAA authenticator
(5)           CHAP_challenge     = MD5(MipMsgAbove) + LS237B(FA-chal)

So, now, if you go back and do the computation described in (1), with the
values from (3) and (5) along with the secret-key you retrieved from your
database, you will see that you are actually repeating exactly the same
computation as (2).

In other words, in order to do CHAP at the AAA, you need the 3 discreet
values shown in (1). That, I think, is why the FA-challenge was included in
the MN-AAA calculation. (Again, it protects against replay, but it does so
by being included in the part of the message that is subjected to the one
way hash.) Its inclusion in the MN-AAA calculation does not further the
security of the one-way-hash any more than a string of bytes chosen at
random and used in the same manner would. So why is the challenge value in
the digest computation? Because something has to be...

Thus, I think that the use of the ID field in place of a mobile-chosen
value will not be adding to the security. I could be wrong of course, but
if you disagree, please let me know how appending to the digest calculation
a  field that is sent in the clear adds any security to a one way hash
(beyond the same value gained by adding self-generated random bytes to
protect against birthday-attack prone collision problems.)?

I think Pete McCann explained all this quite clearly (and more succinctly,
I'm afraid) in an earlier e-mail...

best regards,
ali

"Jayshree Bharatia" <[email-masked]>@sunroof.eng.sun.com on
05/07/2003 05:23:15 PM

Sent by:  [email-masked]

To:   "'bjorn @iki.fi'" <[email-masked]>
cc:   "'mobile-ip @sunroof.eng.sun.com'" <[email-masked]>
Subject:  RE: [mobile-ip] MIPv4: MN-AAA authenticator and challenges

Hi Bjorn,

I see your point on using ID but I have concern regarding having two
different ways to calculate authenticator depending on whether MN has
co-located CoA or not.

Is there any security risk you see if the challenge is used arbitrarily
from
HA perspective? If this is the case, we may have to revise our decision on
supporting MN with co-located CoA.

Thanks,
Jayshree

> -----Original Message-----
> From: Bjorn Andersson [mailto:[email-masked]]
> Sent: Wednesday, May 07, 2003 4:25 PM
> To: Bharatia, Jayshree [RICH1:2H13:EXCH]
> Cc: [email-masked]
> Subject: Re: [mobile-ip] MIPv4: MN-AAA authenticator and challenges
>
>
> On Wed, May 07 2003, at 13:47:32 -0500, Jayshree Bharatia wrote:
> > I didn't see specific reason of your objection other than the fact
> > that the MN with co-located CoA won't be using challenge-response
> > protocol. Appreciate if you can further clarify on: why ID
> generated
> > by the MN is better compare to Challenge?
>
> Because the ID field _is_ a challenge by the HA; it can't be
> arbitrarily chosen.
>
>   Bjorn
>
> --
> Bjorn Andersson <[email-masked]>
> PGP id 5AFC144B
> Mobile +358 40 7723074
>

(See attached file: C.htm)

---

From: Bjorn Andersson <[email-masked]>
Date: Thu, 8 May 2003 10:11:02 +0300

> I am by no means a crypto expert, but here is my understanding:

I am no crypto expert myself. I fully agree with what you explain
below and understand that the CHAP authenticator (SPI 2) in the MN-AAA
extension is done in such a way that is compatible with how RADIUS
servers are implemented.

> database, you will see that you are actually repeating exactly the same

The point is, why do we need to append LS237B(FA-chal) in
CHAP_challenge? It would work equally well with RADIUS servers not aware
of MIP if the CHAP_challenge was only MD5(MipMsgAbove). The mobile would
thus compute "MD5(MSB(FA-chal) + Key + MD5(MipMsgAbove))". Since "MipMsgAbove" 
contains FA-chal we have fulfilled the replay protection need. 

Let's assume that CHAP_challenge was only MD5(MipMsgAbove).  Again, I
am no security expert, but to my understanding MD5 has its weeknesses
which would make it possible to insert data in MipMsgAbove (e.g. in the
form of a skippable extension), so that you can effectively choose
CHAP_challenge yourself. Appending LS237B(FA-chal) to CHAP_challenge
makes it a lot harder to choose the CHAP_challenge yourself. This was
also what Pete McCann <[email-masked]> replied in Message-ID
<[email-masked]> to my question:

	Using only the MD5 sum of the request (which normally includes
	the Challenge) would have been a possibility, but perhaps
	one could argue that by repeating the actual value of the
	Challenge and including it in the response we can further
	reduce the impact of potential hash collisions.

If the MN can generate FA-chal itself (as suggested for an MN with a
co-located address), then it can generate CHAP_challenge itself and
we're back to square one. In the case for timestamps, the ID field
can only be selected from a limited number of identifiers in way so
that the HA accepts it, and in the case for nonces there is exactly
one valid ID field. As you know, the purpose of the ID field is to
prevent replay protection, just to way the FA-challenge's purpose is
to prevent replay protection. The ID field is "in control" partially
by the HA and partially by the MN, effectively making it the HA's
challenge to the MN and vice versa.

If we allow the MN to select FA-challenge itself, then we should admit
that we could have left out LS237B(FA-chal) from CHAP_challenge to
begin with. If LS237B(FA-chal) was not in CHAP_challenge we wouldn't
be having this discussion.

To make it clear, I am not stating that I am correct, I'm just stating
my view of the situation. I'm open to discussion and explanations.

  Bjorn