Subject: [MOBILE-IP] Foreign Agent Challenge

From: Pete McCann <[email-masked]>
Date: Mon, 4 Oct 1999 15:12:45 -0500

Hi,

I have a couple of comments on the Mobile IP Challenge-Response draft
that Pat & Charles recently sent out for last call.

In order to integrate the Mobile IP Challenge-Response with any kind
of AAA infrastructure, some changes need to be made to the current
draft version.  At the very least, the ability to use new kinds of
authentication algorithms, for instance one compatible with CHAP
authentication, needs to be provided.

Note that this is NOT just a matter of defining new algorithms, and
allowing the SPI + NAI to indicate which one is in use.  For many
scenarios, the *Foreign Agent* needs to be aware of the algorithm
being used.  This is true whenever the authentication request needs to
traverse a AAA infrastructure that is itself incapable of carrying the
Mobile IP Registration Request - in this case, the Registration
Request must be translated by the Foreign Agent into another form
(such as a RADIUS Access-Request) and sent through the AAA
infrastructure.  To do so successfully, the FA needs to know what
authentication algorithm is being used and, additionally, that the
particular algorithm is compatible with (translatable to) the
particular AAA infrastructure being used.  This knowledge is necessary
so that the FA can successfully create the proper fields in the AAA
request from the Mobile IP Registration Request.  This act of
translation will depend on what fields were included in the challenge
response and what kind of hash was executed over them.

So, this introduces a new requirement: the authentication algorithm
must be known to the FA.  This could be accomplished in one of two
ways.  First, a new field could simply be added to the
Challenge-Response AVP indicating which algorithm is in use.  Second,
a few well-known SPIs could be reserved (as suggested by Ken Pierce's
document) to indicate the algorithm in use.  This would not interfere
with the ability of the home AAA to authenticate the MN, as we would
still have the NAI to index the table of shared secrets.  However
the use of the SPI for this purpose might strike some people the
wrong way, so maybe an Algorithm Identifier field could be added.

At the very least, I would like to see the following sentence added
to Section 4.2:

"Other authentication algorithms MAY be used by prior arrangement
between the MN and the authentication infrastructure."

I would also like to see something like the following:

"SPI values between the range of 0 and 255 are reserved for use
as an indication to the FA which authentication algorithm is in
use.  This may facilitate translation of the challenge response
into whatever form is used by the authentication infrastructure."

And if I had my druthers, I would also like to see:

"In particular, SPI value 1 is reserverd for the case where the
 authenticator is computed via the following algorithm:

   MD5(   high-order Challenge byte || key
       || MD5(Preceding MIP data || Type || Length || SPI)
       || least-order 237 bytes from Challenge
      )

"

-Pete

---

From: Yingchun Xu <[email-masked]>
Date: Tue, 5 Oct 1999 02:22:41 -0500

Agreed with Pete that a well-known ID is necessary in order for FA to identify
the proper authentication mechanism here. This is different from the
authentication between MN and HA where any SPI value can be configured between
them as long as they are consistent. The assumption there is that MN and HA are
managed by the same administration domain. But MN and FA are very likely
administrated by different domains. Either a well known SPI  or a new extension
as described in Pete's message is necessary in order for FA to identify the
correct algorithm while a mobile roams around from one carrier network to
another carrier network.

--Yingchun

Pete McCann <[email-masked]> on 10/04/99 05:07:35 PM

Please respond to Pete McCann <[email-masked]>

Sent by:  Pete McCann <[email-masked]>

To:   [email-masked]
cc:    (Yingchun Xu/MW/US/3Com)
Subject:  Re: [MOBILE-IP] Foreign Agent Challenge

Hi, Pat,

Patrice Calhoun <[email-masked]> (PC) writes:

PC> Historically, the SPI field (possibly combined with the home
PC> address, or more recently the NAI) allows the authenticator to
PC> identify the transform used.  Some pre-configuration is necessary
PC> here in order for both end-points to authenticate each other.

There is a difference here: in this case, the authentication is really
for the benefit of the FA, and it is performed by an AAA infrastructure
which may or may not be capable of propagating the entire Registration
Request intact.

PC> What I really do not understand is why a Foreign Agent needs to
PC> know what the authentication type that was used. If the Foreign
PC> Agent is talking to an AAA infrastructure which eventually leads
PC> to a RADIUS box (meaning CHAP style authentication was used), then
PC> it really is up to the Mobile Node and the RADIUS server to
PC> authenticate each other, not the Foreign Agent.

PC> Am I missing something?

Maybe my point wasn't clear: in the scenario of an FA connected to a
RADIUS infrastructure, it must translate the authenticator into a
challenge/response pair.  To do this accurately it must know what data
is covered by the authenticator and how the authenticator was
computed.  This is true of *whatever* entity translates the
Registration Request into a RADIUS Access-Request, whether it's the FA
or a AAA server farther along the chain.

PC> That said, the real question is whether the RADIUS-compatible
PC> authentication computation, which you provided below, needs to be
PC> part of the challenge response draft, or in a separate draft.

I would be somewhat happy with a separate draft, as long as there was
some mechanism to let the FA know which algorithm is in use.  This could
be either a reserved SPI or a new field called "algorithm identifier".

-Pete

---

From: Serge Manning <[email-masked]>
Date: Tue, 5 Oct 1999 09:58:03 -0500

I also concur with Ray since in the TR45.6 architecture, both MIP FAC and
RADIUS client functions exist in the FA and therefore need to interoperate
to authenticate the MN.  In terms of the options, Option 1 seems to the best
approach.

Serge Manning

>-----Original Message-----
>From: Raymond Hsu [mailto:[email-masked]]
>Sent: Monday, October 04, 1999 7:19 PM
>To: [email-masked]
>IMO, it is important for the FA Challenge/Response to interact with
>today's AAA protocol (i.e. RADIUS).  My understanding is that TR-45.6
>needs this requirement for their 3G Packet Data Standard by the end of
>this year.  TR-45.6's standard can only reference to
>standard-track RFCs.
>Option 2 below most likely will not meet TR-45.6's deadline.
>Therefore,
>my vote is for Option 1.
>
>Regards,
>
>Raymond Hsu
>
>At 01:37 PM 10/4/99 -0700, Patrice Calhoun wrote:
>>
>>That said, the real question is whether the RADIUS-compatible
>authentication
>>computation, which you provided below, needs to be part of
>the challenge
>>response draft, or in a separate draft. This draft, which we'll call
>>Mobile-IP RADIUS-Like Authentication Computation, is not
>specific to the
>>challenge draft since it could also be used with the MN-HA,
>MN-FA and the
>FA-HA
>>authentication extensions. So, I will ask the WG what they
>would prefer:
>>
>>1. A combined Challenge/Response draft that includes
>RADIUS-Like properties
>>2. A Challenge/Response draft and a separate RADIUS-Like
>draft (for use with
>>MN-AAA, MN-HA, MN-FA and FA-HA).
>>
>>Anyone care of state their preferences?
>>
>>PatC
>

---

From: Vipul Gupta <[email-masked]>
Date: Tue, 5 Oct 1999 08:30:10 -0700

I too prefer not using up the reserved SPIs to indicate what
  authentication mechanism is being used. A separate field or
  additional extension is better in my opinion.

  vipul

>Could get some opinions from this mailing list regards the use of reserved
>global SPIs versus the proposed approach of an "algorithm field"?

>I prefer the "algorithm field" approach because the number of globally reserved
>SPIs, as I understand, is limited. Given there is another approach that is
quite
>easy to understand, it doesn't seem wise to tax the reserved SPI pool for FAC
>use. In my opinion, this field should incorporated into the FAC draft, and the
>reserved SPI approach should be abandoned.

>Thanks,
>Tom Hiller

---

From: Patrice Calhoun <[email-masked]>
Date: Tue, 5 Oct 1999 10:05:11 -0700

Like the MN-HA and others, the MN-AAA should be able to allow for virtually
any authentication transform. However, the big difference here is what data
is actually used to genereate the authenticator since RFC 2002 and the
challenge/response draft simply takes the whole packet up to and including the
SPI. The new proposal is to change that, so I think a new extension is better.

I would like to get a feel from the Working Group about the text below. I
would prefer to get any objections *now* as opposed to once the draft is
in last call.

Please, object now if you have issues with it.

Thanks,

PatC

>Hi, Pat,
>
>Adding a new extension sounds like a good idea, but I am a little bit
>worried about future extensions to new authentication algorithms.  Are
>we using up extension numbers a bit too quickly?  Anyway, hopefully we
>won't have to do that - the MN-AAA extension should be "future proof".
>
>I would prefer to call the extension "MN-CHAP" instead of "MN-RADIUS"
>because that is really what we are emulating.  How about adding the
>following (I am just guessing about the Type 37 - is this number still
>free?):
>
>
>4.3. MN-CHAP Authentication Extension
>
>   The mobile node MAY include this extension in the Registration
>   Request when compatibility with CHAP-style authentication is
>   required.
>
>
>       0                   1                   2                   3
>       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>      |     Type      |     Length    |            SPI ...
>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>               ... SPI (cont.)        |       Authenticator
>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
>
>             Figure 3: The MN-AAA Authentication Extension
>
>
>      Type            37 (not skippable) (see [11])
>
>      Length          4 plus the number of bytes in the Authenticator;
>                      MUST be at least 20.
>
>      SPI             Security Parameters Index
>
>      Authenticator   The variable length Authenticator field consists
>                      random value of at least 128 bits.
>
>   The algorithm for computation of the authenticator is
>   MD5 [12] computed on the following data, in the order shown:
>
>         High-order byte from Challenge || Key
>      || MD5(Preceding Mobile IP data || Type, Length, SPI)
>      || Least-order 237 bytes from Challenge
>
>   where the Type, Length, and SPI are as shown above.  Note that this
>   requires a nested inner MD5 calculation over the Preceding Mobile
>   IP Data and Type, Length, SPI in order to provide protection against
>   replay attacks.  Least-order 237 bytes from Challenge means the entire
>   Challenge value if its length is less than 237.  No padding is added in
>   this case.
>
>
>And deleting the following text from 4.2:
>
>   If the mobile node does not include a Mobile-Foreign
>   Authentication extension, then it MUST include the MN-AAA
>   Authentication extension.
>
>And adding the following text to the intro to section 4:
>
>4. Mobile IP Registration Extensions
>
>   This section specifies new Mobile IP Registration Extensions that are
>   used to satisfy a Challenge in an Agent Advertisement.  If the mobile
>   node does not include a Mobile-Foreign Authentication extension, then
>   it MUST include either the MN-AAA Authentication extension or the
>   MN-CHAP Authentication extension.
>
>-Pete
>
>
>
>PC> It is quite clear that there is consensus that the challenge draft
>PC> needs to address RADIUS as well as another more feature-rich AAA
>PC> infrastructure.  Having throught about the problem, and possible
>PC> solutions, I have come to the conclusion that I am not fond of a
>PC> well-known SPI, or ID. What I would prefer to have are *two*
>PC> separate authentication extensions in the draft, one being the
>PC> MN-AAA, which already exists, and one being the MN-RADIUS
>PC> extension.
>
>PC> This means that Mobile Nodes that have an SA with a RADIUS server
>PC> MUST use the MN-RADIUS extension, while others could use the
>PC> MN-AAA. This, I believe, would make it MUCH simpler for foreign
>PC> agents to identify the challenge-style rather than having to
>PC> lookup an ID and/or SPI, both of which would require IANA
>PC> allocation.
>
>PC> Having not talked to Charlie about this one (since he is out of
>PC> the country), I would like to solicit initial comments on the
>PC> proposal.
>
>PC> PatC

---

From: Vipul Gupta <[email-masked]>
Date: Tue, 5 Oct 1999 17:48:15 -0700

A similar approach is used in draft-gupta-mobileip-inline-secparams-*.txt.
  It uses up only one value from the reserved SPI space and subdivides
  that space between different authentication mechanisms.

  One could easily define a new authentication algorithm type
  CHAP_AUTH and as part of the definition describe what portion of
  the registration message is covered by the auth computation.

  vipul

>> we using up extension numbers a bit too quickly?
>
>If the use of the extension number space really becomes a problem, why
>not apply subtyping to a set of extensions that belong together. This
>could be applied in a draft or a related set of drafts so that only
>one number describing a class of extensions is consumed.  Even the
>vendor extension could be used this way for private sets of extensions
>without consuming the number space.
>
>Regards,
>
>Jari Malinen
>Researcher, HUT/CS Lab.

---

From: Patrice Calhoun <[email-masked]>
Date: Wed, 6 Oct 1999 07:02:30 -0700

OK, I'll send out another query to the list.

Do people prefer to have two separate extensions, or one extension with
an algorithm type? Adding the algorithm type will change the format of
the proposed authentication extension, so most people will have to write
some new code to handle the new auth ext format.

Comments?

PatC

---

From: Eva Gustafsson <[email-masked]>
Date: Wed, 6 Oct 1999 17:17:55 +0200

We have a few questions concerning the challenge/response discussion:

To our best knowledge, RADIUS is considered an interim solution.
How do we solve the case of upgrading RADIUS to another AAA protocol,
preferably without having to reconfigure the MN?

One possibility is to let the home AAA server, when receiving a MN-CHAP
Authentication Extension, send an Error back to the MN, requesting it to
try again with a MN-AAA Authentication Extension.

Another question is what happens in a scenario with AAA brokers.
Consider a MN, with a RADIUS server at home. Assume that the MN visits a
network which uses another AAA protocol.
The MN then adds a MN-CHAP Authentication Extension to the Registration
Request message; shall the FA produce a AAA message (other than RADIUS)
with this information? How does the broker then translate this message
to RADIUS form?
And vice versa...

Shall we allow a MN to optionally add both a MN-AAA Authentication
Extension and a MN-CHAP Authentication Extension to a Registration
Request message?

Eva Gustafsson, Annika Jonsson, Henrik Basilier, Tomas Goldbeck-Löwe

---

From: Mohamed Khalil <[email-masked]>
Date: Wed, 13 Oct 1999 10:58:46 -0500

>some new code to handle the new auth ext format.

Pat,

Would it not be possible to use the SPI itself to indicate the
algorithm type? The default may be MD5 but I would think that the SPI
could be used to determine the algorithm type.... Let me know if this
thinking is flawed.

Of the two options that you suggest I would prefer adding an algorithm
type to the proposed auth extension as opposed to having two separate
extensions.

M. Khalil

>>  A similar approach is used in
draft-gupta-mobileip-inline-secparams-*.txt.

---

From: Patrice Calhoun <[email-masked]>
Date: Wed, 13 Oct 1999 10:54:15 -0700

>could be used to determine the algorithm type.... Let me know if this

It is flawed. Although it seems logical, this really goes against the
current Mobile IP Protocol.

>type to the proposed auth extension as opposed to having two separate

well, Charlie and I decided to have two separate extensions. This makes the
processing of the authentication extensions identical, regardless of whether
it is RADIUS or not. It is then up to the AAA client to figure out what to
do.

PatC

---

From: Mohamed Khalil <[email-masked]>
Date: Wed, 13 Oct 1999 13:04:54 -0500

Pat,

M. Khalil
> From: [email-masked] [SMTP:[email-masked]]
> Sent: Wednesday, October 13, 1999 12:54 PM
> To:   Khalil, Mohamed [RICH2:IP15:EXCH];
> [email-masked]