Subject: RE: [AAA-WG]: Previous-FA-XXXX AVP

From: "Martin Julien (ECE)" <[email-masked]>
Date: Thu, 19 Apr 2001 12:00:52 +0200

> >So the question was: "What happens when a second MN tries to
> >register with the same Nai, home address and home agent address?"
> >
> >If the other MN registers within the same foreign network, I would
> >say that the MN would reach the AAAF, which would return the FA-MN
> >and FA-HA keys to the new FA.
> 
> No, the AAAF will not return any keys since it will not receive any
> Previous-FA-XXXX AVP. The request will continue to AAAH which 
> will have
> a session with the same Nai, Home Address, and Home agent 
> address. It may
> decide to send the reply back with new keys and the 
> Original-Session-Id AVP,
> thus no new session is created.

I don't see why it is required to have the Previous-FA-XXXX AVP if 
you already have the Nai, home address and home agent address to
identify uniquely a session? What more would you get by receiving 
it in the AAAF? When you receive an AMR in the AAAF, you know that 
the MN has either moved to a new FA, or it is requesting a new set 
of keys, or it is a fresh first registration, right?

> I believe that in the absence of a Previous-FA-XXXX AVP the 
> AAAH should take
> the request as a new one, i.e. assign it a new home address, 
> home agent
> address...

I think that if the AAAF can not find any information locally 
related to the MN based on the Nai, home address and home agent 
address, then the AMR should be forwarded to the AAAH. Of course,
unless a new set of keys is also required by the MN, which means
that the AMR obviously needs to be forwarded to the AAAH.

The FA should forward the MIP registration directly to the HA 
only if the AMA does not include a MIP-Reg-Reply.

I think we should also consider the case where a fraudulent user
would seized the User-Name, the Home address and the Home Agent 
address and would try to override the "truly authorized" registration
of the "true" user. I guess that the Previous-FA-XXXX AVP could also
be hijacked easily.

What do you think?

> /Fredrik
> 
> >That security issue should be left
> >to the configuration of the AAAF to trust or not the new FA. Then,
> >the new FA would forward the registration request to the HA, which
> >would fail, since the MN does not have the good MN-HA key. So my
> >question is now: "What should the HA do when it rejects a
> >registration?" For sure, it should not cancel the registration
> >until a proper de-registration is ordered by the MN, or the
> >absence of re-registration at the specified period of time.
> >
> >If the registration occurs in a different (3rd) domain, then the
> >keys are returned by the Home server, and the same process occurs.
> >
> 
> Same as above
> 
> >I'm not sure, but at the first glance, it seems that the HA
> >remains the only one, with the AAAH, controlling if the MN is
> >legitimate or not.
> >
> >Martin
> >
> >> -----Original Message-----
> >> From: Martin Julien (ECE)
> >> Sent: Wednesday, April 18, 2001 2:52 PM
> >> To: 'Fredrik Johansson'; Martin Julien (ECE);
> >> [email-masked]; Tony
> >> Johansson
> >> Cc: AAA Listan
> >> Subject: RE: [AAA-WG]: Previous-FA-XXXX AVP
> >>
> >>
> >> In the case where the MN is roaming within a foreign domain,
> >> a Registration is sent and an AMR is be sent to the AAAF. Then the
> >> AAAF returns the keys to the new FA without authenticating
> >> the MN. That seems to be a "problem". However, if it would reach
> >> the Home server, then the MN could be authenticated based on
> >> the MIP-MN-AAA-Auth AVP, which could decide if it is a valid
> >> request for reporting a roaming situation.
> >>
> >> Then, should we define a new MIP-MN-AAAF-Auth AVP?, or should every
> >> registration reach the Home server each time?
> >>
> >> Martin
> >>
> >> > -----Original Message-----
> >> > From: Fredrik Johansson 
> [mailto:[email-masked]]
> >> > Sent: Wednesday, April 18, 2001 1:26 PM
> >> > To: Martin Julien (ECE); [email-masked]; Tony Johansson
> >> > Cc: AAA Listan
> >> > Subject: RE: [AAA-WG]: Previous-FA-XXXX AVP
> >> >
> >> >
> >> > Looks like it would work, the only question is what happens
> >> > when a second MN
> >> > tries to register with the same Nai, home address and home
> >> > agent address?
> >> >
> >> > /Fredrik

---

From: Tony Johansson <[email-masked]>
Date: Thu, 19 Apr 2001 16:36:11 -0700

Hi,

Please see my comments embedded....

BR,

/Tony

> of keys, or it is a fresh first registration, right?

I agree it seems to work without the Previous-FA-XXXX AVP in most cases.
However, here is one scenario where I think it is needed.

Let's say that you have a hierarchical AAA architecture with two sub-domains
within a large network domain. In each sub-domain you have a AAA and FAs and
these two AAAs are connected to a broker/proxy AAA. The broker/proxy AAA is
used every time the AAAs in the sub-domains can't resolve it on their own.
So let's say that a user that belongs to another network domain has been
registered via an FA in one of the sub-domains to an HA in its home network.
Let's now assume that this user does a handoff to another FA in the other
sub-domain, which means the new AAAF will issue the AMR toward the
broker/proxy AAA. With the Previous-FA-XXXX AVP, the broker/proxy would be
able to proxy (1) or redirect (2) the AAAF to get the existing keys from the
old AAAF. Without the Previous-FA-XXXX AVP, you would be forced to store
more info in the broker/proxy AAA to achieve this functionality, otherwise
you would be forced to proxy the message back to the MN's AAAH (3). Does
this make sense?

    (Please view in a fixed-width font such as Courier.)

+----------------------------------------------+
|                                              |
|             mydomain.com                     | home.com
|                                              |
|                            +--------+        | +------+
|         +------------------+ AAAB   +--->(3) | |AAAH  |
|         |                  |        |        | |      |
|         |                  +--+-----+        | +------+
|         |                     |   ^          |
|         V                     V   |          |
|        (1)                   (2)  |          |     +---+
|                                   |          |     |HA |
| +------------------+    +---------|--------+ |     +---+
| |                  |    |         |        | |
| |                  |    |         |        | |
| |sub1.mydomain.com |    | sub2.mydomain.com| |
| |                  |    |         |        | |
| |                  |    |        ++------+ | |
| |      +-------+   |    |        |AAAF   | | |
| |      | AAAF  |   |    |        |       | | |
| |      |       |   |    |        +-------+ | |
| |      +-------+   |    |          ^       | |
| |                  |    |          |       | |
| |    +--+          |    |        +-++      | |
| |    |FA|          |    |        |FA|      | |
| |    +--+          |    |        +--+      | |
| |                  |    +---------^--------+ |
| +------------------+              |          |
|                                 +-+-+        |
|             ----------------->  |MN |        |
|                                 +---+        |
|                                              |
+----------------------------------------------+

---

From: "Fredrik Johansson" <[email-masked]>
Date: Fri, 20 Apr 2001 09:17:46 +0200

Hi,

[Fredrik Johansson]

That is true, and you can not protect a stupid user from himself.
My idea of sending the registration request back in the AMA was so
that the client should not have to keep state, but I guess it has to
anyway incase the transport fails. So the absence of a Reg Reply is
good enough.

/Fredrik

---

From: Patrice Calhoun <[email-masked]>
Date: Tue, 24 Apr 2001 09:48:57 -0700 (PDT)

All,

I am now just starting to catch up with the mailing list threads, and I read
the one on how to create a session id with great interest.

The protocol, as far as I understand it, is that a session identifier would be
created using (NAI+Home Address+Home Agent Address). I have the following
comments on this proposal:

1. Assuming that a user logs on at 10am, logs out at 11, then logs in again at
1pm, there is no way to recognize that these would be different sessions,
based on the session-id. For this reason, RADIUS requires that session-ids be
unique, and Diameter goes further by stating that they must be globally
unique. The proposal fails this test.

2. This requires that the base protocol's session-id creation be dependent
upon the mobile ip extension, which is bad. The MIP extension is an extension,
and MUST NOT require base protocol changes.

3. In most cases, a mobile will NOT have a fixed Home address, or even Home
Agent. So the Session-Id would always be the NAI followed by 64bits set to
zero. Not very unique (see above). So, for this to work, it would require that
the session id change once the user has been authenticated, and authorized.
This really does require some base protocol changes.

So for the above reasons, I would prefer that the base protocot NOT change
only to satisfy the MIP extension. NASREQ must be able to be used, without MIP.
 PatC