Actually, after a further review of 3344, it seems as though section 3.2.7.1 does address this issue now.<br><br>"If no Mobile-Foreign Authentication Extension is found, or if more than one Mobile-Foreign<span style="font-family: monospace;"><br></span>Authentication Extension is found, or if the Authenticator is<span style="font-family: monospace;"><br></span>invalid, the foreign agent MUST silently discard the Request and<span style="font-family: monospace;"><br></span>SHOULD log the event as a security exception"<br><br>Thank you for pointing this out.<br><br><b><i>Gadi Evron <ge@linuxbox.org></i></b> wrote:<blockquote class="replbq" style="border-left: 2px solid rgb(16, 16, 255); margin-left: 5px; padding-left: 5px;"> On Thu, 7 Dec 2006, Aaron wrote:<br>> This is my first real security related mailing, so I<br>> hope it's acceptable. A search on the web revealed<br>> that no one has yet pointed out this flaw, so I figure<br>> I will.<br><br>It's cool.
Thanks for sharing. :)<br><br>However, part of the community is also peer review. A friend just noted:<br><br>"As for the specific issues raised below -- it's far too long since I've<br>read those RFCs, so I can't comment in detail; I will note that both<br>are listed as Obsolete in the RFC index. RFC 3344 is the current MIP<br>document, and any criticisms should be probably be based on it."<br><br><br>> <br>> In the MIP rfc 2002 and 3220 specs, neither talk about<br>> authentication failures, or when it is acceptable NOT<br>> to include the authentication extension. In fact,<br>> these specs go as far as to include error cases when<br>> we have failed authentications, and mandate that an<br>> authentication extension be returned.<br>> <br>> Since the signaling messages are sent in "clear text,"<br>> meaning that any schmuck with ethereal or some other<br>> sniffing tool can read the packets, and the<br>> information within, it's not
unforseeable that a<br>> potential evil user can send messages to the MIP<br>> foreign, or home agent and listen for the registration<br>> reply with whatever error code. Based on that, he can<br>> use a brute force tool, or even some rainbow crack<br>> lookups and potentially extract the users secret key.<br>> In the even that such a thing happened, the evil user<br>> can hijack legitimate users packet data sessions.<br>> <br>> I'll be writing a case study using the Dynamics Mobile<br>> IP implementation, as well as releasing a patch to<br>> dynamics so that it will simply drop any messages that<br>> could potentially be used for enumeration against<br>> Mobile IP agents.<br>> <br>> Just figured I'd release this information out there.<br>> -Aaron<br>> <br>> <br>> <br>> ____________________________________________________________________________________<br>> Have a burning question? <br>> Go to
www.Answers.yahoo.com and get answers from real people who know.<br>> _______________________________________________<br>> Dailydave mailing list<br>> Dailydave@lists.immunitysec.com<br>> http://lists.immunitysec.com/mailman/listinfo/dailydave<br>> <br><br></blockquote><br><p> 
<hr size=1>Want to start your own business? Learn how on <a href="http://us.rd.yahoo.com/evt=41244/*http://smallbusiness.yahoo.com/r-index">Yahoo! Small Business.</a>