Subject: [Hipsec] Re: [Hipsec-rg] next steps with draft-heer-hip-middle-auth-00

From: Tobias Heer <[email-masked]>
Date: Wed, 23 Jan 2008 15:04:02 +0100

Hi Julien,

Am 23.01.2008 um 14:40 schrieb Julien Laganier:

> Hello Tobias,
>
> On Wednesday 23 January 2008, Tobias Heer wrote:
>> The scope of the draft is to illustrate a possible replay attack
>> towards the middlebox and proposes a solution that enables the
>> middlebox to interact with the BEX.
>>
>>> I think the draft should more accurately state what is the goal,
>>> security-wise. E.g. authentication alone is vague and prone to
>>> ambiguous interpretation. Once that is done, relevance of the
>>> solution can be assessed.
>>
>> Do you think the title is misleading or do you believe we should be
>> more specific in the abstract and text?
>
> I am actually unclear about the goal of BEX inspection by middlebox
> (e.g. signature verification). What kind of security service does it
> offer?
>
The goal is that the middlebox can verify the Identity of the hosts  
that communicate across it unambiguously.

Practical usecases could be middleboxes that enforces certain  
policies based on the identities of two hosts. The middlebox could  
perform access control (only certain hosts may communicate across the  
middlebox), or it may perform accounting (e.g. based on traffic  
volume or connection duration). Every usecase in which a middlebox  
needs to know who is communicating would apply.

If the middlebox only uses the HIs in the BEX and update packets and  
the signatures generated with these HIs to verify the Identities of  
the communicating peers, replay attacks are possible: A malicious  
Initiator collaborating with an malicious Responder can replay  
authentic BEXes of other hosts to the middlebox and thus, both  
attackers can impersonate the hosts that performed the authentic BEX.  
The draft solves this problem by letting the middlebox participate in  
the BEX and the HIP update process.

I have sent an e-mail illustrating the attack to the HIP lists in  
Summer 2007.
Here is a link to the email describing the replay attack:
http://www1.ietf.org/mail-archive/web/hipsec/current/msg02157.html

I hope this clarifies the scope of the drafft.

Best regards,

Tobias

> Once we have a good understanding of that, we can discuss about what
> your draft tries to achieve, and how.
>
> Thanks.
>
> --julien
>

--  
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: Julien Laganier <[email-masked]>
Date: Wed, 23 Jan 2008 15:24:05 +0100

On Wednesday 23 January 2008, Tobias Heer wrote:
> > (e.g. signature verification). What kind of security service does
> > it offer?
>

This is ambiguous in itself :) 

AFAIU, 'communicate' refers only the BEX. The middlebox doesn't verify 
identity of the hosts sending payload packets (e.g., ESP).

> needs to know who is communicating would apply.

Agree that in every such usecase the middlebox needs to know who is 
communicating. 

The point is that the current HIP middlebox story where midboxes are 
verifying signatures in the BEX doesn't achieve that (see above). Thus, 
we cannot use the BEX inspection in any of these usecase...

Let's first discuss what is (are?) the security service(s) offered by 
midbox BEX inspection.

--julien