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

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

So, if we fix up draft-calhoun-mobileip-aaa-key-00.txt, you would be happy,
or is any additional text ALSO necessary in the challenge/response draft?

PatC
>Hi Pat,
>
>Patrice Calhoun wrote:
>>
>> >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?
>
>Yes.
>
>>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.
>>
>
>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
>
>> >
>> >
>> >> >
>> >> >
>> >> >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:53:00 -0800

Adding a lifetime field to the draft-calhoun-mobileip-aaa-key-00.txt
makes I'm happy.

Adding the text in option 3 below, about that the MN SHOULD include the
MN-AAA auth in the next Reg Request if the MN gets a Reg Reply with code
BAD_AUTHENTICATION, would make me even happier.

        --> 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]
 Ericsson Radio Systems AB      Tel:      +46 8 7641467
 SE-164 80 Stockholm            Fax:     +46 8 4045769
                                Mobile: +46 70 9860680
_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/