Re: RE: [LinkSec] Requirements
Clint:
We can easily fix this. The factory assigns a MAC address. This can be
authenticated if we install the mechanisms to do so. If the protocol
environment requires the use of other MAC addresses (DECnet does), then a
local authority can build on the authentication of the factory-installed
MAC address to manage the translation.
Russ
At 08:35 AM 12/12/2002 -0800, Clint Chaplin wrote:
>And yet, the real problem is that the MAC address is not fixed, and can
>easily be spoofed.
>
> >>> "Walker, Jesse" <jesse.walker@intel.com> 12/11/02 11:55 AM >>>
>
>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. ddress, 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) mtual 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
> > >
> > >
> >
> >