Re: [Mip4] Authentication Mandate for All Registration Reply Messages

["Charles E. Perkins" <[e-mail]>]

Hello folks,

After the last IETF meeting, I received some review comments
from Simon Mizikovsky from Alcatel-Lucent on my proposal.
I have reformatted his comments below. I will follow up with
some additional comments in another message. At the end,
I have included Simon's email address also. These comments
refer to the text in draft-perkins-mip4-authreqd-00.txt, which I
presented during the [mip4] working group meeting.

==========================================
======== Comments from Simon Mizikovsky ==========
==========================================

 > ......... Even if the mobile node does retransmit the
 > Registration Reply message,

Perhaps, Registration Request?


 > 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.


 > It would be an
 > unfortunate error if a malicious agent were able to trigger re-
 > establishment of the mobile node's Mobility Security Association.

But if RRQ got to bad FA, it would simply not forward it to the HA.


 > Since, for Code 131, there are no retries specified in the Mobile-IP
 > protocol specification [1]. a single malicious packet could trigger
 > the loss of even a newly established and valid Mobility Security
 > Association between the mobile node and the home agent.

Usually, good client implementations allow some grace period for
not immediately issue the re-registration, but rather wait for
another RRP, possibly with properly signed MN-HA AE. The race
condition between right and bogus RRP can not be solved otherwise.


 > We propose that all Registration Reply messages MUST contain a valid
 > Mobile-Home Authentication Extension, with nonzero authentication
 > data generated according to the security algorithm indicated by the
 > SPI present in the Authentication extension. This is required
 > whether or not the Mobile Node is identified putely by its IP
 > address, or if the Mobile Node NAI extension is also supplied.

But this is impossible in absence of a valid MN-HA SA! Presence of
invalid MN-HA-AE or Zero-filled MN-HA AE is as bad as absence of
MN-HA AE with Error Code 131.


 > 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.


 > 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.


 > This may
 > also include an SPI in the range of well-known SPI numbers, but not
 > any reserved value for the SPI.

Another case is not examined: What if there is a MN-FA SA? The
FA then MUST include the MN-FA AE, and a conflicting error case
may occur when either MN-FA-AE or MN-HA-AE is not valid. How
should MN behave then?


 > This document identifies a security exposure that might disrupt a
 > mobile node's ability to connect to the Internet, and proposes a
 > solution to eliminate this exposure. It does not create any new
 > security exposures.

I don’t think this solution works in cases of dynamic HA
assignment and computed MN-HA and MN-FA SAs.


Semyon Mizikovsky
Alcatel Lucent
Wireless Security & Fraud Prevention
Wireless Standards Department
600/700 Mountain Avenue, 3C-506L
Murray Hill, NJ 07974, USA
(O) 1+908-582-0729
(M) 1+732-239-7533
(F) 1+908-743-4361

PLEASE NOTE MY NEW EMAIL ADDRESS:
[e-mail]
===========================================

Regards,
Charlie P.

PS. Simon also pointed out a few typos which I have not
reproduced in this email.


McCann Peter-A001034 wrote:
> We had some discussion on this in Hiroshima but I don't think
> we came to a satisfactory conclusion.  Does anyone have an 
> objection to requiring authentication on a rejection message?
>
> We'd like to submit 3344bis to the IESG soon, so it would be
> good to have a resolution on this issue in the next few days
> so that Charlie can submit a revised version.
>
> Thanks,
>
> -Pete
>
> Charles E. Perkins wrote:
>   
>> Hello folks,
>>
>> I've written up a new Internet Draft for submission next week.
>>
>> Here is the abstract.
>>     
>>>    Some implementations of Mobile IP home agents have been observed
>>>    to supply zero authentication data when sending a Registration
>>>    Reply to the mobile node that contains rejection code 131 (Mobile
>>>    Node Failed Authentication).  This creates a vulnerability
>>>    whereby a mobile node could be denied service from its home
>>>    agent, and thus lose connectivity to the Internet even though
>>>    mobile node and home agent were otherwise functioning properly.
>>>
>>>       
>> If possible, I would like to have a slot at the upcoming IETF to
>> discuss this matter.  It would be a short presentation. 
>>
>> Regards,
>> Charlie P.
>>     
>
>
>
>