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
>
>