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

From: "Martin Julien (ECE)" <[email-masked]>
Date: Thu, 19 Apr 2001 09:16:36 +0200

Hi Fredrik,

I realized that in my previous e-mail, I had diverged from my original thoughts while writing it, which seems now to be a better understanding of the problem than my previous suggestion.

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

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
> > 
> > >
> > >Ok, let me try again.
> > >
> > >More than one session need to be supported for each MIP user, which
> > >means that a user might want to register several MNs on the
> > >network at once.
> > >That would lead to several separate MIP sessions in the Home 
> > server. AFAIK,
> > >each MIP session can be uniquely identified by using both its Home
> > >Agent address
> > >and its Home address. We could also add the User-Name, to 
> > easily link all
> > >sessions for a particular user. That means that each MIP 
> > session would be
> > >keyed on User-Name, Home Agent and Home Address. That takes 
> > into account
> > >private addresses as well.
> > >
> > >Then a first MN registers with a User-Name. Since it is the first
> > >registration in a foreign domain, then no 
> > MIP-Previous-FA-XXXX is present,
> > >neither Home Agent nor Home address. Then the FA creates a 
> > new Session-ID,
> > >which is sent to the AAAF, which forwards it to the Home 
> > server, since
> > >it is the MN's first registration. Then the MN is registered 
> > successfully.
> > >
> > >Then the MN moves to a new FA within the same domain. The MN 
> > will send the
> > >User-Name, the Home Agent and Home address, along with the
> > >MIP-Previous-FA-XXXX.
> > >Then the new FA will send the AMR to the AAAF, which will check if
> > >there is
> > >any existing session linked to a similar registration, based on the
> > >User-Name, the Home Agent and Home address. Since there is, the
> > >AAAF returns
> > >the Original-Session-ID, along with the FA keys.
> > >
> > >I guess that the same could apply when the node moves to a 
> > third domain, in
> > >which case it would be the Home server that would be responsible
> > >of returning
> > >the Original-Session-ID and FA keys. The same for moving to its
> > >Home domain.
> > >
> > >If there is a second MN that registers for the same user, 
> > then it would
> > >register without a Home Agent and Home Address. Or if it 
> > does, I guess
> > >that the Home address should be already defined as unique for that
> > >particular MN, right? That means that a new session would 
> be created
> > >by the new FA, which would trigger a new session in the 
> Home server.
> > >That new session would be uniquely identifiable by the User-Name,
> > >the Home Agent and the Home address of the MN.
> > >
> > >If ever we need to control
> > >the number of allowed sessions per user, the Home server can 
> > reject the
> > >AMR when it receives a new registration request from a new MN.
> > >
> > >Does that make a bit more sense?
> > >
> > >Martin
> > >
> > >> -----Original Message-----
> > >> From: Fredrik Johansson 
> [mailto:[email-masked]]
> > >> Sent: Tuesday, April 17, 2001 4:53 PM
> > >> To: Martin Julien (ECE); [email-masked]; Tony Johansson
> > >> Cc: AAA Listan
> > >> Subject: RE: [AAA-WG]: Previous-FA-XXXX AVP
> > >>
> > >>
> > >> Hi Martin,
> > >>
> > >> How would generating a session id from User-Name and
> > >> MIP-Previous-FA-XXXX
> > >> help you to have several MIP sessions for the same user 
> if the have
> > >> different MNs? The user may still use the same User-Name on
> > >> all of its MNs,
> > >> thus causing the same session id to be created.
> > >>
> > >> So, I don't believe it will solve the problem. If it is a
> > >> problem that you
> > >> cannot have several session with the same nai, isn't that 
> > one of the
> > >> problems with radius that there is no way to limit a user
> > >> from login in
> > >> from several places at the same time using the same user name
> > >> and password?
> > >>
> > >> /Fredrik
> > >>
> > >> >
> > >> >Hej Fredrik,
> > >> >
> > >> >If the Session-ID would be generated and handled by the MN, I
> > >> >guess it would be a lot easier. At least, we could propose a way
> > >> >of generating a Session-ID in the FA, such as the 
> concatenation of
> > >> >the User-Name and the Care-Of address (FA), which would 
> lead to a
> > >> >predictable Session-ID. In the case where the MN would move to a
> > >> >new FA, then the new FA would need to generate a 
> Session-ID based
> > >> >on the User-Name and the MIP-Previous-FA-XXXX. Would 
> that make any
> > >> >sense? Then, I guess we could have several different 
> MIP sessions
> > >> >for the same User, as long as it is using different MNs. To
> > >> >support more than one session per MN, I guess the MN 
> would need to
> > >> >include additional info about that.
> > >> >
> > >> >We are having the same kind of problems WRT SIP, I believe.
> > >> >
> > >> >Martin
> > >> >
> > >> >> -----Original Message-----
> > >> >> From: Fredrik Johansson 
> > [mailto:[email-masked]]
> > >> >> Sent: Tuesday, April 17, 2001 3:01 PM
> > >> >> To: [email-masked]; Martin Julien (ECE); Tony Johansson
> > >> >> Cc: AAA Listan
> > >> >> Subject: RE: [AAA-WG]: Previous-FA-XXXX AVP
> > >> >>
> > >> >>
> > >> >> Ok, let's see if I can write the entire message this time
> > >> >> before sending it
> > >> >> :-)
> > >> >> There might be a problem with the possiblity to reuse the old
> > >> >> session id,
> > >> >> and
> > >> >> that is that there can only be one session per user. I don't
> > >> >> know if this
> > >> >> limitation
> > >> >> is to harsh.
> > >> >>
> > >> >> /Fredrik
> > >> >>
> > >> >> 11.7  Session Movement
> > >> >>
> > >> >>    When a user moves between different access devices it may
> > >> >> be desirable
> > >> >>    to keep the Session Id unchanged. It is therefore 
> > possible for a
> > >> >>    server to send the original Session Id back to the 
> > client in the
> > >> >>    Original-Session-Id AVP. An old session is identified by
> > >> >> the User Name
> > >> >>    Nai.
> > >> >>
> > >> >> 11.7.1  Original-Session-Id AVP
> > >> >>
> > >> >>    The Original-Session-Id AVP (AVP Code 261) is of type
> > >> >> OctetString and
> > >> >>    MAY be sent in a message of type Response or Answer 
> > if the AAA
> > >> >>    server already has a session identifier for the user,
> > >> and wishes to
> > >> >>    keep the existing Session-Id. All further messages from
> > >> the Access
> > >> >>    Device for this session MUST use the session identifier in
> > >> >> this AVP.
> > >> >>    This shouldn't be viewed as a new session, but rather
> > >> renaming the
> > >> >>    old session. Any message not using the Session Id in this
> > >> >> AVP will be
> > >> >>    treated as an unrecognized Session Id.
> > >> >>
> > >> >> 11.8  Session Termination
> > >> >>
> > >> >>    The Diameter Base Protocol provides a set of messages
> > >> that MUST be
> > >> >>    used by any peer to explicitly request that a previously
> > >> >>    authenticated and/or authorized session be 
> > terminated. Since the
> > >> >>    Session-Id is typically tied to a particular service (i.e.
> > >> >> Mobile IP,
> > >> >>    NASREQ, etc), the session termination messages are used
> > >> to request
> > >> >>    that the service tied to the Session Id be terminated.
> > >> >>
> > >> >>
> > >> >>
> > >> >> >>-----Original Message-----
> > >> >> >>From: [email-masked]
> > >> >> [mailto:[email-masked]]On Behalf
> > >> >> >>Of Fredrik Johansson
> > >> >> >>Sent: den 12 april 2001 10:04
> > >> >> >>To: [email-masked]; Martin Julien (ECE); Tony 
> Johansson
> > >> >> >>Cc: AAA Listan
> > >> >> >>Subject: RE: [AAA-WG]: Previous-FA-XXXX AVP
> > >> >> >>
> > >> >> >>
> > >> >> >>No, no additional AVPs is required. However, I believe some
> > >> >> explanations
> > >> >> >>should be provided on how to treat the  request in
> > >> >> different nodes. I'll
> > >> >> >>give you some text after the weekend that hopefully 
> > will give you
> > >> >> >>some ideas
> > >> >> >>what I mean. Untill then I will enjoy a couple of 
> > days skiing :-)
> > >> >> >>
> > >> >> >>/Fredrik
> > >> >> >>
> > >> >> >>>-----Original Message-----
> > >> >> >>>From: [email-masked]
> > >> >> [mailto:[email-masked]]On Behalf
> > >> >> >>>Of Patrice Calhoun
> > >> >> >>>Sent: den 11 april 2001 19:32
> > >> >> >>>To: Fredrik Johansson; Martin Julien (ECE); Tony Johansson
> > >> >> >>>Cc: AAA Listan
> > >> >> >>>Subject: RE: [AAA-WG]: Previous-FA-XXXX AVP
> > >> >> >>>
> > >> >> >>>
> > >> >> >>>and no additional protocol text (read AVPs) is required???
> > >> >> >>>
> > >> >> >>>PatC
> > >> >> >>>>>
> > >> >> >>>>>Just to make sure, I *presume* that this proposed 
> > text is to
> > >> >> >>>belong in the
> > >> >> >>>>>Mobile IP extension, right?
> > >> >> >>>>
> > >> >> >>>>Yes, that's correct
> > >> >> >>>>
> > >> >> >>>>/Fredrik
> > >> >> >>>>
> > >> >> >>>>>
> > >> >> >>>>>PatC
> > >> >> >>>>>
> > >> >> >>>>>ps: for those that saw my "I will not be responding to
> > >> >> e-mail this
> > >> >> >>>>>week", I
> > >> >> >>>>>happen to be in a city that has metricom service :)
> > >> >> >>>>>
> > >> >> >>>>>>Cool! I was about to send you something very 
> > similar to know
> > >> >> >>>>>>if it was what you meant in your previous mail.
> > >> >> >>>>>>I agree with your solution. Thanks!
> > >> >> >>>>>>
> > >> >> >>>>>>> -----Original Message-----
> > >> >> >>>>>>> From: Fredrik Johansson
> > >> >> [mailto:[email-masked]]
> > >> >> >>>>>>> Sent: Tuesday, April 10, 2001 10:27 AM
> > >> >> >>>>>>> To: Martin Julien (ECE); Tony Johansson
> > >> >> >>>>>>> Cc: 'Patrice Calhoun'; AAA Listan
> > >> >> >>>>>>> Subject: RE: [AAA-WG]: Previous-FA-XXXX AVP
> > >> >> >>>>>>>
> > >> >> >>>>>>>
> > >> >> >>>>>>> After a closer look at the problem we have a
> > >> suggestion on a
> > >> >> >>solution.
> > >> >> >>>>>>> If the AAAH always assigns a SPI that is unique in
> > >> the HA for
> > >> >> >>>>>>> the FA-HA key,
> > >> >> >>>>>>> and a SPI that is unique in the Mn for the MN-FA and
> > >> >> MN-HA keys, the
> > >> >> >>>>>>> security contexts will automatically be unique 
> > in every SA.
> > >> >> >>>>>>>
> > >> >> >>>>>>> 7.5 SPI Allocation
> > >> >> >>>>>>>   To ensure that the SPI is unique for each 
> > pair of nodes,
> > >> >> >>>>>>>   the AAAH SHOULD keep track of assigned SPIs per
> > >> HA and MN.
> > >> >> >>>>>>>   The SPI assigned to the MN-FA key MUST be 
> > allocated from
> > >> >> >>>>>>> the MN SPI pool,
> > >> >> >>>>>>>   the SPI for the FA-HA key MUST be allocated from
> > >> the HA SPI
> > >> >> >>>>>>> pool, and the
> > >> >> >>>>>>>   SPI for the MN-HA key MUST be allocated from 
> > the MN SPI
> > >> >> >>>>>>> pool. Note that
> > >> >> >>>>>>>   SPI values 0 through 255 are reserved and MUST NOT
> > >> >> be used in any
> > >> >> >>>>>>>   Mobility Security Association.
> > >> >> >>>>>>>
> > >> >> >>>>>>> /Fredrik
> > >> >> >>>>>>> >-----Original Message-----
> > >> >> >>>>>>> >From: [email-masked]
> > >> >> >>>>>>> [mailto:[email-masked]]On Behalf
> > >> >> >>>>>>> >Of Fredrik Johansson
> > >> >> >>>>>>> >Sent: den 10 april 2001 08:40
> > >> >> >>>>>>> >To: Martin Julien (ECE); Tony Johansson
> > >> >> >>>>>>> >Cc: 'Patrice Calhoun'; AAA Listan
> > >> >> >>>>>>> >Subject: RE: [AAA-WG]: Previous-FA-XXXX AVP
> > >> >> >>>>>>> >
> > >> >> >>>>>>> >
> > >> >> >>>>>>> >>
> > >> >> >>>>>>> >>> >>
> > >> >> >>>>>>> >>> >> Another thing that needs some clarification,
> > >> >> if there is a
> > >> >> >>>>>>> >>> solution. How
> > >> >> >>>>>>> >>> >> will the HA know which SA to use. In the case
> > >> >> where a mobile
> > >> >> >>>>>>> >>> >moves from one
> > >> >> >>>>>>> >>> >> Fa to another under the same administrative
> > >> >> domain it may
> > >> >> >>>>>>> >>> receive the
> > >> >> >>>>>>> >>> >> session keys for the old Fa from the 
> > AAAF. It will
> > >> >> >>then proceed
> > >> >> >>>>>>> >>> >to send the
> > >> >> >>>>>>> >>> >> mip reg req to the HA. The HA will see that
> > >> >> the message came
> > >> >> >>>>>>> >>> >from the new FA
> > >> >> >>>>>>> >>> >> and try to locate the SA shared with 
> that FA. It
> > >> >> >will not find
> > >> >> >>>>>>> >>> >it since it
> > >> >> >>>>>>> >>> >> was established with the old FA. Eventhough
> > >> >> the HA can see
> > >> >> >>>>>>> >>> the address of
> > >> >> >>>>>>> >>> >> the old Fa in the previous-fa-XXXX it is 
> > not clear
> > >> >> >that it can
> > >> >> >>>>>>> >>> >establish a
> > >> >> >>>>>>> >>> >> SA with the new Fa because it has to use
> > >> the same SPI
> > >> >> >>as before
> > >> >> >>>>>>> >>> >and that one
> > >> >> >>>>>>> >>> >> might be busy. Or have I missed something here?
> > >> >> >>>>>>> >>> >
> > >> >> >>>>>>> >>> >You also have the user NAI in the MIP 
> registration
> > >> >> >>>>>>> request sent to
> > >> >> >>>>>>> >>> >the HA and
> > >> >> >>>>>>> >>> >the user NAI is globally unique....
> > >> >> >>>>>>> >>>
> > >> >> >>>>>>> >>> Yes, but this is not the security association
> > >> >> shared with the
> > >> >> >>>>>>> >>> mobile node
> > >> >> >>>>>>> >>> but the one shared between the FA and HA, thus
> > >> >> has nothing to
> > >> >> >>>>>>> >>> do with the
> > >> >> >>>>>>> >>> user.
> > >> >> >>>>>>> >>
> > >> >> >>>>>>> >>I think you are assuming that there exists only
> > >> 1 mobility
> > >> >> >>>>>>> SA between
> > >> >> >>>>>>> >>a FA and a HA for all the MIP sessions, right?
> > >> >> >>>>>>> >
> > >> >> >>>>>>> >YES, one mobility SA, ceveral security context
> > >> >> within a mobility
> > >> >> >>>>>>> >SA. See rfc
> > >> >> >>>>>>> >2002,
> > >> >> >>>>>>> >
> > >> >> >>>>>>> >"Mobility Security Association
> > >> >> >>>>>>> >               A collection of security contexts,
> > >> >> between a pair
> > >> >> >>>>>>> >               of nodes, which may be applied to
> > >> >> Mobile IP protocol
> > >> >> >>>>>>> >               messages exchanged between them.  Each
> > >> >> >>>>>>> context indicates
> > >> >> >>>>>>> >               an authentication algorithm and mode
> > >> >> >(Section 5.1), a
> > >> >> >>>>>>> >               secret (a shared key, or appropriate
> > >> >> public/private
> > >> >> >>>>>>> >               key pair), and a style of replay
> > >> >> protection in use
> > >> >> >>>>>>> >               (Section 5.6)."
> > >> >> >>>>>>> >
> > >> >> >>>>>>> >Each context is indexed with a unique SPI within
> > >> that SA, if
> > >> >> >>>>>>> there exist a
> > >> >> >>>>>>> >SA between the HA and the old FA and one SA 
> > between the HA
> > >> >> >>>>>>> and the new FA
> > >> >> >>>>>>> >there might exist security context with the same
> > >> SPI in both
> > >> >> >>>>>>> of these.
> > >> >> >>>>>>> >
> > >> >> >>>>>>> >"Security Parameter Index (SPI)
> > >> >> >>>>>>> >               An index identifying a 
> security context
> > >> >> >>between a pair
> > >> >> >>>>>>> >               of nodes among the contexts 
> available in
> > >> >> >the Mobility
> > >> >> >>>>>>> >               Security Association.  SPI values 0
> > >> >> through 255 are
> > >> >> >>>>>>> >               reserved and MUST NOT be used in any
> > >> >> >>Mobility Security
> > >> >> >>>>>>> >               Association."
> > >> >> >>>>>>> >
> > >> >> >>>>>>> >>When a first AMA is received
> > >> >> >>>>>>> >
> > >> >> >>>>>>> >I guess you mean AMR :-)
> > >> >> >>>>>>> >
> > >> >> >>>>>>> >>in the AAAH from a MN, is the AAAH supposed to
> > >> issue a new
> > >> >> >>>>>>> registration
> > >> >> >>>>>>> >>FA-HA key, in the case the HA is in the home 
> > domain? The
> > >> >> >>>>>>> spec says "yes",
> > >> >> >>>>>>> >>if it is required by the MN. However, how can 
> > the MN know
> > >> >> >about the
> > >> >> >>>>>>> >>mobility SA between the FA and the HA? I guess
> > >> it can not,
> > >> >> >>>>>>> which means
> > >> >> >>>>>>> >>that it will ask for a new key, which should be
> > >> transferred
> > >> >> >>>>>>> to the FA and
> > >> >> >>>>>>> >>the HA from the AAAH. Is there a way for the HA to
> > >> >> notify the AAAH
> > >> >> >>>>>>> >>that it does not need
> > >> >> >>>>>>> >>a new key and a new SPI for its mobility SA with
> > >> >> the FA, since it
> > >> >> >>>>>>> >>already has one? I guess
> > >> >> >>>>>>> >>not, right? Then, it looks like your idea 
> > could be very
> > >> >> >>>>>>> interesting, but
> > >> >> >>>>>>> >>I don't know how to deal with it using Diameter,
> > >> unless the
> > >> >> >>>>>>> AAAH and AAAF
> > >> >> >>>>>>> >>would keep a list of mobility SAs between 
> > each FA and HA.
> > >> >> >>>>>>> >
> > >> >> >>>>>>> >In some way the AAAH must keep track of what 
> > SPIs it has
> > >> >> >>>>>>> assigned to the
> > >> >> >>>>>>> >home agent, if it does it per SA or make the SPI
> > >> >> unique over all
> > >> >> >>>>>>> >SA's in the
> > >> >> >>>>>>> >HA is up to the implementation
> > >> >> >>>>>>> >
> > >> >> >>>>>>> >>
> > >> >> >>>>>>> >>> You can not guarantee that a security between
> > >> the HA and
> > >> >> >>>>>>> the old FA is
> > >> >> >>>>>>> >>> unique between the HA and the new FA. The same
> > >> SPI must be
> > >> >> >>>>>>> >>> used in the first
> > >> >> >>>>>>> >>> request in order for the HA to be able to
> > >> >> distinguise between
> > >> >> >>>>>>> >>> different
> > >> >> >>>>>>> >>> security contexts it shares with the FA. What we
> > >> >> can do is to
> > >> >> >>>>>>> >>> have the new
> > >> >> >>>>>>> >>> FA add a <MIP-Preferred-SPI Ext> in the first
> > >> request from
> > >> >> >>>>>>> >>> the new FA to the
> > >> >> >>>>>>> >>> HA, the HA can then use the <Previous-FA-XXXX
> > >> >> Ext> together
> > >> >> >>>>>>> >>> with the old SPI
> > >> >> >>>>>>> >>> to retreive the context and store it under the
> > >> >> Preferred SPI
> > >> >> >>>>>>> >>> under the SA
> > >> >> >>>>>>> >>> with the new FA.
> > >> >> >>>>>>> >>
> > >> >> >>>>>>> >>I was wondering whether or not a mobility SA 
> > between a FA
> > >> >> >>>>>>> >>and a HA was based on a particular MIP session? My
> > >> >> understanding
> > >> >> >>>>>>> >>_IS_ that an existing SA is based on a MIP session.
> > >> >> That means
> > >> >> >>>>>>> >>that between a FA and a HA, there exists several
> > >> >> mobility SAs
> > >> >> >>>>>>> >>depending on each MIP session.
> > >> >> >>>>>>> >
> > >> >> >>>>>>> >No, there is only one SA between two nodes, 
> > but there are
> > >> >> >>>>>>> several security
> > >> >> >>>>>>> >context within each SA. Each security context can
> > >> >> >>>>>>> corresponde to a mip
> > >> >> >>>>>>> >session. It is the security context that has a
> > >> lifetime, the
> > >> >> >>>>>>> SA can be
> > >> >> >>>>>>> >removed when the last security context is removed.
> > >> >> >>>>>>> >
> > >> >> >>>>>>> >>By MIP session, I mean an AAA
> > >> >> >>>>>>> >>authorized session for MIP. The SPI is already
> > >> >> included in the
> > >> >> >>>>>>> >>key transferred between the AAAF and the new FA.
> > >> I don't see
> > >> >> >>>>>>> >>why a HA could not use the SPI stored under its
> > >> MN User-Name
> > >> >> >>>>>>> >>state to retrieve the mobility SA between the new
> > >> >> FA and itself?
> > >> >> >>>>>>> >
> > >> >> >>>>>>> >Because the SA between the FA and HA does not realy
> > >> >> have anything
> > >> >> >>>>>>> >to do with
> > >> >> >>>>>>> >the Mn. It is something setup between the FA 
> > and HA. Thus
> > >> >> >>>>>>> when the HA will
> > >> >> >>>>>>> >look for the key to use it will do the lookup on the
> > >> >> FA address.
> > >> >> >>>>>>> >
> > >> >> >>>>>>> >/Fredrik
> > >> >> >>>>>>> >
> > >> >> >>>>>>> >>
> > >> >> >>>>>>> >>Regards,
> > >> >> >>>>>>> >>Martin
> > >> >> >>>>>>> >
> > >> >> >>>>>>>
> > >> >> >>>>>
> > >> >> >>>>>
> > >> >> >>>
> > >> >> >>>
> > >> >> >>
> > >> >> >
> > >> >>
> > >>
> > 
>

---

From: "Fredrik Johansson" <[email-masked]>
Date: Thu, 19 Apr 2001 10:07:46 +0200

>
>Hi Fredrik,
>
>I realized that in my previous e-mail, I had diverged from my
>original thoughts while writing it, which seems now to be a better
>understanding of the problem than my previous suggestion.
>
>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 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...

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