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

From: Patrice Calhoun <[email-masked]>
Date: Mon, 24 Jan 2000 10:04:26 -0800

>Hi Pat,
>
>Patrice Calhoun wrote:
>>
>> >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)
>>
>> The DIAMETER extension doesn't work in the method you described. The
>> lifetime returned is the expiration time, in a format consistent
>> with NTP time. It is up to the Mobile Node to determine whether it should
>> request new keying information, by including the MN-AAA authentication
>> extension in the registration request.
>>
>That's just my point, we can not use the DIAMETER extension.

I believe that "DIAMETER be itself" is what you meant, right? This draft
was intended to be used with the draft you refer to in option 2 below
since the mobile node does not talk directly to the DIAMETER infrastructure,
and therefore must be the keying material through Mobile IP.

>
>My point is simply that when we distribute keys to the Mobile Node with
>ANY protocol (DIAMETER or whatever), we also include a lifetime for the
>key in the same extension. That will make it possible for the Mobile
>Node to choose between the MN-FA or the MN-AAA authentication
>extensions.

So, the AAA protocol is not the issue here, right? We simply need to be
able to provide the keying material to the Mobile Node, and the keys
MUST have an explicit expiration time.

>
>
>> >
>> >
>> >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.
>>
>> I would agree that the two options you described above are the logical
>choices.
>> #2 is the best way, and #3 provides the safeguard. However, my assumption
>> was that code 67, defined in RFC 2002, could be used for this purpose. Since
>> a code already exists for the Foreign Agent to communicate with the Foreign
>> Agent that the authentication has failed, why should this document define
>> a new one?
>>
>Does the draft really specifiy a new error code?
>BAD_AUTHENTICATION is defined as code 67 in the challenge response
>draft.
>And in rfc2002, error code 67 is defined as "mobile node failed
>authentication".
>My understading was that these were the same. Am I missing something?

you are correct. They are one and the same. I now understand that you were just
asking for specific text to be added to the draft, not a new error code.

PatC

>
>Regards,
>       --> Tomas
>
>> PatC
>> >
>> >
>> >
>> >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: Tomas Goldbeck-Löwe<[email-masked]>
Date: Mon, 24 Jan 2000 11:15:25 -0800

Hi Pat,

Patrice Calhoun wrote:
> I believe that "DIAMETER be itself" is what you meant, right?

Yes.

>This draft

Right, the AAA protocol is not the issue.
Maybe I should have made my point above a little clearer. The AAA
protocol distributes the keying information (key and lifetime) to the
home agent and the foreign agent.
The key and lifetime is sent to the mobile node, in the key extensions
added to the Registration Reply as described in the AAA Reg Keys draft
(draft-calhoun-mobileip-aaa-key-00.txt). This means adding a lifetime
field in that draft. I'd be happy to give you some text to add to the
draft.

        --> Tomas