IntelliGrid Architecture

Identity Establishment Service

An identity establishment (e.g. identity authentication) service is concerned with verifying proof of an asserted identity. The implementation of the service must allow for multiple identity authentication mechanisms (e.g. identity tokens) to be utilized. Additionally, the service needs to provide a mechanism to allow the information from various identity tokens/identity authentication mechanisms to be electronically conveyed.

The requirement that the Identity Establishment service be agnostic in regards to technology can be easily demonstrated. One Security Domain may make use of a User ID/password combination as an identity token. Another Security Domain may require the use of Kerberos based identity tokens. It is the Security Management Infrastructure (SMI) and the Security Domain’s security policies that will determine the actual identity token(s) used and the mechanism(s) through which they are conveyed.

Key definitions:

identity authentication: The performance of tests to enable a data processing system to recognize entities. Note: An example of identity authentication is the checking of a password or identity token. [2382-pt.8]

identity token: 1. A device, such as a metal key or smart card, used for identity authentication. [After 2382-pt.8] 2. [A] Smart card, metal key, or other physical object used to authenticate identity. [INFOSEC-99]

identity validation: Tests enabling an information system to authenticate users or resources. [INFOSEC-99]

Identity Establishment for Physical Assets

Physical access control should be based upon multi-factor Identity Establishment. The use of multi-factor authentication, using the appropriate technologies can provide a significant security advantage above and beyond simple identity cards. Additionally, the selection and creation of physical access control policies and procedures would needs to include the capability to manage and revoke access privileges easily. This would typically indicate the need for some type of token/id that can be managed/changed. However, if only the picture matching the holder of the identity card determines access, there is a high probability that such access control mechanisms can be falsified. Thus, to improve access security there should be another security factor used in order to authorize access.

This “other-factor” should be “something the individual knows” (e.g. username/password) or combination code. However, typically username/passwords or combination codes can be compromised through observation or garbage diving. Therefore, it would be recommended that some type of electronic mechanism, with verification/challenge be implemented. The most widely deployed example of this would be the use of a Smart-ID card (e.g. a card that electronically authorizes the holder to enter a combination and that explicitly bound to the identity of the holder) and a combination lock. Only the proper Smart-ID badge authorization allows the combination to be entered into the lock, which then enables access. The side benefit of the use of such technology is that an audit trail of access can be created electronically. Additionally, management issues (especially revocation of access privileges) are eased since the Smart-ID card can be revoked thereby disallowing access.

Should a Security Domain decide to perform electronic auditing of physical access (recommended), then appropriate audit trail time-stamping techniques need to be utilized (see the audit service section).

Computational Resources

Identity establishment, for computational resources, is directly related to the types of credentials that are in use within a Security Domain. The definition of the credentials that IntelliGrid Architecture may be using may be found in the Credential Renewal section (see page 2-20). The credential types used to establish identity are: addresses and address resolution, username/passwords, smart cards, digital certificates, and biometric identifications.

The issue with computational resource identification establishment is that of architecting a solution that creates a framework for authentication. Table 15 and Table 16 list relevant references and specifications that may aid in the construction of such a framework within a security domain.

Table 15: General References Regarding Identity Establishment and Identity Infrastructure

Table 16: Relevant Specifications regarding Identification Frameworks

Technological Assessment and Relevant Specifications

The following section discusses issues and potential general resolution to the issues regarding the use of any particular identification mechanism. In general, two-factor authentication is desired.

Address Resolution

The most prevalent issue in using address resolution as an identification mechanism is address spoofing. This attack is easy to generate and is well documented. Therefore, such an identification mechanism should not be used on its own. It must be augmented with another factor to actually establish the identity.

Address resolution is a worthwhile qualifier for actions/information exchanges that are only supposed to occur between certain peers. However, this is not a reasonable mechanism for inter-domain exchanges since neither domain controls the other domain’s address allocation/changes.

Username/Password

This is a typical mechanism employed by Web based interfaces (especially for customers interfacing for retrieval of billing information). However, the use of cookies or password caches (e.g. the prompt to remember the username password) represents an issue that should be addressed by the addition of a challenge/response mechanism.

The challenge response should be user selectable/definable so that they can remember the response when prompted.

Smart Cards

The references given previously in this section give a large amount of guidance in the selection of SMART-CARDS that can be used in the implementation of physical or cyber access control. The smart card industry embraces ISO 7816 as one of the prevalent smart card specification and this is the recommended base specification for smart cards.

However, ISO 7816 does not specify a programmatic interface to such cards that is portable. Therefore, it is recommended that the Java CardTM Platform Specification be used in conjunction with ISO 7816 technology.

The remaining issue is how much storage to deploy on the smart cards. The Gartner Group published the information found in Figure 2. At this juncture there is no recommendation in regards to the amount of storage to deploy.

Table 17: Relevant Standards Concerning Smart Cards

Figure 2: Estimated Smart Card Storage Costs

Digital Certificates

The industry accepted digital certificate is an X.509 certificate. This is the certificate format that should be used by IntelliGrid Architecture when applicable. There are some issues in identifying a certificate:

·       There is an issue in regards to how to uniquely identify a certificate. There are many fields that could be used, however only the certificate Thumbprint is truly unique. All other fields could be non-unique. Therefore, it is the thumbprint that should be used to identify and match certificates.

·       Enunciation of lifetime expiration (see Credential Renewal service).

·       Policy issues in regards to use will need to be addressed. The NERC e-Marc certificate policy discusses many of these issues. It is recommended that the e-Marc policy be used as a basis for certificate usage.

It is worthwhile to note that the NERC policy does not allow the same certificate to be duplicated. Should a security domain adopt this as a policy, the number of certificates required (e.g. in the case of redundancy) will be higher.

·       A policy in regards to how applications should react in the case that an in use certificate is revoked.

Revocation is basically caused when the integrity of a certificate has been compromised (e.g. the private certificate may have been stolen). Since none of the revocation protocols give an indication that could be used to determine if the certificate was compromised prior to use, the safe option is to terminate use of the certificate upon revocation. This may cause information exchange to be terminated if fail-over procedures are not made part of the policy.

Table 18: Public Key Infrastructure (PKI) Related Specification/Standards

Digital Signatures

Typically considered a subset of Digital Certificates, as certificates are required in order to digitally sign, these have their own benefit for identification purposes. In instances where bandwidth or packet size is a limiting factor, a digital signature can be used in place of a certificate.

In IEC 61850, for GOOSE, this signature, in conjunction with address resolution would provide two-factor authentication if properly implemented. However, this raises the issue that:

·       Digital signatures should not repeat often in order to prevent spoofing.

There are several different interpretations in regards to what a digital signature is.

It is recommended that RFC 2313 be used as the definitive definition for a digital signature algorithm:

“For digital signatures, the content to be signed is first reduced to a message digest with a message-digest algorithm (such as MD5), and then an octet string containing the message digest is encrypted with the RSA private key of the signer of the content. The content and the encrypted message digest are represented together according to the syntax in PKCS #7 to yield a digital signature.”

However, it is recommended that RFC 2437 be the actual Cryptography specification used[4]

Table 19: Relevant Specifications for Digital Signatures

Biometrics

There is a large body of biometric work occurring. The standards development is largely being performed in ISO JTC1 SC37. The total scope of work can be obtained from www.jtc1.org. However, some of the major work items have been included in Table 20. The major focus of ISO JTC1 SC37 is focused on the biometric aspects of fingerprints and facial images. However, from a practical perspective fingerprint biometrics represents a much lower cost alternative than facial and therefore would be recommended for IntelliGrid Architecture deployment.

It is also suggested that the biometric data be encoded on a smart-card so that two-factor authentication is achievable.

Table 20: Relevant References regarding Biometrics

Table 21: Relevant Specification regarding Biometrics and Smart Cards