Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

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