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

From: "Martin Julien (ECE)" <[email-masked]>
Date: Tue, 17 Apr 2001 16:28:03 +0200

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: Tue, 17 Apr 2001 16:53:23 +0200

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