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

From: "Jayshree Bharatia" <[email-masked]>
Date: Fri, 18 Apr 2003 11:59:28 -0500

Hello Ali,

Please see my comments inline.

Thanks,
Jayshree
> 
> 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.
> 
[JB] As per the scope of this draft "it defines extensions for the Mobile IP
Agent Advertisements and the Registration Request that allow a foreign agent
to use a challenge/response mechanism to authenticate the mobile node". You
are suggesting HA to manage challenge in same way as it is done by the
foreign agent. Looking from the scope of this document perspective, I am not
sure this is acceptable unless I hear something different from others. 
> 
>      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 ."
> 
[JB] Earlier we had the following issue noted on the mailing list:
According to section 3.2 of RFC3012bis "the FA MUST NOT remove the
Mobile-AAA Authentication Extension from the Registration Request prior to
the
completion of the authentication performed by the AAA infrastructure". This 
needs recommendation on the processing of the MN-AAA extension at the FA and

also HA if it is received.

Proposed Action: 
It was identified that we need the following text for the MN-AAA processing 
at HA in section 3.4:
"If the Mobile-AAA extension is received in the Registration Request, it
will be
handled based on the local policy of the Home Agent."

In addition to the above text addition in section 3.4, the following options
were suggested for section 3.2 
1. New text: "The processing on the Mobile-AAA extension if received at the
FA, is based on the local policy at the Foreign Agent"
2. New text: "FA  MUST not remove MN-AAA auth extension after successful
verification"
3. New text: "FA  MAY remove MN-AAA auth extension after successful
verification" 

It seems you are suggesting option 2 which is fine. Only issue I see with
your suggested text is the later portion. It implies that we have standard
mechanism to notify the FA regarding whether to remove MN-AAA auth
extension. This mechanism doesn't exist today. Any suggestion?

---

From: [email-masked]
Date: Thu, 24 Apr 2003 18:36:07 -0500

"Charles E. Perkins" <[email-masked]>@darkstar.iprg.nokia.com on
04/24/2003 04:27:19 PM

Sent by:  [email-masked]

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

Hi Charlie,

>                                     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.

>>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.

>>>ali>> I agree, this is a great time to do this.

>> 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.

>>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.

>>ali>> super.

>                                                             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.

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

>>ali>> great.

> 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.

>>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.

>>ali>> I see what you meant. That would have been a solution, but I think
that it is not supported by the radius servers today. Could this have been
a diameter solution maybe? Right now, the radius servers receive the access
request, authenticate the user, return an access-accept with an attribute
set from the user's profile. But I do understand how it could work the way
you are describing, if the AAA server had support for that behaviour.

>> 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.

>>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.

>>ali>> please see my comments towards the end, regarding co-lo mode..

> 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.

>>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.

>>ali>> The home agent will do exactly the same thing with MN-AAA and
FA-Challenge that the FA does. It will repackage it in a radius access
request, the way Pete McCann described, "in a way that would produce
correct authentication by a RADIUS server that didn't understand anything
about Mobile IP." This is why, the HA behaves differently when the rreq has
the MN-AAA extension versus when it does not. When it has, the chap_id,
chap_chal, and chap_pswd fields are composed by deriving them out of the
FA-Challenge and MN-AAA fields.

> 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.

>>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.

>>ali>> Well, if I am a network operator, I may have control over an HA,
and all the MIP clients that will connect to the HA. But my clients may go
through many different types of networks, with some FAs that send me the
MN-AAA extensions, and some FAs that do not. We can fix this problem by
arguing with the 835-B guys that they should follow 3344 and never send the
MN-AAA to the HA. However, maybe I want my HA to go to AAA and have my
clients get authenticated at the AAA, in the way that Pete's e-mail
describes.

>>ali>>On a different note, I completely agree with you that the 835-B
should have resolved these issues with the mobile-ip working group, before
putting FA requirements into the 835-B spec. I do not know the history of
835-B, so I cannot figure out why it was done the way it was. I would have
thought that they would work with the mip working group, resolve their
issues, then simply refer to the RFCs in 835, rather than explicitly making
statements about FA (PDSN) behaviour, in a none mobile-ip specification.
That's the root of the problem, I agree. If I'm implementing an FA which is
not a PDSN, I would not open up 835 and discover additional requirements.
So when the HA is receiving rreq's from PDSNs in 835 networks, and FAs in
'regular' networks, it is receiving protocol components from two different
specifications.. Perhaps the 835 authors were not considering the
possibility that the mobile client may be roaming from 835 networks (CDMA)
to non-835 networks, which is when inter-op problems are occurring.

>>ali>> In terms of local policy, what the 835-B did was to introduce a
radius attribute which tells the FA whether to drop the MN-AAA and FA-chal
or not. So, FA receives these extensions, composes an access-request, sends
it to the AAA. AAA authenticates the user, sends back access-accept, with
the attributes. FA looks through the attributes, if it sees the one
indicating that it should drop those two extensions, it drops them and
sends the rreq to the HA without the extensions. If however, the attribute
is not present, it sends the rreq with those two extensions. Not the
prettiest of solutions for sure...

>                                                  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.

>>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.

>>ali>> excellent.. This is better than my suggestion of _requiring_ this
behaviour from the MNs. If, in 3012, we describe how it can be done, then
operators who want this behaviour can require it from the clients that will
register at their HAs. The operator that controls the HA will also have a
say over the mobile nodes, so an over-reaching requirement in the RFC is
not needed. good point..

> 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.

>>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.

>>ali>> I understand.. putting these two extensions inside the FA-HA
extension's coverage should take care of that, if I'm not mistaken.

>                                      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.

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

>>ali>> So, do you think we can add to 3012, a _requirement_ that the FA
forward the two extensions in question, and a _description_ of how these
two extensions could be used in co-lo mode by the MN? I think these two
clarifications would  go a long way to enable consistent authentication
when the MN is roaming between 835 to 'regular' networks.

best regards,
ali