Subject: [MOBILE-IP] challenge / response; MN auth timeout

From: Tomas Goldbeck-Löwe (ERA)<[email-masked]>
Date: Sat, 22 Jan 2000 02:40:10 +0100

Hi all,

(when I write SA below, I mean the security association between the MN and the FA)

I have some comments in the challenge response draft about which auth extension to include in the Reg Request from the MN.
In chapter 3.1 of the draft there is a lot about "if the mobile node does not have a security association with the FA...." and "if the mobile node has a security association with the FA...." in order to decide which auth extension to include in the Reg Request.
My concern is how the MN does know if it has a VALID security association. I think this is a more appropriate question than if it just do have a SA or not. A security association that is not valid will be rejected by the FA anyway.

The FA knows if the SA is valid or not, since it received a timeout together with the SA from the AAA. The problem seams to be that the FA can not forward this timeout to the MN.

I am aware that there is a proposal in the draft about MobileIP Diameter Requirements that says that the timeout for the keys must be an integer multiple of the registration lifetime offered by the FA to the MN. But I don't see how this solves the problem, since (a) the HA can give the MN an other lifetime than the one offered by the FA and (b) all we know from rfc2002 is that the MN will re-register when the lifetime is near to expire. (not _exactly_ when it re-registers)

As I see it, there are four different ways to solve this (someone can probably come up with another one)
1) Add an extension to the Reg Reply to let the FA forward the SA timeout to the MN. This will make it possible for the MN to include the correct auth extension in the following Reg Requests. However, more extensions means larger messages to the MN which, in a cellular environment, are connected over an air interface.
2) Include a "SA lifetime" in the session key extensions in the AAA Keys draft (draft-calhoun-mobileip-aaa-key-00.txt). By including the information in an existing extension, we will not extend the Reg Reply even more. (they are already quite large)
3) Add a rule for the MN Reg Request procedure. If the MN gets a Reg Reply with code BAD_AUTHENTICATION, the MN SHOULD include the MN-AAA auth in the next Reg Request. This will mean some extra delay, since the first Reg Request will be rejected.
4) Both the MN-FA and the MN-AAA auth extension is included in the RegRequest. Then the FA can take the correct action since it kows if the SA are valid or not. The draft does not exclude this today. To include both keys is also mentioned in the MN AAA Keys draft. However, this means more processing for the MN and that there always will be one auth extension in the RegRequest that is not used. To me, that doesn't sound good from a security point of view...

If we don't specify a solution to this, we can end up in a deadlock situation where the MN tries to register with the (invalid) SA which always will be rejected by the FA.

Personally I'm in favor of option 2, alternatively option 1, with option 3 as "backup".
However, including the timeout in the AAA key extensions will result in changes to another draft, which might have impact on the challenge response draft last call procedure.
My suggestion is that we include the timeout in the AAA Keys draft (option 2) and add the extra rule for the MN (option 3) as optional (SHOULD) in the draft. 

Regards,

        --> Tomas

_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ 
 Tomas Goldbeck-Löwe                ph. +1 650 463 6138
 Ericsson Inc.                               mobile. +1 510 305 6109
 1555 Adams Drive                      fax. +1 650 463 6851
 Menlo Park, CA 94025
                              [email-masked]
_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ 

> -----Original Message-----
> From:>        Basavaraj Patil [SMTP:[email-masked]]
> Sent: Thursday, January 13, 2000 8:16 AM
> To:   [email-masked]
> Subject:      [MOBILE-IP] WG Last Call (draft-ietf-mobileip-challenge-08.txt)
> 
> 
> Mobile IP Challenge/Response Extensions draft 
> (draft-ietf-mobileip-challenge-08.txt) has undergone a couple of 
> revisions since the previous WG last call. As a result we are sending out 
> another WG last call on this I-D. Please provide comments and feedback 
> within the next two weeks. 
> 
> WG last call issued on: Jan 13, 2000 
> 
> Regards, 
> Basavaraj 
> Phil 
>

---

From: Yoshiyuki Tsuda <[email-masked]>
Date: Sat, 22 Jan 2000 12:56:32 +0900

Hello, Tomas and Pat,

 My comment is attached at the end of this email:

On Sat, 22 Jan 2000 02:40:10 +0100,  Tomas_Goldbeck wrote:
>> I have some comments in the challenge response draft about which auth extension
>> to include in the Reg Request from the MN.
>> In chapter 3.1 of the draft there is a lot about "if the mobile node does not
>> have a security association with the FA...." and "if the mobile node has a
>> security association with the FA...." in order to decide which auth extension
>> to include in the Reg Request.
>> My concern is how the MN does know if it has a VALID security association. I
>> think this is a more appropriate question than if it just do have a SA or not.
>> A security association that is not valid will be rejected by the FA anyway.
>>
>> The FA knows if the SA is valid or not, since it received a timeout together
>> with the SA from the AAA. The problem seams to be that the FA can not forward
>> this timeout to the MN.
>>
>> I am aware that there is a proposal in the draft about MobileIP Diameter
>> Requirements that says that the timeout for the keys must be an integer multiple
>> of the registration lifetime offered by the FA to the MN. But I don't see how
>> this solves the problem, since (a) the HA can give the MN an other lifetime than
>> the one offered by the FA and (b) all we know from rfc2002 is that the MN will
>> re-register when the lifetime is near to expire. (not _exactly_ when it re-registers)
>>
>>
>> 1) Add an extension to the Reg Reply to let the FA forward the SA timeout to
>>    the MN. This will make it possible for the MN to include the correct auth
>>    extension in the following Reg Requests. However, more extensions means
>>    larger messages to the MN which, in a cellular environment, are connected
>>    over an air interface.
>> 2) Include a "SA lifetime" in the session key extensions in the AAA Keys draft
>>    (draft-calhoun-mobileip-aaa-key-00.txt). By including the information in an
>>     existing extension, we will not extend the Reg Reply even more. (they are
>>     already quite large)
>> 3) Add a rule for the MN Reg Request procedure. If the MN gets a Reg Reply
>>    with code BAD_AUTHENTICATION, the MN SHOULD include the MN-AAA auth in the
>>    next Reg Request. This will mean some extra delay, since the first Reg
>>    Request will be rejected.
>> 4) Both the MN-FA and the MN-AAA auth extension is included in the RegRequest.
>>    Then the FA can take the correct action since it kows if the SA are valid
>>    or not. The draft does not exclude this today. To include both keys is also
>>    mentioned in the MN AAA Keys draft. However, this means more processing for
>>    the MN and that there always will be one auth extension in the RegRequest
>>    that is not used. To me, that doesn't sound good from a security point of
>>>   view...
>>
>> If we don't specify a solution to this, we can end up in a deadlock situation
>> where the MN tries to register with the (invalid) SA which always will be
>> rejected by the FA.
>>
>> However, including the timeout in the AAA key extensions will result in
>> changes to another draft, which might have impact on the challenge response
>> draft last call procedure.
>> My suggestion is that we include the timeout in the AAA Keys draft (option 2)
>> and add the extra rule for the MN (option 3) as optional (SHOULD) in the draft.

 Your proposal may improve the protocol.  But, there is another way,
 although it's similar to your option 3:

 An MN can get a hint of the FA key expiration.  Because, the life time,
 which an MN received in the last registration reply before the FA key
 expiration, ends at the same time when the previous life time will expire.
 Thus, the MN can send another registration request to the FA with a Mobile
 Node NAI extension and a MN-AAA authentication extension.

 I agree with you; I also couldn't find the exact description about this
 issue in drafts.  I think, an explicit description will improve the drafts.
 Or, am I missing a draft about this issue ?

Cheers.
-Yoshi

---

From: "Charles E. Perkins" <[email-masked]>
Date: Sat, 22 Jan 2000 10:29:22 -0800

Hello Tomas,

>>  ==   Tomas Goldbeck-Löwe

>> My concern is how the MN does know if it has a VALID security association.

I think that your only concern about validity is whether the association
has timed out.  Am I right?

>> The FA knows if the SA is valid or not, since it received a timeout
>> together with the SA from the AAA. The problem seams to be that the FA
>> can not forward this timeout to the MN.

This is not a concern for the FA Challenge draft, since there is
no key distribution specified in that draft.  So, I do not think
that draft should be delayed.  We can independently continue to search
for a resolution to the problem you have raised.

>> Requirements that says that the timeout for the keys must be an integer
>> multiple of the registration lifetime offered by the FA to the MN.
>> But I don't see how this solves the problem   ...

I agree that the Mobile-IP DIAMETER extensions draft may need to be
reconsidered.  Perhaps it is appropriate to add a lifetime to the
key extensions.

Furthermore, I am currently in the process of revising the
Registration Key draft (draft-ietf-mobileip-regkey-00.txt).
The new draft will feature a Generalized Registration Key Reply
extension.  I think it is appropriate to make the extensions of
the AAA keys draft into subtypes of the generalized extension,
and I expect to write that up soon, unless further discussion
indicates otherwise.

Relevant to this discussion, I would then expect that there
should be _two_ kinds of Generalized Key Reply extensions.
One would have a "lifetime" field, and the other would not.
The current Registration Key draft does not specify any lifetime
for the keys.  Up until now, the thought seems to be that a
Registration Key should be valid until the foreign agent uses
it to make a smooth handover to a new care-of address.

I would very much like to get comments on the advisability of
allowing both variants.  Perhaps Registration Keys should _always_
last for as long as the mobile node continues to reregister the
same care-of address.  Alternatively, perhaps Registration Keys
should _always_ come along with a timeout parameter.  Unless I
hear otherwise, I will continue to allow for both possibilities
with all of the existing key reply extension subtypes.

Some other more minor comments:

>> 1) Add an extension to the Reg Reply to let the FA forward the SA timeout
>>    to the MN. This will make it possible for the MN to include the correct
>>    auth extension in the following Reg Requests. However, more extensions
>>    means larger messages to the MN which, in a cellular environment, are
>>    connected over an air interface.
>> 2) Include a "SA lifetime" in the session key extensions in the AAA Keys
>>    draft (draft-calhoun-mobileip-aaa-key-00.txt). By including the
>>    information in an existing extension, we will not extend the Reg
>>    Reply even more. (they are already quite large)
>>    with code BAD_AUTHENTICATION, the MN SHOULD include the MN-AAA auth in
>>    the next Reg Request. This will mean some extra delay, since the first
>>    Reg Request will be rejected.
>> 4) Both the MN-FA and the MN-AAA auth extension is included in the
>>    RegRequest. Then the FA can take the correct action since it kows if
>>    the SA are valid or not. The draft does not exclude this today.
>>    To include both keys is also mentioned in the MN AAA Keys draft.
>>    However, this means more processing for the MN and that there always
>>    will be one auth extension in the RegRequest that is not used. To me,
>>    that doesn't sound good from a security point of view...
>>

I think I substantially agree with this, with the interpretation that
(2) can be managed by adding a lifetime field to the Registration Key
Reply extension as in draft-ietf-mobileip-regkey-00.txt, and that a
key that arrives with no lifetime is good as long as the mobile node
continues to use the same care-of address.

>> draft last call procedure.   My suggestion is that we include the timeout
>> in the AAA Keys draft (option 2) and add the extra rule for the MN
>> (option 3) as optional (SHOULD) in the draft.

Your suggestion doesn't have to be considered a "rule".  It can
be considered a clarification and a suggested procedure to overcome
a particular failure.  A mobile node could avoid using
the suggested procedure and still interoperate with foreign
agents that perform as specified; the downside would be that
it would not be able to register if it did not make use of
one of its existing security associations (namely, that with
its home AAA server).

I think I can speak for Pat that we will await further comment before
including this clarification into a new Challenge draft.

Regards,
Charlie P.

---

From: "Charles E. Perkins" <[email-masked]>
Date: Sat, 22 Jan 2000 10:35:32 -0800

>  Or, am I missing a draft about this issue ?

I think it has always been the intention to allow a security association
between a mobile node and a foreign agent to survive (i.e., last longer
than) individual Mobile IP registration timeouts.  Thus I don't
understand
your comments in the first paragraph above.  Can you say more about the
explicit description that is needed?

Regards,
Charlie P.

---

From: Tomas Goldbeck-Löwe<[email-masked]>
Date: Sat, 22 Jan 2000 15:23:44 -0800

Hi Charlie,

> == Charles E. Perkins

> has timed out.  Am I right?

Yes, I guess that is another way to say it.
It seams that we agree that the MN need to know if the keys are valid or
not.

> for a resolution to the problem you have raised.

I fully agree that the timeout of the keys better belong in the draft
which specifies key distribution. Just as long as the timeout also is
sent to the MN.

> and I expect to write that up soon, unless further discussion

I couldn't find the Registration Key draft on the ietf homepage. And the
link from your page isn't valid any more  :-(

> it to make a smooth handover to a new care-of address.
I'm not really sure that I follow you here.
Do you mean that as long as a MN is registered at the same FA the key is
always valid? And when the MN moves to a new FA, it will get new keys
from the home AAA server. This means that there are no timeout for the
keys, moving means getting new keys.

> one of its existing security associations (namely, that with
Agree.
I think my "optional rule" is the same as your "clarification and a
suggested prodedure".

Regards,
        --> Tomas

---

From: Yoshiyuki Tsuda <[email-masked]>
Date: Mon, 24 Jan 2000 14:33:34 +0900

Hello, Charlie,

 I attached a more explicit description; I'm sorry my comment itself wasn't
 explicit:

>> explicit description that is needed?

 Here is a figure about life times, and so on:

 |-----------------Tsa-----------------------|
                      t-prev                t-expire
                       |--------Tprev--------|

                                  t-req
                                   |--------Treq--------|
                                    t-last
                                   |--Tlast--|

 "Tsa" is a life time about a security association between an MN and
 an FA, also between an MN and an HA.  At t-prev, the MN received the
 previous registration reply from the FA, whose life time is "Tprev".
 Both Tsa and Tprev will expire at "t-expire".
 At "t-req", the MN sends a registration request whose life time is
 "Treq".  Then, the MN receives a registration reply at "t-last", but
 its accepted life time is "Tlast".  Although the MN doesn't know Tsa
 will expire at t-expire, the MN gets a hint about it by that both Tprev
 and Tlast will expire at(or about) t-expire.  By this hint, I think,
 the MN may be able to send a registration request with a Mobile Node
 NAI extension and a MN-AAA authentication extension.

Thanks.
-Yoshi