Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

RE: [LinkSec] Requirements



Writing this email is a bit like dipping your toe into piranha infested waters - the conversation already involves so many familiar names from so many years that joining it is a little daunting...

 

It seems to me that there are two issues that are getting confused here:

 

(1) The need to authenticate one end point to another in order to prove that the traffic is coming from another authenticated user of the LAN (and optionally to prove that it is coming from the MAC address it claims to be).  This is to protect users of the network (including servers) from unauthorised access and eavesdropping.

 

(2) The need to authenticate traffic to the network.  This is to protect the network from unauthorised use between a pair of users, one at least of which is not authorised to use the network. 

 

Wired networks may need the former, but may be happy to fall back on physical connectivity to provide the latter.

 

In contrast, wireless networks must provide (2) by some protocol mechanism.  In 802.11i the protocol mechanism chosen also authenticates to the user that the received traffic came from the network access point.  It is assumed that the access point is a portal into a trusted environment, so this authentication effectively provides (1) at the same time.

 

To reiterate – the 802.11i model (and the 802.1X model) is of a trusted network accessed through access points that can prevent unauthenticated access to the trusted network.  I think Bob’s “two bridges” scenario is fundamentally different in that there is no trusted network to which you want to gain access.  It’s all un-trusted, and you need protection end-to-end.

 

However, I don’t think that there is any point in solving the end-to-end issue at level 2 – it’s much better done at level 3 or above.  So I really don’t think that the two Bridge scenario is one that needs fixing – there are already other ways of doing it.

 

The one that is worth fixing is the trusted network accessed through an access point (or points).  You authenticate with the access point (or points), you get credentials in return, and you use them to exchange data with the access point.

 

Moving on…

 

If you look at the 802.11i model you’ll see that each client is effectively a member of three VLANs.  The first is completely insecure and is used to transfer messages to establish an authentication.  The second  is a VLAN accessible to all members of the LAN, and is used to carry broadcast messages to all the devices.  It is protected from unauthenticated users by encryption.  The third is an individual VLAN between the access point and the client which protects the unicast data from everyone else.  As a result, when you get a frame from a wireless client via this VLAN, you know that it really did come from the station currently associated with that MAC address.  (If the frame originated from a non-wireless device this may not be true.  Also, there is no proof that the person who claimed the address at authentication time is the real owner).  The VLANs are not tagged, but are identified by a combination of the MAC addresses involved, encryption credentials, and the current state of the authentication.

 

I think this model maps equally well to EPON from what I know of it.   At the root of the access link you have an access point which all the devices can send frames to in order to establish an 802.1X authentication.  You then move each authenticated device to a pairwise VLAN which is protected from all other users of the physical LAN by encryption.  If the access point is also a router, you could forget about the broadcast VLAN, and consider each pairwise VLAN as a point to point link.

 

However you might want to retain the broadcast VLAN for broadcasting or multicasting video or some such application.  In this case the data would be accessible to all the level 2 devices, but could be protected by some higher layer mechanism if required.

 

Just as in the wireless LAN case it is not possible to prevent two users on the same access link using the access network for communication if it provides a signal carrying conduit between them.

 

Perhaps the only question that remains is whether the operator wants the device to prove ownership of the MAC address that the device claims.  If the access point is also a router then this is un-necessary (as the MAC address then only has local significance, and the access point can prevent a second client authenticating with a duplicate MAC address).  It’s equally the case if the VLANs are carried all the way through to a remote router, rather than being bridged together as they effectively are in 802.11i.

 

Of course, I could have totally missed the point… J

 

Mike.

 

 

 

 

 

 

Mike Moreton, Synad Technologies.