Subject: [mobile-ip] mobile authentication inconsistencies

From: [email-masked]
Date: Mon, 14 Apr 2003 12:23:19 -0500

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: Bjorn Andersson <[email-masked]>
Date: Tue, 15 Apr 2003 10:41:00 +0300

I have stumbled across the same problems as Ali, which he has covered
well in his mail. Here's my comment on the MN-AAA authenticator. I'll
probably get back to the other issues later.

> identifier field in the MIP header.

[...]
> Authentication extension field in the mobile-ip registration request it

In my opinion the problem with RFC3012 is not the MN-AAA extension,
but how the CHAP authenticator is computed. From the context I guess
this is what Ali means. Why is the challenge explecitely included
when calculated the authenticator MD5 sum? Wouldn't it be sufficent to
include the challenge extension in the registration message as it is
and calculate the MD5 sum for the preceeding message (which includes
the challange extension). This would form the CHAP challange. The
authenticator would then be the MD5 sum computed over the key and
CHAP challange. When registering in co-located mode no challange
extension is needed: The challange is the ID field and the CHAP
authenticator can be computed without the challange extension.

The question is: what is the rationale for including the data from
the Challange extension directly in the authenticator (instead of
mandating that a challange extension has to be included if registering
via a FA)? If there is a reason for it, I think it should at least
be described in the RFC.

  Bjorn

-- 
Bjorn Andersson <[email-masked]>
PGP id 5AFC144B
Mobile +358 40 7723074

---

From: "Charles E. Perkins" <[email-masked]>
Date: Tue, 22 Apr 2003 10:05:07 -0700

Hello Bjorn,

> via a FA)? If there is a reason for it, I think it should at least

The rationale is that we were told to do it that way
for interoperation with RADIUS.  I don't remember the
details, but again I am CC:'ing Tom Hiller and Pete McCann
who, if I remember correctly, had a lot more to say about
the processing of the CHAP extension than I cared to have.
Basically, at this point, I would be happy with whatever
is the right thing to do, but keeping some thought with
compatibility with existing RFC 3012 systems.

Regards,
Charlie P.

---

From: "Charles E. Perkins" <[email-masked]>
Date: Tue, 22 Apr 2003 10:01:11 -0700

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.

---

From: Pete McCann <[email-masked]>
Date: Tue, 22 Apr 2003 16:57:54 -0500

Hi,

 > > via a FA)? If there is a reason for it, I think it should at least

The choice was somewhat arbitrary; the only requirement was that we
have something to fill in the CHAP Ident & String of the CHAP
Password and the CHAP Challenge fields of a RADIUS message (see RFC
2865) in a way that would produce correct authentication by a RADIUS
server that didn't understand anything about Mobile IP.

Using only the MD5 sum of the request (which normally includes the
Challenge) would have been a possibility, but perhaps one could argue
that by repeating the actual value of the Challenge and including it
in the response we can further reduce the impact of potential hash
collisions.

If you really want to do a co-located mode registration I suggest you
don't use the CHAP_SPI; in fact, you may be better off with simple
MN-HA authentication.

 > compatibility with existing RFC 3012 systems.

We should not make any change in 3012-bis that would break backwards
compatibility for CHAP_SPI.

-Pete