Subject: Re: [mobile-ip] mobile authentication inconsistencies, continued

From: [email-masked]
Date: Mon, 12 May 2003 17:43:06 -0500

Hey Pete,

Thanks for the answers.. We are trying to use CHAP in order to have a
single mechanism of authentication (at AAA, through the HA, not at the HA
via the MN-HA) as the mobile moves from a networks with FAs to networks
without  FAs. Some of the networks with FAs have 3G equipment where the FA
can be instructed to forward the MN-AAA and FA-Chal to the HA, and the HA
can formulate a CHAP style access-request in order to authenticate at the
AAA. There are also non 3G FAs which can be instructed to do the same. We
are trying to cover the thrid scenario when the MN finds no FA in the
network it moves into. Ideally, the HA would get the same extensions in all
three scenaorios, and would always be able to authenticate at the AAA,
using CHAP. (This is separate from the HA-MN authentication.)Regarding your
comment the randomX number, yes, that number needs to be communicated in
the challenge extension.

ali

Pete McCann <[email-masked]>@sunroof.eng.sun.com on 05/12/2003 03:46:55
PM

Sent by:  [email-masked]

To:   Ali Akgun/MW/US/3Com
cc:   [email-masked], [email-masked],
      [email-masked], [email-masked], [email-masked]
Subject:  [mobile-ip] mobile authentication inconsistencies, continued

Hi, Ali,

My first question would be why are you using CHAP_SPI in co-located
mode?  Why not just pick another SPI and use the default algorithm?

If you do have a good reason for this, then I think your proposal
would work, but you need to make sure that the Challenge extension
containing rand-numberX also appears somewhere in the message.  I
don't think it would normally be there in co-located mode.

On your security question, I am not sure it is possible to gauge the
"cryptographic security" of a mechanism if you don't specify what is
being protected and from whom it is being protected.  From what you
say below, it sounds like the MN-AAA extension is not really serving
any useful purpose in the message (anti-replay is covered by the
Identification field, as you know) so the "security" of the scheme is
really not an issue, right?

-Pete

[email-masked] writes:
 > Hey Folks, and Pete in particular,
 >
 > The following question seems to be remaining in some minds, regarding
the
 > modifications suggested for 3012bis:
 >
 > Currently, MN-AAA is calculated as follows:
 >
 > (1)  MD5(MSB(FA-chal) + Secret-Key + MD5(MipMsgAbove) + LS237B(FA-chal))
 >
 > Where "+" indicates concatenation.
 >
 > For the sake of interoperability in co-located mode, when the challenge
is
 > not present, say a mobile was to just pick a number, and subsititute it
in
 > place of the FA-Challenge, and calculate the MN-AAA as:
 >
 > (2)  MD5(MSB(rand-numberX) + Secret-Key + MD5(MipMsgAbove) +
 > LS237B(rand-numberX))
 >
 > For those with expertise in crypto: Is this message digest calculated in
 > (2), cryptographically any less secure than the one calculated in (1)?
 > Please note that the question does not pertain to re-play protection,
but
 > rather to the MD5 hash function itself. And also note that, the question
is
 > strictly bound by the current application -- authentication of the
 > registration-request messages in Mobile-IP. Also, I am definitely not
 > asking why the FA-chal was included in the MN-AAA calculation
originaly..
 > just trying to ascertain that the workaround I am suggesting in
co-located
 > mode does not present a security issue.
 >
 > looking forward to your comments,
 > ali