RE: [LinkSec] Requirements
Russ,
Certainly the identity of whoever is doing the protection/encryption needs
to be known (or easily guessable - but we needn't go down that hole for the
moment) at layer 2, but the form of that identity depends on how far away
from it the "remote enforcement" as you term it takes place.
The identity only needs to distinguish those who are allowed to transmit on
a link if envforcement is restricted to the other end of the link,(obviously
intruders can't be relied upon to uniquely label themselves!) so the
identity on a point to point protected link can simply be "the other end of
this link".
Some of the MACs in design (.17, .3ah have or are considering - a murky
subject in itself) a source station identifier that is unique only to that
LAN (I would prefer it to be a globally unique 48-bit address for robustness
of design, but it is an issue local to the MAC, and in at least one case I
believe they are considering a 16 bit id). So on a shared media LAN of those
types there is an identifier (in each bridged frame) of the last MILS-SAP
(MAC Internal Layer Service Service Access Point) that a frame got bridged
through. I would be surprised if other MACs have not got useable local
identifiers, although protection of control traffic to the point they
acquire these is a difficult task, that traffic at least has as its end
points MAC addressed entities).
The last MIL-SAP identifier can be generalised as a concept across shared
LANs requiring protection, although it may change size etc. etc.
Mick
> -----Original Message-----
> From: owner-stds-802-linksec@majordomo.ieee.org
> [mailto:owner-stds-802-linksec@majordomo.ieee.org]On Behalf Of Russ
> Housley
> Sent: Wednesday, December 11, 2002 2:14 PM
> To: mick_seaman@ieee.org
> Cc: stds-802-linksec@ieee.org
> Subject: RE: [LinkSec] Requirements
>
>
>
> Mick:
>
> This looks like it is going to be a good debate. Several beers will
> probably be needed to settle it. Either that, or we already
> violently
> agree and are using different words to describe it.
>
> >I could not diagree more with the statement "At this layer,
> the MAC address
> >is the identity that should be authenticated".
> >
> >What you want to authenticate depends on what you want to
> allow. If you want
> >to allow someone using a PC to access a network through a
> network access
> >point/network access port you want to be able to
> authenticate the person
> >using (with trusted authority over) the PC and then securely
> associate all
> >the frames from and intend for with the PC's own attachment
> to the LAN, i.e.
> >with its M-SAP in architectural speak. An M-SAP is not the
> same as M-SAP
> >address.
> >
> >This may become clearer if you consider
> authenticating/authorizing the
> >attachment of a bridge to secured LAN. The addresses used by
> the bridge may
> >be reasonably unknown at authentication/authorization time,
> and the address
> >associated with the bridge port for management protocol
> purposes is only
> >peripherally relevant (it could change it without any impact on the
> >authorized communications). What needs authenticating are
> the credentials
> >that the bridge has for placing traffic on the secured LAN
> (or segregated
> >portion of the LAN) and what needs authorizing is
> transmission and reception
> >at the M-SAP (the MAC Internal Layer Service uses the same
> M-SAPs as the MAC
> >Service).
>
> If you want distributed or remote enforcement to occur at
> layer 2, then the
> identity must be meaningful at layer 2.
>
> The points that you make support my assertion that
> higher-layer identities
> may need to be authenticated in the authorization process.
> In your first
> example, the identity of the human using the PC is being
> authenticated,
> then an M-SAP is enabled (or disabled) based on the success
> (or failure) of
> the authentication. Now, if remote enforcement of an access control
> decision that is based on the identity of the human user is
> to be performed
> at layer 2 (perhaps packet filtering), then for the duration of the
> session, the MAC address needs to be associated with the
> privileges of that
> human user.
>
> Russ
>
>