FW: [LinkSec] Requirements
Jesse,
Well that's all very nice, but if you can't accomodate a bridge attaching to
a LAN within your secure architecture then it is going to be irrelevant
(again). If you want to separately authenticate all MAC addresses in the
network to all the access points that they might pass through that's nice
but it certainly isn't the solution that any of us working on MAN Service
provision with secured LAN access points would find scaleable, or just plain
workable.
By the way, I'm not talking about a new 802 architecture here, just the one
that happens to be deployed.
This all depends what you want to secure, and until we have a model of how
the network(s) of interest is put together at the system level - which means
at least LANs bridged together - I don't think we are going to make much
progress. If our vision on this project is limited to securing each possible
pairwise communication between MAC addresses representing the end points of
that communicationm I think we may rapidly conclude that all that was needed
was IPsec running at a higher layer.
Mick
> -----Original Message-----
> From: owner-stds-802-linksec@majordomo.ieee.org
> [mailto:owner-stds-802-linksec@majordomo.ieee.org]On Behalf Of Walker,
> Jesse
> Sent: Wednesday, December 11, 2002 11:51 AM
> To: 'mick_seaman@ieee.org'; stds-802-linksec@ieee.org
> Subject: RE: [LinkSec] Requirements
>
>
>
> Mick,
>
> I have to agree with Russ. The usual technique is exactly as Russ has
> described.
>
> In this some higher layer entities are first authenticated. As a side
> effect of the authentication process a key is defined. The
> key represents
> the authorization decision that followed from authentication,
> in the sense
> that by using the someone can "prove" they are authorized to
> do some action.
> In our case the "some action" authorized is to utilize the data link
> channel.
>
> Since one only wants authorized parties to use the key, the
> usual strategy
> is to bind the key to the identifiers used at the level of
> the transaction.
> The reason for doing this is three-fold. First, this strategy
> amortizes this
> authentication over a series of transactions, so that a full
> reauthentication can be avoided on every subsequent packet
> exchange. Second,
> as an efficiency matter the receiver of a message does not
> want to try every
> key it knows to determine its origin. Third one--and this is
> important for
> security--one wants to be able to detect abuse of the key,
> where one party
> might try to use it for some purpose that it was not intended for.
>
> So in a very practical sense, on a packet by packet basis the key is
> attesting to authentication in exactly the way Russ
> described. The only
> possible identifier for the key that can be used at this level are MAC
> addresses, unless of course someone wants to invent a new 802
> architecture.
>
> -- Jesse
>
> > -----Original Message-----
> > From: Mick Seaman [mailto:mick_seaman@ieee.org]
> > Sent: Wednesday, December 11, 2002 11:46 AM
> > To: stds-802-linksec@ieee.org
> > Subject: RE: [LinkSec] Requirements
> >
> >
> >
> > Russ,
> >
> > 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).
> >
> > 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 10:50 AM
> > > To: PaulLambert@AirgoNetworks.Com
> > > Cc: stds-802-linksec@ieee.org
> > > Subject: Re: [LinkSec] Requirements
> > >
> > >
> > >
> > > Paul:
> > >
> > > At this layer, the MAC address is the identity that should be
> > > authenticated. An authorization decision may require
> > > authentication of a
> > > higher-layer identity.
> > >
> > > 1.b) Integrity of what? Source address, dest. address,
> payload, ....
> > >
> > > 3.d) Strong agreement for peer-to-peer key management
> > >
> > > 4.b) Strong agreement that the protocol must be algorithm
> > > independent. Lack of algorithm independence has made WEP
> much more
> > > difficult to fix.
> > >
> > > 5) Maybe we should look at the DOCSIS architecture. Each
> > > cable modem comes
> > > with a MAC address, a private key, and a certificate that
> > > binds the MAC
> > > address to the public key. This means that it can
> > > authenticate the MAC
> > > address. This can be used for key management as well as
> > > other functions,
> > > like enrollment in a particular network.
> > >
> > > Russ
> > >
> > > At 01:28 PM 12/10/2002 -0800, Paul Lambert wrote:
> > >
> > >
> > > >My preliminary view of requirements.
> > > >
> > > >Paul
> > > >
> > > >---- 802 LinkSec Requirements ----
> > > >
> > > >1) Protect 802 Link Level Communications
> > > > a) Provide protection against evesdropping (confidentiality)
> > > > b) Prevent packet modification (integrity)
> > > > c) Provide traffic separation (integrity and confidentiality)
> > > > i) Prevent malicious mixing of traffic
> > > > ii) Identify protected traffic class/identity
> > > > (could be MAC address, vlan, said, etc.)
> > > > e) Specifically protect PONs link communications
> > > > f) Protect broadcast/multicast traffic
> > > > (may or may not need group key mechanism depending on
> > > scenarios)
> > > > g) Protect against replay of messages (optional perhaps,
> > > debatable issue)
> > > > h) Provide capability to use 'strong' cryptographic
> mechanisms
> > > > for link layer protection
> > > > i) Efficient as possible
> > > > i) minimize pdu expansion
> > > > ii) reasonable speed/performance for MAC requirements
> > > (e.g. PONs)
> > > >2) Layering
> > > > a) Be applicable to multiple 802 MAC protocols
> > > > b) Protect bridging protocols
> > > > c) Protect unicast communications
> > > > i) 'pair-wise security', confidentiality, integrity
> > > > ii) mutual authentication of unicast security
> > > > d) Protect broadcast/multicast traffic and protocols
> > > > e) Provide explicit support or guidelines for com
> > > > f) Must handle or provide recommendations for MAC
> > level pdu size
> > > > limitations
> > > >3) Key Management
> > > > a) Provide secure distribution of cryptographic keys for
> > > > Link Layer Protection mechanism(s)
> > > > b) Provide pair-wise key establishment for unicast
> > communications
> > > > c) Support key management independent of MAC type
> > > > d) Should only require 802 protocols between peers
> > > > (note - this does not exclude force the use of 802.1x)
> > > >4) Cryptographic Mechanisms
> > > > a) Provide suitable algorithms for threat/performance
> > > environment of PONs
> > > > b) Not be limited to a single set of algorithms
> > > (algorithm flexibility)
> > > > (should not be construed as allowing any and all
> algorithms)
> > > > c) Provide ability to implement strong cryptographic
> > > encryption for
> > > > confidentiality
> > > > d) Provide ability to support strong integrity checks
> > > >5) Enrollment
> > > > a) Provide centralized management of device enrollment
> > > > i) not limited to a single management system (e.g.
> > > multiple domains)
> > > > ii) provide means to identify management domain
> > > > b) Provide ability to 'disenroll' individual systems
> > > > c) Support strong authentication of devices based on
> enrollment
> > > > d) Provide ad-hoc enrollment (very debatable, e.g.
> 802.11 iBSS)
> > > > i) no centralized enrollment server
> > > > ii) etc. technically viable, many interesting use
> > > case scenarios,
> > > > likely could be split as a unique work item
> > >
> > >
> >
> >
>