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

From: "Munson, Mark A." <[email-masked]>
Date: Tue, 5 Oct 1999 08:49:17 -0400

I am in support of Pete and Yingchun on this.  I think that it is important
to get the FAC out and implemented ASAP, but the reality is that RADIUS
infrastructure may be all that is available for some time.  Therefore, the
proposed approach of either reserving some SPIs or adding an authenticator
identifier seems to be the best solution for the immediate needs, as well as
allowing for  flexibility in the future.

Regards,
Mark Munson

> ----------
> From:         Pete McCann[SMTP:[email-masked]]
> Reply To:     Pete McCann
> Sent:         Monday, October 04, 1999 6:07 PM
> To:   [email-masked]
> 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
>
>
> >> 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: Tom Hiller <[email-masked]>
Date: Tue, 5 Oct 1999 09:33:16 -0500

These are very good points being raised. We need the FAC in wireless data for
authentication, authorization, and accounting purposes. Initially, the HAAA will
likely/often be a RADIUS server, and as Yingchun points out, the mobile must be
assumed to be roaming so the FA has no relationship per se with the MN or HA.

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: Gopal Dommety <[email-masked]>
Date: Tue, 5 Oct 1999 09:40:21 -0700

I agree with Mark, Pete, and Yingchun in that
1. we need  RADIUS-compatible authentication computation.
2. Need to know what data is covered by
the authenticator and how the authenticator was computed.

I  do see  your point  Pat that historically  SPI  (with other fields)
allowed the   authenticator  identify the   transform used   and would
require some pre-configuration (I was trying to  figure out the reason
for this decision, can anybody shed  some light on  this?). But in our
case an entity other than the end entities might have to do some
processing.

I will read the entire thread and try to understand the current
momentum.

Thanks
Gopal

 is necessary