Subject: [Hipsec] Security issue for middlebox authentication?

From: Tobias Heer <[email-masked]>
Date: Thu, 09 Aug 2007 19:47:39 +0200

Hi everyone,

I recently stumbled about a seemingly unhandled security issue in the  
HIP protocol concering the authentication of HIP hosts towards  
middleboxes. I'm not sure if this issue has been discussed before. If  
so, please excuse my ignorance.

In order to illustrate the issue, let me construct a small example:
Assume we have a middlebox that checks HIP HIs in order to restrict  
traffic passing through the box (something like a HIP firewall,  
etc.). Assume the legitimate holder of HIT X establishes a HIP  
association with the legitimate holder of HIT Y at some point in time  
and an attacker M overhears the base exchange and records it (it is  
not required that the middlebox is on the communication path at that  
time).

At some later point in time (maybe even just milliseconds later) M  
collaborates with another attacker N. M and N replay the very same  
BEX with the middlebox on the communication path. The middlebox has  
no way to distinguish M from X and N from Y as it can only overhear  
the BEX passively and does not participate in the authentication  
process. If M and N have agreed on a shared secret beforehand, they  
can make ESP traffic traverse the middlebox by using the SPIs that X  
and Y negotiated in the original BEX. This is problematic in all  
cases where the middlebox really needs to know who is communicating  
across it (think of logging, accounting for traffic volume, ....).

If I am not completely mistaken (and that may be the case, of course)  
HIP does not have a built in defense against this kind of attack.  
Using R1 generation counters and unique puzzles won't help much  
because the middlebox might not have seen the first (authentic) BEX  
and cannot identify the replayed one as duplicate.

It might be the case that HIP was not intended to be used for such  
authentication towards middleboxes but I remember seeing quite a few  
application examples that plan to use HIP in such a way.

A solution for fixing this problem could be allowing middleboxes  
adding nonces (like the ECHO_REQUEST, ECHO_RESPONSE mechanism) to the  
unsigned part of the R1 and I2 messages. The initiator or responder  
includes this additional nonce in the signed part of the I2 or R2,  
respectively. This allows the middlebox to verify the signatures and  
the presence of its nonces before allowing ESP traffic to pass  
through. A problem here might be the number of middleboxes that can  
add nonces to the packet. If too many middleboxes insist to add  
nonces, this might exceed the maximum packet size for a HIP packet.  
However, one shouldn't expect too many middleboxes on the path.

Best regards,

Tobias

-- Dipl.-Inform. Tobias Heer, Ph.D. Student
Distributed Systems Group
RWTH Aachen University, Germany
http://ds.cs.rwth-aachen.de/members/heer

_______________________________________________
Hipsec mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/hipsec

---

From: Pekka Nikander <[email-masked]>
Date: Fri, 10 Aug 2007 09:23:02 +0300

Hi Tobias,

> association with the legitimate holder of HIT Y at some point in  
> time and an attacker M overhears the base exchange and records it  
> (it is not required that the middlebox is on the communication path  
> at that time).
>
> can make ESP traffic traverse the middlebox by using the SPIs that  
> X and Y negotiated in the original BEX. This is problematic in all  

As far as I can see, that is correct.  However, ...

> adding nonces (like the ECHO_REQUEST, ECHO_RESPONSE mechanism) to  
> the unsigned part of the R1 and I2 messages.

... that's allowed already, isn't it?

> The initiator or responder includes this additional nonce in the  
> signed part of the I2 or R2, respectively.

So this is what is missing: requiring the recipient of an unsigned  
ECHO_REQUEST to include a corresponding ECHO_RESPONSE to the *signed*  
part of the reply message?  Well, that has the obvious drawback that  
the middle box won't be able to delete the ECHO_RESPONSE from the  
reply, but I cannot see any other bad effects.

> This allows the middlebox to verify the signatures and the presence  
> of its nonces before allowing ESP traffic to pass through. A  
> problem here might be the number of middleboxes that can add nonces  
> to the packet. If too many middleboxes insist to add nonces, this  
> might exceed the maximum packet size for a HIP packet. However, one  
> shouldn't expect too many middleboxes on the path.

I agree.

To me what you suggest seems like a fairly simple new extension,  
probably worthy a new parameter with the CRITICAL bit set.
Care to write a draft?

--Pekka

---

From: Tobias Heer <[email-masked]>
Date: Fri, 10 Aug 2007 22:13:53 +0200

Hi Pekka,

I'll write a short draft about it and send it to the list ASAP.

Cheers

Tobias

Am 10.08.2007 um 08:23 schrieb Pekka Nikander:

>> Assume we have a middlebox that checks HIP HIs in order to  
>> restrict traffic passing through the box (something like a HIP  
>> firewall, etc.). Assume the legitimate holder of HIT X establishes  
>> a HIP association with the legitimate holder of HIT Y at some  
>> point in time and an attacker M overhears the base exchange and  
>> records it (it is not required that the middlebox is on the  
>> communication path at that time).
>>
>> BEX with the middlebox on the communication path. The middlebox  
>> has no way to distinguish M from X and N from Y as it can only  
>> overhear the BEX passively and does not participate in the  
>> authentication process. If M and N have agreed on a shared secret  
>> beforehand, they can make ESP traffic traverse the middlebox by  
>> using the SPIs that X and Y negotiated in the original BEX. This  
>> is problematic in all cases where the middlebox really needs to  
>> know who is communicating across it (think of logging, accounting  
>> for traffic volume, ....).
>
> ECHO_REQUEST to include a corresponding ECHO_RESPONSE to the  
> *signed* part of the reply message?  Well, that has the obvious  
> drawback that the middle box won't be able to delete the  
> ECHO_RESPONSE from the reply, but I cannot see any other bad effects.
>
>> This allows the middlebox to verify the signatures and the  
>> presence of its nonces before allowing ESP traffic to pass  
>> through. A problem here might be the number of middleboxes that  
>> can add nonces to the packet. If too many middleboxes insist to  
>> add nonces, this might exceed the maximum packet size for a HIP  
>> packet. However, one shouldn't expect too many middleboxes on the  
>> path.
>
> I agree.
>

--  
Dipl.-Inform. Tobias Heer, Ph.D. Student
Distributed Systems Group
RWTH Aachen University, Germany
http://ds.cs.rwth-aachen.de/members/heer