Subject: [AAA-WG]: Issue 317:FA-HA Key

From: Tony Johansson <[email-masked]>
Date: Mon, 01 Apr 2002 14:21:15 -0800

Hello Siva and All,

How about the following clarification:

change:

"If the FA's local policy allows it to receive AAA session Keys, and
it does not have any existing keys with the HA, it MAY set the
FA-HA-Key-Request flag".

to:

"If the FA's local policy allows it to receive AAA session Keys, and
it does not have any existing FA-HA key with the HA, the FA MAY set the
FA-HA-Key-Request flag"

I hope this makes it more explicit.

And to your question below;  - "In other words, is the FA-HA key session
specific or not?"

I guess you can use the same FA-HA key for multiple session, but I would
say this is implementation specific if you use one FA-HA key per session
or not, and should NOT be stated in the spec. Furthermore, since we only
have one key lifetime per session, you better be careful if you use the
same FA-HA key for multiple session....

/Tony

Issue 317:FA-HA Key
Submitter Name: Siva Ramamurthy
Submitter email address: [email-masked]
Date first submitter: 3/27/2002
Document: Mobile IP
Comment Type: T
Priority: 1
Section: 4.5

Explanation of Issue:

Section 4.5 has text that says:

"If the FA's local policy allows it to receive AAA session Keys, and
it does not have any existing keys with the HA, it MAY set the
FA-HA-Key-Request flag".

the co-existance of the phrases "any existing keys" and "AAA session
keys" is confusing! Is the FA-HA key to be used only for the session
from which it was obtained, or can it be used with any other sessions
that require communciation between this FA and HA? In other words, is
the FA-HA key session specific or not?

Requested Change:
Please clarify, since different implementations at the FA and HA can
lead to needless FOR_HOME authentication failures.

---

From: Joe Lau <[email-masked]>
Date: Mon, 1 Apr 2002 14:50:18 -0800 (PST)

Tony,

> or not, and should NOT be stated in the spec. 

If we don't state whethter the FA-HA key is session specific or not,
won't there may be potential interoperability problem between FA 
(from vendor A) and HA (from vendor B)?

Regards,

Joe Lau

---

From: Tony Johansson <[email-masked]>
Date: Mon, 01 Apr 2002 16:08:34 -0800

Why would it be interpretability problems ?

/Tony

Joe Lau wrote:

>
>
> This message uses a character set that is not supported by the
> Internet Service.  To view the original message content,  open the
> attached message. If the text doesn't display correctly, save the
> attachment to disk, and then open it using a viewer that can display
> the original character set. <<message.txt>>

---

From: Sivasundar Ramamurthy <[email-masked]>
Date: Mon, 1 Apr 2002 16:34:26 -0800 (PST)

Hello Tony,

> Why would it be interpretability problems ?
 
If the HA and FA folllow different implementations, there might be
unnecessary authentication failures. Consider the case when the FA   
keeps one FA-HA key per session, and the HA keeps one key per FA and 
uses it for all sessions. If there are multiple MNs of that HA
visiting the FA, re-registrations of some MN's may result in in FA-HA
authentication failures -- FA is using the key from a specific
session, while the HA's "global" key to that FA is obtained from a HAR
from another session.

Siva

---

From: Joe Lau <[email-masked]>
Date: Mon, 1 Apr 2002 16:44:08 -0800 (PST)

Tony,

> Why would it be interpretability problems ?

Let's say FA (from vendor A) implemented session-specific FA-HA key 
and the HA (from vendor B) implemented "global" FA-HA key.  Two MNs
from the HA visisted the FA's foreign network.  The FA requested a
separate FA-HA key from the AAAH for each MN's session.   Yet, the HA 
simply uses the latest FA-HA key generated by the AAAH.  Under this
circumstance, one of the MN's registration request will fail the FA-HA
authentication due mismatch of FA-HA key.  Won't it?

Regards,

Joe

---

From: Tony Johansson <[email-masked]>
Date: Mon, 01 Apr 2002 17:17:22 -0800

But each FA-HA key also has SPI, which helps out to identify the key.
Thus, when a HA receives a  MIP RRQ from the FA, the HA must identify the
the right FA-HA key to be used by looking at the received FA-HA SPI in the
FA-HA auth.

/Tony

---

From: Sivasundar Ramamurthy <[email-masked]>
Date: Tue, 2 Apr 2002 08:56:39 -0800 (PST)

Hello Tony,

> the right FA-HA key to be used by looking at the received FA-HA SPI in the

What I think you are saying is that the HA maintains multiple HA-FA
keys (one for each session?), but can expect the FA to use any of
those keys. The HA authenticates the FA by selecting the key that
matches the SPI used by the FA, even if the key is from a different
session. And in order to make this work, the HA needs to make sure
that each session key has a unique SPI.

This is different from the two implementations I was referring in my
original email:

1. The HA implementation maintains only one key to the FA. Everytime
it get a new key to the FA, it will refresh the existing key (if any)
and assign the same SPI to the new key. This is the only key that will
be used for all communication between the FA and HA. (corresponds to
"any key")

2. The FA implementation maintains HA-FA key for each session, which
is the one and only key that can be used for any communication between
the FA and HA for that session -- the FA will expect the authenticator
from the HA to have been created only using that session's key (and
SPI). (corresponds to "session key"). 

I dont think there is anything in the draft that says that the above
two interpretations are wrong. Even if it may seem that "multiple
HA-FA keys indexed by SPI" is the correct way to do it, I feel that it
is better if we can make certain issues non-implementation specific to
eliminate chances of unnecessary HA-FA authentication failures.

thanks,

Siva

> > session, while the HA's "global" key to that FA is obtained from a HAR

Thanks,

Siva

====================================
Sivasundar Ramamurthy		
(She-va-su-ndar Ra-ma-moor-thee)

Engineer, Mobile IP Project
Hewlett Packard
(408) 447 7255
====================================

---

From: Tony Johansson <[email-masked]>
Date: Tue, 02 Apr 2002 14:24:59 -0800

Siva and All,

What you explain below can not happen unless you have a broken implementation...

You can not simply change the SPI value in the HA without also making sure that
the FA gets the same SPI for the same key.

With the clarification in section 4.5 below:

change:

to:

To me this is explicit enough, thus the FA  may request one FA-HA key per
session or use the same FA-HA key for multiple session, and since each FA-HA key
has a unique SPI the FA and HA can easily identify which key to be use when
authenticating the FA-HA auth extension in the MIP RRQ. However, I strongly
believe how you choose to request and assign FA-HA keys is implementation
specific and I don't think we need to say more then my suggested clarification
above, and be done with this issue.

What do others think?

/Tony

---

From: "Fredrik Johansson" <[email-masked]>
Date: Thu, 4 Apr 2002 09:16:16 +0200

Hi Sivasundar,

Please see comments inline.

/Fredrik

>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]]On Behalf Of
>Sivasundar Ramamurthy
>Sent: den 2 april 2002 18:57
>To: Tony Johansson
>Cc: Joe Lau; AAA Working Group
>Subject: Re: [AAA-WG]: Issue 317:FA-HA Key
>
>
>
>Hello Tony,
>

But this is a illegal behavior, what if the message distributing the keys to
the FA gets lost on its way? Consider the case where the HA receives a new
key for the FA and refreshes the existing key and assigns the same SPI (as
you indicate) to the new key. If the FA does not receive the new key it will
try to use the old key which still might be valid since it should request
new keys sometime before the old one expires. When the request reaches the
HA it will check what key to use by looking at the SPI, the HA will now take
the new key since it has already replaced the old one, i.e. you get an
authentication failure just beacause the HA replaced the key for that SPI.

>SPI). (corresponds to "session key").

The FA-HA keys does not have anything todo with the session, the session
might just be the one that distributes the key. A Security Association is
between a pair of nodes. When the FA should authenticate a mip msg it looks
at the SPI to find a Security Context within the Mobility Security
Association that exists between the FA and the node that sent the message.
It may very well be so that every session adds a new Security Context to the
Mobility Security Association, but they are all valid for any session
between these nodes. Each Context may have a lifetime similar to that of the
session that added it, but there is nothing in the context that tells the FA
which session that added it.

If one would like to limit the number of keys held at the FA, one can
implement a scheme where the FA doesn't request keys to be distributed if it
has valid keys. This will be more complex since one has to take care of the
case where the new session last longer than the existing keys.
>two interpretations are wrong. Even if it may seem that "multiple

Nope, not in the Diameter drafts, but the use is in Mobile IP, Diameter is
just used for distribution.

---

From: Sivasundar Ramamurthy <[email-masked]>
Date: Thu, 4 Apr 2002 08:41:02 -0800 (PST)

Hi Fredrick,

> authentication failure just beacause the HA replaced the key for that SPI.

true.

> which session that added it.

This IS more in line with base Mobile IP. However, if the FA-HA key
does not have anything to do with the session, then it seems like the
key-lifetime rule wrt termination of session (section 6.13) may not be
applicable to it!!

Anyway, greatly appreciate your detailed clarification here. 

Siva

---

From: "Fredrik Johansson" <[email-masked]>
Date: Fri, 5 Apr 2002 09:52:32 +0200

Hi Sivasundar,

>From: Sivasundar Ramamurthy [mailto:[email-masked]]
>Sent: den 4 april 2002 18:41
>To: Fredrik Johansson
>Cc: Tony Johansson; Joe Lau; AAA Working Group
>Subject: RE: [AAA-WG]: Issue 317:FA-HA Key
>
>
>
>Hi Fredrick,
>
>

I interpret section 6.13 as follows.
You can't use the key after the lifetime has expired (which is reasonable)
If the key expires while the session is still active, you must either renew
the key or terminate the session. And it's not so strange, if you don't
renew the key you will not be able to re-register, thus the session will be
terminated. So I can't really see what not applicable with section 6.13. But
please tell me if I misunderstood you.

/Fredrik

---

From: Sivasundar Ramamurthy <[email-masked]>
Date: Fri, 5 Apr 2002 09:44:09 -0800 (PST)

Hi Fredrick,

> please tell me if I misunderstood you.

Ok. From all these discussions, this is how I think the HA-FA was
meant to be used/created:

1. Each session can have a HA-FA key but any of them can be used by
the FA/HA irrespective of the session (since HA-FA key is NOT session
specific)

2. Each HA-FA session key must have a different SPI (to enable proper
auth since  FA-HA keys from other sessions can be used).

3. When a HA-FA session key is renewed, the new key must be given the
same SPI. (This will allow the session termination rule from section
6.13 to apply to the HA-FA key.)

If I am correct, then, IMHO, the draft should at least say something
about maintaining a unique SPI for each session key and that usage of
the HA-FA key is not restricted to that session.

thanks,

Siva

---

From: Tony Johansson <[email-masked]>
Date: Fri, 05 Apr 2002 11:34:07 -0800

Hi Siva,

> the FA/HA irrespective of the session (since HA-FA key is NOT session

Right.

> auth since  FA-HA keys from other sessions can be used).

Right. Section 5.0 - "The SPI values are used as key identifiers, meaning that
each session key has its own SPI value; nodes that share a key also share an SPI".

> 6.13 to apply to the HA-FA key.)

The HA has the control and responsibility of allocating the FA-HA SPI, section 5.0
- "The Mobile Node proposes SPIs for use in computing the Mobile-Foreign and
Mobile-Home authentication extensions, via the Mobile IP AAA Key Request
extensions [MIPKEYS], while the Home Agent allocates the Mobile-Foreign,
Mobile-Home and Foreign-Home SPIs."

> the HA-FA key is not restricted to that session.

As pointed out above the HA has the responsiblitity of allocating the SPI, so the
HA can  make sure that each FA-HA key has its an own SIP value.
IMHO, the SIP handling described in section 5.0 and 6.0 in the Diameter MIPv4 appl
plus [MIPKEYS] is clear and good enough.

/Tony

---

From: Sivasundar Ramamurthy <[email-masked]>
Date: Fri, 5 Apr 2002 14:54:55 -0800 (PST)

Hi Fredrick,

I am still trying to figure this out so please bear with me. :-)

> > please tell me if I misunderstood you.

But if the FA can use HA-FA keys from other sessions, re-registration
on a particular session can succeed even if the HA-FA key for that
session expires! So why should the session terminate even when
re-registration can succeed?

Does that then mean that if the FA requests a FA-HA session key, it
must renew it to keep the session alive, even if it does not want to
use the key?

thanks,

Siva

---

From: "Fredrik Johansson" <[email-masked]>
Date: Mon, 8 Apr 2002 10:27:18 +0200

>Sent: den 5 april 2002 19:44
>To: Fredrik Johansson

Correct.

>auth since  FA-HA keys from other sessions can be used).

Correct

>6.13 to apply to the HA-FA key.)

No, it must be given a new unique SPI, you can see it as the old key has
expired and a new one is distributed to replace it.

/Fredrik

---

From: "Fredrik Johansson" <[email-masked]>
Date: Mon, 8 Apr 2002 10:26:46 +0200

Hi Siva,

>Sent: den 6 april 2002 00:55
>To: Fredrik Johansson

No problem, we need to get all issues cleared so we can get the drafts
through iesg, so if I can help answer your questions I'm glad to help

>must renew it to keep the session alive, even if it does not want to

No, you're right, as long as the FA has one key that it can use it doesn't
have to renew the key that it received for that particular session.

/Fredrik