Subject: Re: [MOBILE-IP] Foreign Agent Challenge

From: Patrice Calhoun <[email-masked]>
Date: Mon, 4 Oct 1999 13:37:50 -0700

Pete,

RFC 2002 discusses how an implementation does prefix+suffix for any of the
authentication extensions. However, there have been several drafts out that
add to RFC 2002 by defining new authentication mechanisms, mostly using new
transforms.

The challenge/response draft should work the same way as RFC 2002. The draft
defines one, but any other transforms could be used.

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

So far, I do not see a need to update the draft. Perhaps adding the one
sentence you mentioned would make it clearer, but I need to check whether RFC
2002 has such a sentence.

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

Am I missing something?

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

>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: Pete McCann <[email-masked]>
Date: Mon, 4 Oct 1999 17:07:35 -0500

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: Raymond Hsu <[email-masked]>
Date: Mon, 4 Oct 1999 17:18:36 -0700

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