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

Hi Julien,

Thanks for your comments, find my comments in-line.

Am 23.01.2008 um 11:43 schrieb Julien Laganier:

> Hello Miika,
>
> On Tuesday 22 January 2008, Miika Komu wrote:
>> On Mon, 21 Jan 2008, Henderson, Thomas R wrote:
>>> Questions or comments raised during the RG presentation:
>>> - Philip Matthews raised some questions about the relevance of the
>>> use case described (access point sharing, and the assumptions on
>>> the location of the attackers) and whether HIP was the right
>>> solution for this (versus, for example, WPA). He also suggested to
>>> look at other work in IETF on how to talk to middleboxes
>>
>> WPA is used wireless networks and it does not solve the problem for
>> wired networks.
>
> WPA is a specification of the Wi-Fi Alliance that implements (most)
> IEEE
> 802.11i specification.
>
> IEEE 802.11i specifies security for 802.11 wireless media, and
> relies on
> IEEE 802.1x which is a network access control/authentication
> mechanisms
> for 802 style media.
>
> Thus, IEEE 802.1x is not limited to wireless or wired, and can
> perfectly
> be used with IEEE 802.3 media, a.k.a. Ethernet.
>
>> I am not an wireless expert, but I believe you need
>> something like RADIUS to create individual WPA keys for each host,
>> right? Otherwise hosts can snoop each others traffic and do the
>> attack described in the draft.
>
> IEEE 802.1x does not require a AAA infrastructure per se, it is an
> underlying layer for EAP. However, for scalability reasons you might
> want to centralize credentials in a AAA server so that credentials
> need
> not be distributed to all access points.
>
>> Also, WPA is usually used at the edge and it does not solve the
>> problem when the multiple middleboxes on the path.
>
> W.r.t. edge vs. multiple midboxes on-path, if network access
> control/authentication is the goal, it is sufficient to perform it
> once, at the edge.
>

Thank you for the clarifications on WI-Fi protection. However, I would like to move away from this Wi-Fi protection discussion because it is not part of the draft. The usecase of Wi-Fi sharing was only used to highlight one possible application of HIP. This application
demands that a middlebox can verify the identities of communicating hosts by observing the HIP handshake.
This scenario is not limited to Wi-Fi sharing but is also relevant for other usecases.
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?

Thanks for your comments,

Tobias

>
>> I don't think that we should force dependencies to some other
>> protocols in a *HIP* middlebox... does not make much sense to me.
>>
>> As a conclusion, I think the middlebox draft from Tobias makes a lot
>> of sense for replay protection for middleboxes.
>
> I think we should first determine what's the goal pursued. Then we can
> decide if the specific solution makes sense.
>

Do you need help?
In addition to our free technical library, Pantek provides professional IT services to companies who utilize Open Source software: Learn more about Pantek's Technical Support offerings Place an order for 24/7/365 Technical Support here Learn more about Pantek, who we are, and what we do Chat with a Live Operator Related listserv.cybertrust.com Links hipsec-rg Request more information about Pantek

> My 2 cents.
>
> --julien
>
>

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