Subject: Re: [Mip4] Authentication Mandate for AllRegistration Reply Messages

From: "McCann Peter-A001034" <[email-masked]>
Date: Tue, 12 Jan 2010 18:17:17 -0500

We need to come to some agreement on this thread.

One thing I'd like to point out: the spec currently requires
the following, in Section 3.8.2.1 bullet (a) paragraph 2:

       If the home agent receives a Registration Request from a Mobile
       Node with which it does not have any security association, the
       home agent MUST silently discard the Registration Request.

If we take this requirement as given, then if the HA does not have
or cannot get an SA with the MN it should not be sending a Registration
Reply at all.  Whether or not AAA is involved should be irrelevant.
Code 131 means, "I think I have an SA, but the one you used didn't
work."  The HA should be using what it thinks is a valid SA.  IMHO,
if the MN can't authenticate the Reply, it shouldn't take any action
based on it.  If the MN's state machine is currently trying to register,
this means keep re-transmitting the Request until it gives up.

Thoughts?

-Pete

Charles E. Perkins wrote:
> Hello Simon,
> 
> Mizikovsky, Semyon B (Simon) wrote:
>> 
>>>> In the specific case of rejection Code 131, there is a likelihood
>>>> that the mobile node's security association with its home agent
>>>> needs to be refreshed, if the authentication data supplied with the
>>>> Registration Request message were not correct.
>>>> 
>>> In a real case scenario, when both MN-HA and MN-HA-SPI are computed
>>> from EMSK, the HA will not know the new MN-HA after
>>> re-authentication, but link to the AAA would be broken, disallowing
>>> it to retrieve the new MN-HA. 
>>> 
>> 
>> In this case, what remedy is made available?
>> [sm] One thing comes to mind: MN should not purge the old MN-HA
>> before it received an RRP signed by the new MN-HA. Thant way, the HA
>> may sign the RRP with old existing MN-HA because it could not access
>> the AAA and retrieve the new MN-HA based on the new SPI. MN would be
>> able to verify the RRP using the old MN-HA, and get an indication
>> that HA is on its own. The old MN-HA would have to coexist with the
>> new MN-HA until its natural death, after which it will not exist in
>> either MN or HA. From that point on, the RRP Reject with code 131 -
>> unsigned - would be appropriate.        
>> 
> 
> Suppose the mobile node receives a RREP with code 131.  Then there
> are multiple cases: - MN-HA security association is valid, and the
>     RREP can be authenticated. Then, what should the mobile node do? 
>     This could happen if a malicious node sent a bogus RREQ to the
>     home agent.    In fact, it could happen even if the mobile node
>     did not recently send any RREQ message at all. If so, maybe it is
>     safer for the mobile node to re-register with a proper RREQ, but
>     always doing so would enable a malicious node to make additional
>     cryptographic work for the mobile node.  Maybe such a
>     re-registration should only be done when the mobile node has in
> fact recently sent a re-registration.  Or, ...? 
> 
> - MN-HA authentication data cannot be validated in the RREP.  This is
>    the case I think we have been discussing.  Here, the mobile node
>    should wait for another RREP.    If no RREP arrives, the mobile
>    node should probably act as if its registration security
> association is invalid. 
> 
> 
>> I think this is a good idea.  Perhaps it should be specified as
>> something the mobile node SHOULD do.  I realize it is not required
>> (strictly speaking) for interoperability, but it might be the best
>> solution for the problem with code 131.   
>> 
>> [sm] I think so. Can not think of anything as clean and as cheap.
>> 
> 
> O.K.  I will write up something along these lines.
> 
>> 
>> 
>>> 
>>>> As specified in section 3.6.2.1 of [1], if a Mobile Node receives a
>>>> Registration Reply message that does not contain a Mobile-Home
>>>> Authentication Extension, or one with zero authentication data, the
>>>> Mobile Node MUST silently discard that packet.
>>>> 
>>> Sorry, I disagree.
>>> 
>> 
>> Here is the language:
>> 
>>                                                                   
>>            If the Registration Reply was generated by the home agent
>>            but no Mobile-Home Authentication Extension is found, or
>>            if more than one Mobile-Home Authentication Extension is
>>            found, or if the Authenticator is invalid, the mobile
>>            node MUST silently discard the Reply and SHOULD log the
>> event as a security            exception. 
>> 
>> That seems pretty definite to me.  Do you think it should be worded
>> differently? 
>> 
>> [sm] Let's go over the scenarios:
>> MN sent the RRQ with the MN-HA-AE containing unknown SPI. HA needs
>> to send the RRP but it can not get the proper MN-HA associated with
>> this SPI. In other words, there is no valid security association
>> between MN and HA. HA can: 1) Send the RRP signed by its current
>> existing MN-HA (if it exists), different from the one used by the MN
>> in RRQ. If MN retains the old MN-HA, we are home free.    
>> 
>> 2) Send the RRP with 131 unsigned. The MN will assume this is
>> temporary outage (not DoS) and resend the RRQ after a short while,
>> hoping for the best. If in a grace period the right RRP does not
>> come, and retry comes again unsigned, then - sorry - access
>> unsuccessful.    
>> 
>> 3) Send the RRP with MN-HA-AE set to Zeros. This case is not
>> different from (2) because the treatment by the MN would be just the
>> same.  
>> 
>> So, sending RRP without MN-HA-AE or with bogus "all zero" MN-HA-AE
>> is the same! 
>> 
> 
> O.K.  We can agree that those two cases in your last sentence are
> practically equivalent. 
> 
> But:
> - I thought you were disagreeing with "silently discard".
> - "silently discard" is compatible with "wait for another RREP to
> arrive" 
> - "silently discard" isn't 100% compatible with "expunge MN-HA
>         association and begin to establish a new MN-HA security
> association". 
> 
> I thought that there was some train of thought whereby it was better
> to have zero authentication data instead of a missing MN-HA
> authentication extension, because of the way that some people had
> read the original specification language.   
> But anyway
> I agree with you and don't see any technical difference except that
> the former approach wastes a little more bandwidth over the air. 
> was "better" than a missing.
> 
> Nevertheless it might be reasonable to specify something about when
> the mobile node ought to re-establish its security association. 
> 
> Except that MIPv4 never did anything like that in the past.  It was
> all laid out in the AAA specifications, as far as I remember. 
> 
>> 
>>> 
>>>> A mobility security association between the Home Agent and the
>>>> Mobile node MAY be configured especially For the purpose of
>>>> supplying the authentication data to the Mobile Node when a
>>>> Registration Request is rejected, This alternative security
>>>> association MAY use a default SPI number, or any other different
>>>> SPI that may be convenient. 
>>>> 
>>> If the assumption here is a special SA pre-configured for handling
>>> error cases, than it is a very bad idea. Consider: If all mobile
>>> nodes knew it, than it would not be a secret, and any interloper
>>> could use it to sign a bogus RRP.
>>> 
>> 
>> How about if it were particular to the mobile node, but had a very
>> very long lifetime? 
>> 
>> [sm] How would HA know it? What if HA is dynamically assigned? HA
>> would have to query the AAA for it, so why would not it query AAA
>> for the right MN-HA in the first place?  
>> 
> 
> Well, the idea is to enable solutions sometimes even if not every
> system design can make use of the solution.  So, if HA has to query
> AAA to get the longer-lived key, that doesn't bother me.  Mobile IP
> was designed a long time before AAA anyway.  If this were a different
> discussion, I'd complain a lot about typical AAA system designs, but
> here I will have to forgo that opportunity.  However sometimes I wish
> someone would explain to me why operators insist on using the most
> time-consuming and heavyweight approaches imaginable, and then wonder
> why they can't get sufficient performance.  More round trips over the
> network and queueing delays at the servers?  No problem, right?? 
> They should just use Mobile IP and be done with it.  The HA was,
> after all, designed to be a secure router with a near-trivial update
> protocol.  (<== easy to understand).            
> 
> 
> Thanks for your holiday wishes.  I hope that many good things are
> routed your way. 
> 
> Regards,
> Charlie P.

---

From: Ahmad Muhanna <[email-masked]>
Date: Wed, 13 Jan 2010 13:05:26 -0500

Hi, Pete,

I think the text you quoted very much cover this case and everything else we have been discussing can continue to be out-of-scope. However, I like your definition of what error code 131 means to the HA.

I would support adding some clarification text to reflect that.

Regards,
Ahmad
________________________________________
From: [email-masked] [[email-masked]] On Behalf Of McCann Peter-A001034 [[email-masked]]
Sent: Tuesday, January 12, 2010 5:17 PM
To: Charles E. Perkins; Mizikovsky, Semyon B (Simon)
Cc: Mobile IPv4 Mailing List
Subject: Re: [Mip4] Authentication Mandate for AllRegistration  Reply   Messages

Thoughts?

-Pete

--
Mip4 mailing list: [email-masked]
    Web interface: https://www.ietf.org/mailman/listinfo/mip4
     Charter page: http://www.ietf.org/html.charters/mip4-charter.html
Supplemental site: http://www.mip4.org/