Re: [Hipsec] Feedback for 4423bis

[Miika Komu <[e-mail]>]

Hi,

On 10/21/2012 06:21 PM, Miika Komu wrote:
> Hi,
>
> On 10/19/2012 12:38 AM, Miika Komu wrote:
>> Hi,
>>
>> On 10/10/2012 10:05 PM, Sasu Tarkoma wrote:
>>> Hi all,
>>>
>>> I read the latest HIP architecture draft (4423bis-05) and it looks
>>> very good. Below you will find some observations that I made
>>> when reading the draft.
>>
>> looks good to me too but I have also some suggestions for improvement.
>> Here's the first batch of comments, I'll send the remaining ones later.
>
> the second batch is here, I'll send the third and final later.

the third and final batch is now here. Sorry for the delay.

> 14. Security considerations
> ..
> There are more details on this process in the Host Identity Protocol.

I think we're pretty much done with the details.

> HIP optionally supports opportunistic negotiation.  That is, if a
> host receives a start of transport without a HIP negotiation, it can
> attempt to force a HIP exchange before accepting the connection.
> This has the potential for DoS attacks against both hosts.  If the
> method to force the start of HIP is expensive on either host, the
> attacker need only spoof a TCP SYN.  This would put both systems into
> the expensive operations.  HIP avoids this attack by having the
> responder send a simple HIP packet that it can pre-build.  Since this
> packet is fixed and easily replayed, the initiator only reacts to it
> if it has just started a connection to the responder.

send a simple HIP packet -> send a simple R1 packe

I think this text tries to describe a SHIM6-like upgrade feature that is 
poorly defined by any of the RFCs for HIP. The description is difficult 
to understand (for instance, "opportunistic" can be confused with 
opportunistic mode) and a bit too research oriented for this document.

> If the responder's HI is
> retrieved from a signed DNS zone or secured by some other means, the
> initiator can use this to authenticate the signed HIP packets.

secure -> securely obtained

> The need to support multiple hashes for generating the HIT from the
> HI affords the MitM a potentially powerful downgrade attack due to
> the a-priori need of the HIT in the HIP base exchange.

...MitM to *mount* a...

> However, since this only
> happens in an attack scenario and since the attack can be handled (so
> it is not interesting to mount anymore), we assume the additional
> messages are not a problem at all.

happens -> occurs

> However, since this only
> happens in an attack scenario and since the attack can be handled (so
> it is not interesting to mount anymore), we assume the additional
> messages are not a problem at all.

..the *potentially* additional..

.. are not a *security* problem at all..

> This might seem to make it
> easier for an attacker, but ESP with replay protection is already as
> well protected as possible, and the removal of the IP address as a
> check should not increase the exposure of ESP to DoS attacks.

make it easier for an attacker -> make attacking easier

> Since not all hosts will ever support HIP, ICMPv4 'Destination
> Unreachable, Protocol Unreachable' and ICMPv6 'Parameter Problem,
> Unrecognized Next Header' messages are to be expected and present a
> DoS attack.  Against an initiator, the attack would look like the
> responder does not support HIP, but shortly after receiving the ICMP
> message, the initiator would receive a valid HIP packet.  Thus, to
> protect against this attack, an initiator should not react to an ICMP
> message until a reasonable time has passed, allowing it to get the
> real responder's HIP packet.  A similar attack against the responder
> is more involved.

I would clarify that the attack scenario is MitM here.

..get the real.. -> ..receive the real..

> A HIP packet is
> not used because it would either have to have unique content, and
> thus difficult to generate, resulting in yet another DoS attack, or
> just as spoofable as the ICMP message.

Suggest rewriting the beginning to avoid passive voice:

In this scenario, the attacker would not use a HIP control packet
because ...

Why would it create yet another DoS attack? Are mixing the R1 counter to 
the discussion here (I suggest not doing this).

> Like in the previous case,
> the defense against this attack is for the initiator to wait a
> reasonable time period to get a valid HIP packet.

Like -> Similarly as
get -> receive

If one does not
> come, then the initiator has to assume that the ICMP message is
> valid.

come -> arrive or appear

Since this is the only point in the HIP base exchange where
> this ICMP message is appropriate, it can be ignored at any other
> point in the exchange.

this -> an

> 14.1. HITs used in ACLs
 >
 > It is expected that HITs will be used in ACLs.

(they have already been used for such purposes)

"At end-hosts, HITs can be used in IP-based access control lists at the 
application and network layers".

 > Future firewalls can use HITs to control egress and ingress to
 > networks, with an assurance level difficult to achieve today.

"At middleboxes, HIP-aware firewalls [FW] can use HITs or public keys to 
control both ingress and egress access to networks or individual hosts, 
even in the presence of mobile devices because the HITs and public keys 
are topologically independent".

[FW] Janne Lindqvist, Essi Vehmersalo, Miika Komu and Jukka Manner.
Enterprise Network Packet Filtering for Mobile Cryptographic Identi-
ties. International Journal of Handheld Computing Research (IJHCR),
Volume 1, Issue 1, pp. 79-94, ISSN 1947-9158, January 2010.

 > The signatures in HIP packets allow a capable firewall
 > to ensure that the HIP exchange is indeed happening between two known
 > hosts.

happening -> occurring

 > A potential of HITs in ACLs is their 'flatness' means they cannot be
 > aggregated and this could result in large table searches

"A potential drawback of HITs in ACLs is their 'flatness' means
they cannot be aggregated ,and this could potentially result in large 
table searches in HIP-aware firewalls. However, all hosts are treated as 
individuals in HIP, meaning that it is also easier to exclude individual 
hosts out simply by removing the corresponding HIT from the firewall ACL".

 > A host can keep track of all of its partners that might use its HIT
 > in an ACL by logging all remote HITs.  It should only be necessary to
 > log responder hosts.  With this information, the host can notify the
 > various hosts about the change to the HIT.  There has been no attempt
 > to develop a secure method to issue the HIT revocation notice.

untrue, you're missing an (informal) reference to here:

http://tools.ietf.org/html/draft-irtf-hiprg-revocation-05

 > HIP-aware NATs, however, are transparent to the HIP aware systems by
 > design.  Thus, the host may find it difficult to notify any NAT that
 > is using a HIT in an ACL.  Since most systems will know of the NATs
 > for their network, there should be a process by which they can notify
 > these NATs of the change of the HIT.  This is mandatory for systems
 > that function as responders behind a NAT.  In a similar vein, if a
 > host is notified of a change in a HIT of an initiator, it should
 > notify its NAT of the change.  In this manner, NATs will get updated
 > with the HIT change.

NAT is a middlebox that does address translation. It should not be 
concerned with access control, besides that they typically drop inbound 
data flows due to absence of mappings. I think you should be rather 
talking about passive, on-path HIP-aware firewalls  such as described in 
[FW], or this text should be removed.

> 14.2. Alternative HI considerations

 > The definition of the Host Identifier states that the HI need not be
 > a public key.  It implies that the HI could be any value; for example
 > a FQDN.  This document does not describe how to support such a non-
 > cryptographic HI.  A non-cryptographic HI would still offer the
 > services of the HIT or LSI for NAT traversal.  It would be possible
 > to carry HITs in HIP packets that had neither privacy nor
 > authentication.

RFID version of HIP could maybe cited (as informational) as an example 
of such a compromise?

http://tools.ietf.org/html/draft-irtf-hiprg-rfid-06

 > Since such a mode would offer so little additional
 > functionality for so much addition to the IP kernel, it has not been
 > defined.  Given how little public key cryptography HIP requires, HIP
 > should only be implemented using public key Host Identities.

I suggest rephrasing the last sentence because the cryptography may be 
just too much some constrained devices.

> 15. IANA considerations

 > Finally,
 > Lars Eggert, Spencer Dawkins and Dave Crocker provided valuable input
 > during the final stages of publication, most of which was
 > incorporated but some of which the authors decided to ignore in order
 > to get this document published in the first place.

What were the issues?

> 16. Acknowledgments

Please add Aalto University, University of Helsinki and RWTH Aachen.

> 17.2. Informative references

Consider adding the following reference, for example, in the 
introduction of the draft if seem fit:

P. Nikander, A. Gurtov, T. Henderson, Host Identity Protocol (HIP): 
Connectivity, Mobility, Multi-homing, Security, and Privacy over IPv4 
and IPv6 networks, IEEE Communications Surveys and Tutorials, 12 (2), 2010.

http://www.cs.helsinki.fi/u/gurtov/papers/hip_survey.pdf