RE: [LinkSec] Thoughts on high-level requirements
Sorry if I aggravated an old wound. I didn't mean to imply that a list of authorized MAC addresses was sufficient, or anything like that.
What I was really getting at was that if all we do is a perimeter defense in which we can associate each device with a user, then we can apply security policies that are about controlling the behavior of users (separating them into groups, etc.), but if we want to do as you suggest, and authenticate and authorize devices such as bridges that do not belong to any specific user, then there are some problems that are (or may be) addressed differently.
Peter K. Boucher
Rappore Technologies
www.rappore.com
-----Original Message-----
From: owner-stds-802-linksec@majordomo.ieee.org
[mailto:owner-stds-802-linksec@majordomo.ieee.org]On Behalf Of Mick
Seaman
Sent: Friday, December 20, 2002 1:17 PM
To: 'LinkSec'
Subject: RE: [LinkSec] Thoughts on high-level requirements
My apologies for having to repeat this, but for perimeter defence to be useful, authorisation on the basis of a MAC address is not sufficient.
What may be added at the perimeter is a network, or a fraction of a network, with a number of MAC addresses that may only apear over time. This is the case where an access link is provided by a service provider to a customer organization to carry layer 2 services (a.k.a bridging). The model of a network as having a fixed perimeter with only individual devices (a.k.a laptops) seeking to access the network only covers half the perimeter security space - roughly the 802.11 half as we know it today. It leaves out the EPON to business customer scenario.
The incomplete document I distributed as an attachment on Tuesday 12/10 has part of this scenario in it (Mutual Authentication & the Growing Network).
The "something generic" that Mike refers to below can start with securing the perimeter of the network where RSTP is running, only admitting another part when the RSTP bridge that joins the two parts has been authenticated and authorized.
In a network where all the internal links are point-to-point and bridged this works quite well, where EPON plays in this business scenario it will probably start of being used point-to-point, and authenticating and authorizing each node/bridge at the edge of the EPON before it can join in STP works well too in the advanced scenario.
Mick
> -----Original Message-----
> From: owner-stds-802-linksec@majordomo.ieee.org
> [mailto:owner-stds-802-linksec@majordomo.ieee.org]On Behalf Of Mike
> Moreton
> Sent: Friday, December 20, 2002 8:55 AM
> To: LinkSec
> Subject: RE: [LinkSec] Thoughts on high-level requirements
>
>
>
> Peter,
>
> One viewpoint on this:
>
> If you want perimeter security, it can only be sensibly
> implemented at the link layer. The one business requirement
> that the group definitely has is EPON, which seems to want
> perimeter security. So whatever else you do, I think you
> have to do perimeter security.
>
> On the other hand, peer to peer security can generally be
> achieved at the network layer, and if the user isn't prepared
> to set-up peer-to-peer security at the network layer I don't
> see why they would be prepared to do it at the link layer. I
> haven't seen anyone suggesting there is a business
> requirement for peer-to-peer link layer security.
>
> The only group of protocols that seems to be left is link
> layer maintenance protocols like STP and 802.11 management
> frames. No-one seems greatly to care about securing them -
> maybe they're best left to the groups responsible for them
> rather than attempting to do something generic.
>
> Mike Moreton, Synad Technologies.
>
>
>
>
>
> -----Original Message-----
> From: Peter Boucher [mailto:pboucher@rappore.com]
> Sent: Friday, December 20, 2002 4:22 PM
> To: LinkSec
> Subject: [LinkSec] Thoughts on high-level requirements
>
>
>
> In our last teleconference we all seemed to agree that it
> would be useful to look at business model requirements as a
> way to ensure that the technical requirements we settle on
> are all addressing important business concerns.
>
> It seems to me that there are really two or more business
> models we could try to address. For example, service
> providers want to prevent theft of services and protect
> customers from each other, while enterprises may want us to
> help solve a different set of access control problems, and
> government may want to rely on us to help ensure that certain
> sensitive-but-unclassified data is secure from users who
> don't need-to-know, and thus are not authorized (by law) to
> gain access.
>
> Some questions arise: Do we pick one model and ignore the
> others? Do we try to come up with a one-size-fits-all set of
> technical requirements that will address all of the business
> concerns of all of the models? Do we create a set of (not
> mutually incompatible) standards, one for each model?
>
> Another area of high-level requirements related to the above,
> but interesting in its own right, is whether we do link
> security only as a perimeter-defense, or pervasively
> throughout the network. If we simply defend the perimeter,
> then each MAC address (for example) can be associated with a
> user, but if we are also supposed to secure the spanning-tree
> protocols and other communications between bridges, then some
> devices are not operating on behalf of any specific user.
>
> Again: Do we do perimeter-defense and ignore the internal
> communications? Do we try to come up with a comprehensive
> set of technical requirements that will address both sets of
> concerns? Do we create a pair of (not mutually incompatible)
> standards, one for each model?
>
>