semi合集-English.pdf - 第3355页

SEMI E132-0305 © SEMI 2004, 2005 8 client to sign, preventing replay. error Illegal or unexpected message. error Defined by the specific authentication protocol used. Table 6 Client Authenticate Parameter Defin itions Pa…

SEMI E132-0305 © SEMI 2004, 2005 7

same. Specifics of algorithms and protocols will be detailed in a separate technology mapping specification. The

terms server and equipment are used interchangeably.

10.1.1 Session Request — This message requests the equipment to initiate establishment of an authenticated session.

Upon receiving this message, the equipment begins the authentication handshake as shown in Figure 5. If the

request is not accepted, the equipment responds with a protocol specific alert or error message and terminates the

connection, see Equipment Challenge.

10.1.2 Equipment Challenge — After the session request is accepted, the equipment responds with a challenge. The

equipment selects the algorithms to be used for authentication (if applicable), provides its own identification and

challenges the client to authenticate itself. The challenge can be a simple request to client to prove its identity. Note

that errors can be returned instead of the normal parameters. Additional errors may be needed as required by the

implementation protocol used to support the concepts.

10.1.3 Client Authenticate — The client responds to the server challenge, confirming the algorithms selected (if

applicable), equipment’s identification and also presents proof of client’s own identity. The proof is typically a hash

of some random data encrypted with a key that only the client would know and that the server can verify. A secret

unique to the authentication protocol may also be generated by the client and sent to equipment in the response.

Actual algorithms used for exchange of this secret will be defined by the specific authentication protocol specified in

the adjunct standard.

Client Equipment

Session Request

Equipment Challenge

- Algorithms

- Equipment ID

- Challenge

Client Authenticate

- Client Id

- Session Secret

- Client Id Proof

Client Authenticated

Equipment ACK

- ACK

Session

Authenticated

Client Verify

Equipment Verify

Figure 5

Authentication Message Flow

Table 5 Equipment Challenge Parameter Definitions

Parameter Description Kind Form

Algorithms Identifies the cryptographic algorithms to be used for key

exchange, one-way hash functions and data encryption.

OUT Text, with delimited

fields to identify the

algorithms used.

Equipment Id Equipment identity, exact format as defined by the protocol chosen,

and can be as simple as a name identifier such as in a password-

based scheme.

OUT Text.

Challenge Request for client to authenticate itself, contains random data for OUT Text.

SEMI E132-0305 © SEMI 2004, 2005 8

client to sign, preventing replay.

error Illegal or unexpected message. error Defined by the specific

authentication protocol

used.

Table 6 Client Authenticate Parameter Definitions

Parameter Description Kind Form

Client Id Client identity, exact format as defined by the protocol chosen, and

can be as simple as a name identifier such as in a password-based

scheme.

IN Text.

Session Secret Randomly generated data unique to the authentication process.

This is encrypted using the equipment’s public key or an

established shared secret key, depending on the actual protocol

used and algorithm chosen for key exchange.

IN Text, encrypted.

Client Id Proof Encryption on some random data using a secret that only this client

would know, proving client’s claim of identity. This serves as a

signature. The random data can be the data from equipment’s

challenge or derived from it.

IN Text, encrypted.

error Illegal or unexpected message. error Defined by the specific

authentication protocol

used.

10.1.4 Equipment ACK — Equipment verifies client’s response and confirms the exchanged session secret in this

final authentication protocol message. The acknowledgement contains a parameter that can be a hash of the secret

or its derived secret. The derivation algorithm for derived session secret is known both to the equipment and the

client, and is part of the protocol specification. This allows client to verify the exchange by verifying the hash.

Subsequent communication over the session will make use of the derived secret keys. Note that this standard does

not require data be encrypted over the established session, the derived secret is only used to identify the session and

hence the authorizations of the authenticated client. Additional errors may be defined as required by the protocol

chosen, and technology used by the implementations.

Table 7 Equipment ACK Argument Definitions

Parameter Description Kind Form

ACK Hash of data derived from the exchanged session secret, this proves

equipment’s correct decryption of the secret. Hash algorithms as

agreed to at the beginning of handshake.

OUT Text, encrypted.

error Illegal or unexpected message received. error Defined by the specific

authentication protocol

used.

error Illegal parameter. error Defined by the specific

authentication protocol

used.

error Authentication failure. error Defined by the specific

authentication protocol

used.

10.2 Session Identifier

10.2.1 The session id returned from the EstablishSession request (Section 13.2.6)

can be used to identify the session

for subsequent communications and to enforce authorizations. The identifier will be embedded in special headers in

the message transport, and not as formal parameters in the communication messages thus preserving their original

structure as defined by the respective interface specifications.

11 Authorization

11.1 Authorization Overview

11.1.1 Any client wishing to invoke privileged services on the equipment must be authorized to do so.

Authorization is implemented by granting access control privileges beforehand to defined clients and later checked

against the client’s requests. The total set of available privileges may include standardized service-level access

control, such as privileges to invoke specific services or functions, but may also include supplier-defined finer-

grained privileges. A default privilege to allow access to all services available from an authenticated session is

defined in this specification, and must be supported by all implementations. A user of the equipment therefore has

the option to reduce security enforcement on the equipment to authentication alone, achieved by assigning this all-

access privilege to all defined clients.

11.1.2 Figure 6 provides an abstract overview of the relationships among the Role, Principal, and Privilege concepts

defined in this specification. A Principal is either assigned to one and only one Role, or to one or more Privileges.

A Role is defined as a uniquely-identifiable set of 1 or more Privileges, and cannot be composed from other Roles.

Zero or more Principals can be assigned to at most one Role. These relationships are enforced through the

management of Access Control List entries, described in Section 11.2.

Privilege

Principal Role

0..* 1

role

0..*

1..*

privileges

0..*

1..*

privileges

{XOR}

Figure 6

Abstract Model of ACL

11.2 Access Control List

11.2.1 Access control privileges are assigned to defined clients (principals) by using an Access Control List (ACL).

An ACL is a collection of ACL entries, each entry granting a subset of the available privileges to a specific subject.

A subject can represent a specific principal, a uniquely-named role, or all principals that successfully authenticate

with the equipment. A principal can have privileges granted to it through either an explicit list of privileges, or

indirectly through assignment to a role. The equipment shall maintain the ACL defined in this specification in non-

volatile memory.

11.2.2 Roles are used to simplify the management of privilege assignments to principals. Each unique role has an

ACL entry that specifies the privileges assigned to that role. Those privileges can then be granted to principals

through a RoleAssignment ACL entry for each principal that should have those privileges. A principal must either

have a RoleAssignment or an explicit list of privileges assigned to it (PrivilegeAssignment); it is not permitted to

have both.

11.2.3 The equipment shall refuse session requests from clients that have no ACLEntry, either explicitly through a

role or privilege assignment, or implicitly through the existence of an ACLEntry for all authenticated principals.