Re: [Mip4] WGLC Comments: draft-ietf-mip4-mobike-connectivity-01.txt

[Vijay Devarapalli <[e-mail]>]

Sami Vaarala wrote:
> Vijay Devarapalli wrote:
>> Sami Vaarala wrote:
>>> Vijay Devarapalli wrote:
>>>> Henrik Levkowetz wrote:
>>>>
>>>>>> Also, I think it is worth mentioning that enterprise IP addresses 
>>>>>> may be
>>>>>> visible on untrusted networks, due to transmission of the RRQ, while
>>>>>> bypassing the VPN - the i-HA IP address will be available in the 
>>>>>> clear. 
>>>>>
>>>>> New topic here.  The observation seems to be correct.  I'll leave 
>>>>> it up to
>>>>> the authors whether they want to comment further on this.
>>>>
>>>> We could add the following text in the Security
>>>> Considerations section.
>>>>
>>>>    When the mobile node sends a registration request to the i-HA 
>>>> from an
>>>>    untrusted network that does not go through the IPsec tunnel, it may
>>>>    be leaking the i-HA's address and its own home address to the
>>>>    untrusted network.  This may be a concern in some deployments.
>>>
>>> I can live with that, though I think the potential concern is a bit 
>>> wider.
>>> How about this:
>>>
>>>     When the mobile node sends a registration request to the i-HA 
>>> from an
>>>     untrusted network that does not go through the IPsec tunnel, the 
>>> request
>>>     leaks some information possibly useful for an attacker.  In 
>>> particular,
>>>     the request reveals the i-HA address (and other address 
>>> information),
>>>     the user's NAI (if present), and may provide data which allows an
>>>     off-line brute-force attack on the MN-HA authentication key.
>>>
>>> I guess an underlying assumption here has been that the i-MIP setup 
>>> is not
>>> considered to be confidential.  Some users may be uncomfortable with 
>>> their
>>> username (NAI) being revealed.
>>
>> None of these registration requests from the untrusted
>> network including the registration request from the
>> mobile node make to the i-HA. They are all dropped at
>> the Enterprise firewall.
> 
> When the MN visits an untrusted network and attempts to send an RRQ to
> the i-HA, the RRQ is visible potentially to anyone, including any
> attackers.  The RRQ has an authenticator (which may be, for instance,
> HMAC-based).  Given the full RRQ packet, a brute force attack on the
> HMAC key can be launched; this is an off-line attack because all you
> need is the RRQ and you can begin churning away on possible HMAC keys,
> the MN-HA authentication data will give you the correct answer for
> comparison.  This attack doesn't involve the i-HA in any way, all you
> need is the RRQ packet.

RFC 3344 is susceptible to this attack.

Vijay

> 
>> BTW, this text needs to be added to
>> draft-ietf-mip4-vpn-problem-solution too.
> 
> Yup, already added.
> 
> BR,
> 
> -Sami


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