Subject: Re: [MOBILE-IP] Comments on PN-4732 -- MN-AAA Extension and FAC Draft

From: "[email-masked]" <[email-masked]>
Date: Tue, 23 May 2000 07:08:17 -0700

OK, In my Home Agent, if I receive a packet from a Foreign Agent, which
includes an MN-AAA Authentication extension, that was computed using the
"RADIUS" algorith, as defined in the Internet-Draft, when the Home Agent
generates an Access-Request. The Challenge is included, and the Response as
well, as produced from the alforithm defined in the draft.

The Home Agent knows that it shouldn't expect to see the MN-HA auth ext,
because it saw the MN-AAA authentication extension. If the RADIUS server says
yes, then the HA is happy, and produces the MN-HA using whatever key
distribution mechanism you've come up with in TSG-P, which smells of sending
the user's password in the clear.

PatC

---

From: Gopal Dommety <[email-masked]>
Date: Tue, 23 May 2000 11:44:21 -0700

>because it saw the MN-AAA authentication extension. If the RADIUS server says

So, the HA checks the lifetime etc and passes an Access-Request to the RADIUS server, which checks CHAP auth.

>the user's password in the clear.

Hmmm. Are you saying that the Registration request will have MN-AAA AE and the reply will have a MN-HA AE in this case? This is confusing and needs clarification.

The MN-AAA AE is used for AAA authentication and MN-HA is used for HA authentication. And optionalizing MN-HA AE implies that the mobile IP message Need Not Be AUTHENTICATED by  the HA but should check for replay protection (essentailly HA believes the AAA).  This changes the security model and the processing in the HA.

We have two options: 1. HA asks the AAA to authenticate the MN and 2. AAA authenticates the MN and tells the HA. What is not clear is the details and whether this works?

When we are operating with RADIUS (or any other protocol depending on the operation), the HA could  ask the RADIUS server  for authenticating, in which case some clarification is needed as to what the operations should be.

 Either we remove the text optionalizing the HA-MN AE or we should provide clarification how it is supposed to work. Since this changes
the mandatory authentication of RFC2002 (and some of the procedures) I think some clarification text is need to  the draft. Clarifing these procedures will enable interoperability.

If there any intricacies of  AAA protocols that are involved, those should also be clarified. Would the statement about making
MN-HA was made optional apply to Diamater like protocol only. If you could supply some clarification as to how it is supposed to
work with the details that would help. I have no problem with the procedures as long as there is enough clarification provided that will
help understand how it is supposed to work.

Thanks
Gopal

---

From: "[email-masked]" <[email-masked]>
Date: Tue, 23 May 2000 13:02:43 -0700

> RADIUS server, which checks CHAP auth.

When supporting RADIUS, that is about as good as it gets.

> Hmmm. Are you saying that the Registration request will have MN-AAA AE and
> the reply will have a MN-HA AE in this case? This is confusing and needs
> clarification.

OK. I re-read the draft, and it does state:
"The mobile node MAY include a MN-AAA Authentication extension in any
Registration Request."

It never mentions the MN-AAA ever being present in the reply. Are you asking
that the text be clarified in order to state that the MN-HA would be present
in the response? Since I've already seen four implementations interoperate, I
would like to make sure that the new proposed text is really clear, and
doesn't change the behavior of the I-D.

>
> The MN-AAA AE is used for AAA authentication and MN-HA is used for HA
> authentication. And optionalizing MN-HA AE implies that the mobile IP
> message Need Not Be AUTHENTICATED by  the HA but should check for replay
> protection (essentailly HA believes the AAA).  This changes the security
> model and the processing in the HA.
>
> We have two options: 1. HA asks the AAA to authenticate the MN and 2. AAA
> authenticates the MN and tells the HA. What is not clear is the details and
> whether this works?

But the design goal behind most of the AAA/Mobile IP work was to assume that
the AAA did not know how to decode/parse/build Mobile IP registration
messages. I would REALLY like for this to not change, since the AAA server
needs to be kept as simple as possible.

>
> When we are operating with RADIUS (or any other protocol depending on the
> operation), the HA could  ask the RADIUS server  for authenticating, in
> which case some clarification is needed as to what the operations should be.
>
>  Either we remove the text optionalizing the HA-MN AE or we should provide
> clarification how it is supposed to work. Since this changes the mandatory
> authentication of RFC2002 (and some of the procedures) I think some
> clarification text is need to  the draft. Clarifing these procedures will
> enable interoperability.

See my comment above. Further, the draft DOES include the following text:

" If the MN-AAA Authentication extension is present, then the Registration
Message MAY be sent by the mobile node without containing the Mobile-HA
Authentication extension [12]."

So, are you stating that you would prefer to see a MUST NOT instead of a MAY?

>
> If there any intricacies of  AAA protocols that are involved, those should
> also be clarified. Would the statement about making  MN-HA was made optional
> apply to Diamater like protocol only. If you could supply some clarification
> as to how it is supposed to work with the details that would help. I have no
> problem with the procedures as long as there is enough clarification
> provided that will help understand how it is supposed to work.

First, just for the record, whatever the AAA protocol happens to be (modulo
RADIUS), it should behave in the manner that we've been talking about for well
over 1.5 years, which is how DIAMETER is implemented. The actual AAA protocol
itself is really irrelevant.

PatC

---

From: Gopal Dommety <[email-masked]>
Date: Tue, 23 May 2000 14:51:22 -0700

>So, are you stating that you would prefer to see a MUST NOT instead of a MAY?

Adding MUST NOT  instead of MAY will remove the confusion. If we want to leave it as MAY then clarification
is needed.

Thanks
Gopal