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

From: [email-masked]
Date: Thu, 24 Apr 2003 15:40:10 -0500

Hi Charlie,

Thanks for the comments.. Your point about the fact that the mobile-ip RFCs
are self-consistent and that they CAN work correctly is absolutely true.
However, they do provide multiple ways of achieving certain things, and
even though each works well by itself, when these mechanisms are mixed
together in a system where the mobile goes from one network to another, I
think consistent operation becomes, at least, very difficult to achieve.
Also, I do believe that the benefits that are to be derived from
authenticating the mobile at the AAA, when the mip rreq is received at the
FA, are just as desirable when the rreq is received at the HA.  Finally,
the fact that IS-835-B has put on certain mandates at the FA (wisely or
not), do pose a real-world interoperability problem, which can be fixed
here, without breaking the RFCs.

I am not understanding the following comment very well:
"It seems to me that your scenarios describe a message flow
in which the foreign agent concludes its business with the
AAA infrastructure before it transmits the RREQ to the home
agent.  If this is true, then it is not in harmony with the
message flows described in the appendices to RFC 3012."

It is my understanding that the FA will always conclude its business with
AAA before sending the rreq to the HA. FA will receive the rreq,
authenticate with the AAA, and if it receives the access-accept from the
AAA, it will send the rreq to the HA.

What would be very useful, I think, is if we could make the authentication
mechanism consistent accross all the network types, co-lo, fa-based,
IS-835-B, etc. We could do this by having the same authentication
extensions, computed in the same way, present in all these network types,
and always the same at both the FA (if it is in the network) and HA.
Otherwise, it is hard to specifiy that the HA will do X or Y depending on
local policy... If the HA never got the MN-AAA, local policy will not help
it make the decision. And since the HA will be dealing with multiple FAs
from multiple networks, some may send these extensions and some may not.

If we could clarify 3012, and require the FA to send both the challenge and
the MN-AAA to the HA, then the HA will be capable of AAA-based chap style
authentication, regardless of local policy at the FA. If we could also
clarify 3012, and require that co-located MNs also provide these two
extensions, then the HA would get the same consistent authentication
extensions even when the mobile is visiting a network without an FA. With
these requirements, the Home Agent would always see the same authentication
extensions, and would always have the option of authenticating chap-style
at the AAA, and the user would need only one profile at the AAA. At that
point, the HA still has the option of not using the MN-AAA extension and
authenticating locally by using the MN-HA extension, but AAA authentication
has been made possible and consistent.

I agree with your comment that if we require this behaviour from the FA,
the HA-FA extension should follow the MN-AAA and the Challenge extensions.
Your point about mandating the HA to _ignore_ the content of these
extensions is not very clear to me, however. The HA will use the MN-AAA and
the Challenge extensions in order to formulate the AAA access-request
message. However, the HA will not authenticate the mobile with those
extensions, it will rely on the AAA to do that, and when it receives the
access-accept, it can then do MN-HA authentication (if desired), and maybe
that's what you meant.

ali

"Charles E. Perkins" <[email-masked]>@sunroof.eng.sun.com on
04/22/2003 12:01:11 PM

Sent by:  [email-masked]

To:   Ali Akgun/MW/US/3Com@3Com
cc:   [email-masked], Tom Hiller <[email-masked]>,
      Jayshree Bharatia <[email-masked]>
Subject:  Re: [mobile-ip] mobile authentication inconsistencies

Hello Ali,

It seems to me that your scenarios describe a message flow
in which the foreign agent concludes its business with the
AAA infrastructure before it transmits the RREQ to the home
agent.  If this is true, then it is not in harmony with the
message flows described in the appendices to RFC 3012.

Furthermore, it is _not_ required to have the FA Challenge
in order to use the MN-AAA authentication extension.  It is
quite possible to design the AAA processing so that the
Challenge is not needed.  The Challenge may be mandated by
_other_ specifications (e.g., IS-835-B), but that does not
necessarily affect RFC 3012{,bis} or RFC 3344.  The foreign
agent is _not_ mandated by RFC 3012 to pass the extensions
to the home agent.  My understanding is that the foreign agent
"should" pass them along to the AAA infrastructure.  Whether
the home agent is contacted as part of the AAA infrastructure
operation is a matter for the designers of the AAA infrastructure
to determine.

However, it would be nice to support the mode of operation
you have described.  If I understand it correctly, the
foreign agent is designed to contact AAA for checking the
mobile node's authentication data, and then when the AAA
phase is over, to send the RREQ to the home agent, presumably
with a FA-HA authentication extension.  This is a valid
scenario.  One could omit the Challenge extension and/or
the MN-AAA authentication extension, and the system would
still work correctly and securely if the foreign agent
operated as currently specified.  Again, I do NOT claim
that it follows or enables any other external specification,
only that it CAN work correctly and is self-consistent.

On the other hand, it would not damage the protocol to
include the Challenge extension and/or the authentication
extension as long as one of the two following conditions
are also specified:
1) The foreign agent follows these extensions with a
   FA-HA authentication extension, or
2) The home agent is mandated to _ignore_ the content
   of those extensions.

It would still need to be decided whether the home agent
should copy them to the Registration Reply message.

With these understandings, there is no reason that the
mobile node cannot use a co-located care-of address.
Furthermore, I do not see any difficulty in roaming from
a co-located care-of address to a foreign-agent provided
care-of address.

I believe it would be worthwhile to find a way to make
these clarifications as part of the document production
for RFC 3012bis.  Please let us (Jayshree and myself)
what else needs to be said for maximum clarity.

I have CC:'d Tom Hiller on this because he may have some
useful opinions.

Regards,
Charlie P.

[email-masked] wrote:
>
> Hi everyone,
>
>      We've been playing with a system that has some CDMA components, and
> some non-CDMA components, and have been noticing inconsistencies between
> the two types of networks with regards to mechanisms of authentication.
> Some of these may have been discussed in this forum previously, but my
> search through the archives could not find a detailed and comprehensive
> discussion of them.
>
>      It seems like there are a number of contradictions between RFC 3344,
> RFC 3012, and IS-835-B, as well as some ambiguities. These contradictions
> and ambiguities may not have very serious real world consequences in
> homogenous networks, but they have a very real, and prohibitive effect on
> mixed networks.
>
>      I'll try to go through the issues first, and then will describe the
> problems caused by them. Finally, there is a couple of suggested changes
> which attempt to overcome these issues.
>
>      According to IS-835-B, upon receiving an access accept message from
> the AAA, the FA is expected to forward the MIP RRQ, including the MN-HA
and
> MN-AAA fields along with the Challenge, to the Home Agent, unless the AAA
> server returns an attribute indicating that the MN-AAA authenticator must
> be stripped before the RRQ is relayed to the HA:  (IS-835-B, 6.2.2.3)
"If
> the RADIUS attribute "MN-AAA Removal Indication" is included in the
RADIUS
> Access-Accept message, and if the RRQ contains an MN-HA Authentication
> Extension followed by the MN-FA challenge and MN-AAA Authentication
> Extension, the PDSN shall remove the MN-FA challenge and the MN-AAA
> Authentication Extensions when relaying the RRQ to the HA. Otherwise, the
> PDSN shall relay the RRQ to the HA as received by the MS."
>
>      RFC 3012, however, does not mandate that the FA should retain the
> MN-AAA authenticator and the challenge when forwarding the RRQ to the
Home
> Agent. Ambiguously, RFC 3012 does not mandate that these extensions
should
> be removed either. RFC 3344, however, states in section 3.7.2.2 that
"[the
> foreign agent] MUST process and remove any extensions following the
> Mobile-Home Authentication Extension".
>
>      The MN-AAA and FA-Challenge extensions always come after the MN-HA
> field, as required by RFC3012. This creates a contradiction, since an FA
> which is 835B aware, would be required to forward these extensions,
whereas
> an FA that is following RFC 3344 only, will interpret the RFC as a
mandate
> that that it must remove these extensions. It is a contradiction, and
> perhaps one that is a result of the fact that RFC3012 was written after
the
> original version of RFC3344, which was RFC 2002. There is also a cryptic
> statement in RFC3012, section 3.2, which could be interpreted in more
than
> just a few ways: "The Foreign Agent MUST NOT remove the MN-AAA
> Authentication Extension from the Registration Request prior to the
> completion of the authentication performed by the AAA infrastructure."
>
>      Moreover, the appendix section of RFC3012, depicts in an example
> diagram that the HA is a part of the verification infrastructure, and
> describes the Home Agent taking part in the verification process:
> "Implicit in this picture, is the important observation that the Foreign
> Agent and the Home Agent have to be equipped to make use of whatever
> protocol is made available to them by the challenge verification and key
> management infrastructure shown in the figure."
>
>      Likewise, section 3.4 of RFC 3012 describes the action to be taken
by
> a Home Agent receiving an FA-Challenge extension. This follows section
3.1,
> where the RFC dictates that this extension MUST come after the MN-HA
field.
> It is evident that RFC 3012, does not assume that Foreign Agents will
> remove all extensions following the MN-HA extension as they were mandated
> to do in RFC 3344.
>
>      Compounding the problem is the fact that neither the RFCs nor
> IS-835-B, indicate how a mobile can use the MN-AAA authentication
extension
> in co-located mode, when there is no Foreign Agent in the network, and
> therefore no challenges are received by the mobile. This could of course
be
> interpreted as an indication that the MN-AAA authentication extension
> should not be used in co-located mode is not intended to be used in
> co-located mode.
>
>      It is, in fact, possible to use the MN-AAA extension in co-located
> mode. The mobile can generate the challenge value itself, and use that
> value to compute the MN-AAA authenticator. Since both the authenticator
> *and* the challenge value are included in the registration request, the
> Home Agent can form the AAA access request message in exactly the same
way
> as it did when the challenge was generated by a FA. This would remove the
> value of the challenge field as a replay protection device, but it would
> allow the use of the MN-AAA authentication mechanism. (It should be noted
> that the HA is protected from replay attacks through another device, the
> identifier field in the MIP header.
>
> Current Interoperability Problems
>
>      To see the effects of these ambiguous and sometimes contradictory
> requirements, we now look at the actions taken by the nodes in a system
> comprised of multiple networks, some of which may be IS-835-B compliant
> CDMA systems while others may be WiFi networks that are either
transparent
> to mobile-ip (co-located), or have Foreign Agents that are compliant with
> the RFCs, but are not aware of IS-835-B.
>      We initially have three possible scenarios, when the mobile is first
> registering with the Home Agent:
>
> 1.) Mobile in a network with an RFC-only Foreign Agent:
>      MN creates RRQ with MN-AAA, FA-Challenge and MN-HA extensions.
>      FA goes to the AAA with the MN-AAA authenticator and the FA
Challenge.
>      FA strips the MN-AAA and FA-Challenge Extensions, forwards RRQ to
HA.
>      HA goes to the AAA with a common password in order to receive MN-HA
> key.
>
> 2.) Mobile in a network with an IS-835-B Foreign Agent:
>      MN creates RRQ with MN-AAA, FA-Challenge and MN-HA extensions.
>      FA goes to the AAA with the MN-AAA authenticator and the FA
Challenge.
>      FA relays the RRQ to the HA, with the MN-AAA and FA Challenge
> extensions.
>      HA goes to the AAA with the MN-AAA authenticator and the FA
Challenge.
>
> 3.) Mobile in a network with no Foreign Agent:
>      MN  creates RRQ with MN-HA extension only.
>      HA goes to the AAA with a common password in order to receive MN-HA
> key.
>
>      Things get even more complicated, when we consider that a mobile may
> roam from one of these networks to another, and that the Home Agent would
> then receive Registration Requests from the same user, but with different
> authentication components.
>
>      One case would involve a 3GPP2 network with a IS-835-B PDSN acting
as
> a Foreign agent, and a WiFi network without a Foreign Agent. In this
setup,
> when the mobile registers with the HA through the 3GPP2 network, the HA
> will receive a MIP RRQ with the FA-Challenge and the MN-AAA extensions,
> along with the obligatory MN-HA extension. The HA will then request a
CHAP
> style authentication from the AAA. When the user registers on the WiFi
> network, however, the mobile will send a MIP RRQ with only the MN-HA, and
> the HA will have to go the AAA with a password common to all users, in
> order to get the MN-HA secret.
>      The same situation would arise when the mobile goes to a WiFi
network,
> which has a Foreign Agent that is not aware of the IS-835-B requirements.
> The MIP RRQ that the HA receives from that network would have its MN-AAA
> and the FA-Challenge extensions already stripped by the FA.
>
>      With these cases it is our understanding that the user will not be
> successfully authenticated by the AAA server in one of these registration
> attempts; the profile for the user will have been setup either to succeed
> with the unique password that is used as part of the MN-AAA
authentication
> scheme, or it will have been setup to succeed with the simple password
> which will need to be common to all the profiles.
>
> Proposed Solution
>
>      The correct solution for this problem lies in making the
> authentication mechanism identical in all three of the above listed
> scenarios. One way to do this would be to require that Home Agent always
> discard the MN-AAA authenticator, and use a common password to retrieve
the
> MN-HA key and authenticate the user locally on the Home Agent. This
> solution, however, has serious drawbacks, foremost among which are the
> facts that a single password is being used to retrieve all profiles from
> the AAA server and that the authentication process is taking place at the
> HA, and not at the AAA.
>
>      We therefore propose another solution:
>
>      1.) Remove the contradictions and ambiguities IS-835-B and RFCs 3012
> and 3344.
>      IS-835-B already lets the AAA tell the FA whether or not the
> FA-Challenge and the MN-AAA extensions should be removed from the MIP RRQ
> prior to the FA forwarding it to the HA. Modify RFC 3012, which is
already
> under revision currently, to mandate that "the FA MUST NOT remove these
> extensions, unless it is instructed to do so by the verification
> infrastructure". If possible, modify 3344, to replace the section that
> dictates the removal of all fields following the MN-HA field, with a
> statement such as "The FA MUST remove all fields following the final
> authentication extension. The FA may remove some of the authentication
> extensions, if instructed to do so by the verification infrastructure ."
>
>      2.) Add explicit wording in in RFC 3012, to describe the use of the
> MN-AAA and FA-Challenge extension when the mobile node is running in
> co-located mode.
>
>      Modify RFC3012, to add a section, "Co-Located Mobile Node
Processing".
> The wording would be similar to: "In co-located mode, the mobile, MUST
> randomly choose a challenge value, and compute the MN-AAA authenticator.
> The mobile MUST include the challenge value it chose in the FA-Challenge
> extension field and the MN-AAA authenticator it calculated in the MN-AAA
> Authentication extension field in the mobile-ip registration request it
> generates."
>
>      We believe that with these changes implemented in the mobile node,
and
> in the Foreign Agent, the home agent would always get consistent Mobile
IP
> Registration Requests, resulting in a uniform authentication mechanism,
> regardless of the specifics of the foreign network the mobile node is
> coming from.
>
> looking forward to your comments,
> - ali

---

From: "Charles E. Perkins" <[email-masked]>
Date: Thu, 24 Apr 2003 14:27:19 -0700

Hello again Ali,

[email-masked] wrote:

>                                     when these mechanisms are mixed

But that has to be among our objectives, so let's fix whatever
problems there are.  Now would be a good time, since RFC3012bis
is almost ready for publication.

> FA, are just as desirable when the rreq is received at the HA.

I agree there are benefits.  I just meant to say that the specification
was not originally written to provide them.  I believe if we can get
the specification to provide them, that would be a good idea.  I had
thought we were close to doing that.

>                                                             Finally,

Sounds good to me, especially if you can help us accomplish that.

> AAA, it will send the rreq to the HA.

The intention of using the "AAA infrastructure" as originally written
was that the AAA infrastructure would do the Mobile IP registration
process with the home agent, and then relay the RREP along with the
appropriate AAA status codes and results (and possibly keys) to the
foreign agent.  This is according to the understanding that Pat and
I had with the TR45.6 specification group at that time.

> and always the same at both the FA (if it is in the network) and HA.

That's not a very nice solution, because it places constraints on all
other designs because of some arguably broken specification that we
never heard of at the time.  I don't think I could support that mandate.

> from multiple networks, some may send these extensions and some may not.

The home agent should _never_ use the MN-AAA authentication extension
to do its work.  It should use the MN-HA authentication extension.
The MN-AAA extension is specified for use of the AAA entity, which
is likely to use a whole different protocol than Mobile IP.

> authentication, regardless of local policy at the FA.

You are saying that we should eliminate the possibility of
allowing the foreign agent to be affected by local policy
considerations -- again, because of some other specification
which was enacted after the fact.  And, I might add, without
any consultation or discussion with the IETF mobile-ip working
group.  One could reasonably make the case that it's not our
problem.  On the other hand, I don't mean to be completely
insensitive.  I just wonder if there isn't some solution that
may require more programming from IS-895-B system implementers.
Our goal should be to make that a possibility at least, even
if we cannot satisfy IS-895-B trivially with zero programming.

>                                                  If we could also
> extensions even when the mobile is visiting a network without an FA.

We can _allow_ a mobile node to do this in co-located mode.
Whether it does so or not, would depend on policy settings that
were configured probably at the same time that the security
association parameters were configured.

> extensions is not very clear to me, however.

What I wanted to suggest was that the home agent MUST ignore
unauthenticated data.  If it's authenticated, then it's safe
to use, but not otherwise.

>                                      The HA will use the MN-AAA and

That would be O.K. with me, I think, since it preserves correctness
at least up to the level of base RFC 2002.

Regards,
Charlie P.