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