&gt;It's cool. Thanks for sharing. :)<br>&gt;<br>&gt;However, part of the community is also peer review. A friend just noted:<br>&gt;<br>&gt;"As for the specific issues raised below -- it's far too long since I've<br>&gt;read those RFCs, so I can't comment in detail; I will note that both<br>&gt;are listed as Obsolete in the RFC index.  RFC 3344 is the current MIP<br>&gt;document, and any criticisms should be probably be based on it."<br><br>RFC 3344 also has the same issue. It specifies that the reg-reply should contain an authentication extension, and specifies a reply code for authentication failures by mobile node, and home agent.<br><br>The issue isn't just the RFC though, as I noted in my original post. It's also with specific implementations of the mobile IP standard. The implementation in question is the Dynamics implementation, however, I know of at least one other Mobile IP-like protocol (A11 interface in 1xEV-DO networks) which have this enumeration
 problem.<br><br>-Aaron<br><br><br><b><i>Gadi Evron &lt;ge@linuxbox.org&gt;</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>&gt; This is my first real security related mailing, so I<br>&gt; hope it's acceptable. A search on the web revealed<br>&gt; that no one has yet pointed out this flaw, so I figure<br>&gt; 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>&gt; <br>&gt; In the MIP rfc 2002 and 3220 specs, neither talk about<br>&gt; authentication failures, or when it is acceptable
 NOT<br>&gt; to include the authentication extension. In fact,<br>&gt; these specs go as far as to include error cases when<br>&gt; we have failed authentications, and mandate that an<br>&gt; authentication extension be returned.<br>&gt; <br>&gt; Since the signaling messages are sent in "clear text,"<br>&gt; meaning that any schmuck with ethereal or some other<br>&gt; sniffing tool can read the packets, and the<br>&gt; information within, it's not unforseeable that a<br>&gt; potential evil user can send messages to the MIP<br>&gt; foreign, or home agent and listen for the registration<br>&gt; reply with whatever error code. Based on that, he can<br>&gt; use a brute force tool, or even some rainbow crack<br>&gt; lookups and potentially extract the users secret key.<br>&gt; In the even that such a thing happened, the evil user<br>&gt; can hijack legitimate users packet data sessions.<br>&gt; <br>&gt; I'll be writing a case study using the Dynamics Mobile<br>&gt; IP
 implementation, as well as releasing a patch to<br>&gt; dynamics so that it will simply drop any messages that<br>&gt; could potentially be used for enumeration against<br>&gt; Mobile IP agents.<br>&gt; <br>&gt; Just figured I'd release this information out there.<br>&gt; -Aaron<br>&gt; <br>&gt; <br>&gt;  <br>&gt; ____________________________________________________________________________________<br>&gt; Have a burning question?  <br>&gt; Go to www.Answers.yahoo.com and get answers from real people who know.<br>&gt; _______________________________________________<br>&gt; Dailydave mailing list<br>&gt; Dailydave@lists.immunitysec.com<br>&gt; http://lists.immunitysec.com/mailman/listinfo/dailydave<br>&gt; <br><br></blockquote><br><p>&#32;
<hr size=1>Cheap Talk? <a href="http://us.rd.yahoo.com/mail_us/taglines/postman8/*http://us.rd.yahoo.com/evt=39663/*http://voice.yahoo.com">Check out</a> Yahoo! Messenger's low PC-to-Phone call rates.