Secure Device Identity par p802

Secure Device Identity PAR (P802.1AL)

5 Criteria
1. Broad Market Potential

A standards project authorized by IEEE 802 shall have a broad market potential. Specifically, it shall have the potential for:

1. 
   Broad sets of applicability.
   
2. 
   Multiple vendors and numerous users
   
3. 
   Balanced costs (LAN versus attached stations)
   

DevID has applicability to every IEEE 802 protocol. All networks go through the process of provisioning devices to the network. It is increasingly desirable to authenticate entities attached to the network in a secure fashion, e.g. 802.1X. DevID is specifically conceived to address this need.

The IETF has identified DevID or an equivalent capability as an enabling component of a solution to security issues in several of their protocols, e.g. ARP.
The LinkSec Task Group has representation from multiple vendors all of whom are interested in providing and using this capability. A standardized device identity facilitates interoperable secure device authentication. User organizations have identified this as a desirable capability to simplify and standardize security management in their networks.
DevID will provide its capabilities at low cost relative to the cost of a Silicon MAC integrated circuit, e.g. storage on the order of 1 KB in its minimal configuration, while providing sufficient trust.

2. Compatibility

IEEE 802 defines a family of standards. All standards shall be in conformance with the IEEE 802.1 Architecture, Management and Interworking documents as follows: 802. Overview and Architecture, 802.1D, 802.1Q and parts of 802.1f. If any variances in conformance emerge, they shall be thoroughly disclosed and reviewed with 802.

Each standard in the IEEE 802 family of standards shall include a definition of managed objects which are compatible with systems management standards.
Helps augment the capabilities of existing protocols, such as (.1X, .ae/.af), but does not disturb their relationship to the overall architecture. Going forward, this would provide a standardized foundation for building other authentication protocols within the 802 family.

Can augment / interoperate with existing device IDs, while adding security.

1. 
   As a supplement to IEEE Std 802.1, the proposed project will remain in conformance with the 802 Overview and Architecture.
   
2. 
   As a supplement to IEEE Std 802.1, the proposed project will remain in conformance with 802.1D, 802.1Q, 802.1f.
   
3. 
   Managed objects will be defined consistent with existing policies and practices for 802.1 standards.
   

3. Distinct Identity

Each IEEE 802 standard shall have a distinct identity. To achieve this, each authorized project shall be:

1. 
   Substantially different from other IEEE 802 standards.
   
2. 
   One unique solution per problem (not two solutions to a problem).
   
3. 
   Easy for the document reader to select the relevant specification.
   

1. 
   There is no existing standard that provides the envisaged capabilities for IEEE 802 secure device identification. Furthermore secure DevID is applicable across inter-networks of differing network architectures.
   
2. 
   A single framework is envisaged for the standard.
   
3. 
   This will be a separate standalone standard.
   
4. 
   While there are outside standards that serve a similar purpose, they all have a much smaller scope, etc.
   

4. Technical Feasibility

For a project to be authorized, it shall be able to show its technical feasibility. At a minimum, the proposed project shall show:

1. 
   Demonstrated system feasibility.
   
2. 
   Proven technology, reasonable testing.
   
3. 
   Confidence in reliability.
   

1. 
   DOCSIS and Trusted Computing Group have solved similar problems using substantially similar technological approaches to that envisaged for DevID.
   

5. Economic Feasibility

For a project to be authorized, it shall be able to show economic feasibility (so far as can reasonably be estimated), for its intended applications. At a minimum, the proposed project shall show:

1. 
   Known cost factors, reliable data.
   
2. 
   Reasonable cost for performance.
   
3. 
   Consideration of installation costs.
   

1. 
   Experience with DOCSIS shows that secure device identity may be added to highly cost sensitive devices at minimal additional equipment cost.
   
2. 
   Moreover DevID enabled devices can be incrementally deployed, and thus do not incur large one time capital expenditures before any benefits are realized. Existing devices that do not have DevID capabilities will continue to operate as at present, while DevID enabled devices may be deployed on existing networks while taking advantage of enhanced capabilities as they are deployed in the network.
   
3. 
   DevID has the potential to be added as a retrofit capability to existing hardware in some contexts.
   
4. 
   Secure device identity has been shown to play a significant role in reducing operating expenses by providing reliable device tracking, equipment history logs, etc.