Architecture for a 3-party-protocol

[Paul Lambert]

First 802.1x is a badly designed architecture ... there really should be an ongoing bypass for key management versus the "switch" used in .1x This would be akin to the "dual stack" model in IPsec where traffic (in a fully secure - no bypass system) is either necrypted by the encapsulation protocol or sent to the key management agent.

In this context one approach woud be to use an alternate new layer two protocol Id (sapi) to support your protocol - and not use .1x  This is a better architecture, but it changes some of the base 802.11 association states.  Fixing / removing .1x would be ideal, a compromise would be to use action frames to carry the new authentication protocol.  Action frames can be sent pre-association - so would be viable for an authentication protocol.  These frames could continue unprotected after key establishment so they could support rekey or other management functions.

The last approach would be to not use the EAPoL encapsulation on the link - but not RADIUS to the third party.

Paul




 
Paul A. Lambert | Marvell Semiconductor | +1 650-787-9141
 
> -----Original Message-----
> From: hostap-bounces at lists.shmoo.com [mailto:hostap-
> bounces at lists.shmoo.com] On Behalf Of Damien Leroy
> Sent: Thursday, March 11, 2010 6:38 AM
> To: hostap at lists.shmoo.com
> Subject: Architecture for a 3-party-protocol
> 
> Hi,
> In the context of our research, we have designed a network protocol
> performing authentication between a mobile host, an authenticator and
> third party. Each message is different and contains various payload (id,
> signature, ...) but due to WiFi architecture, we could see the protocol
> as a protocol between the supplicant and the authenticator mixed with a
> protocol between the authenticator and the third party.
> We have implemented it, but currently we are using classical EAP between
> the supplicant and the authenticator and the authenticator creates a
> radius client (in the EAP method) that encapsulate another EAP packet to
> the third party. This way of doing is quite ugly in the authenticator
> because we have to make the EAP-SM sleep while waiting for reply from
> the 3rd-party and creating a radius client with all its parameters
> inside our EAP method is not really transparent.
> 
> Would you have a better idea of infrastructure to implement this
> mechanism while keeping the code clean and observing standards ?  (of
> course, we will implement it by ourselves)
> Maybe it would be smarter to implement it using a, independant UDP
> protocol (i.e., without RADIUS nor EAP) between the authenticator and
> the 3rd party.
> 
> Best,
> 
> --
> Damien Leroy
> http://inl.info.ucl.ac.be/dleroy
> ICTEAM Research Institute
> UCLouvain - Belgium
> 
> _______________________________________________
> HostAP mailing list
> HostAP at lists.shmoo.com
> http://lists.shmoo.com/mailman/listinfo/hostap