semi合集-English.pdf - 第3356页

SEMI E132-0305 © SEMI 2004, 2005 9 11 Authorization 11.1 Authorization Overview 11.1.1 Any client wishing to i nvoke privile ged services on the equipment m ust be authorized to do so. Authorizati on is im plemente d by …

100%1 / 7923
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.
SEMI E132-0305 © SEMI 2004, 2005 9
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.
SEMI E132-0305 © SEMI 2004, 2005 10
id
Subject
privilegeId
Privilege
ACLEntry
Principal
Role
subject
11
PrivilegeAssignment RoleAssignment
privileges1
1..*
principal
1
1
role1
1
Figure 7
ACL Entry Description
11.2.4 ACLEntry
11.2.4.1 Figure 7 shows the classes used for requesting the creation of a new ACLEntry on the equipment (see
Section 12.3.2.3). The ACLEntry is an abstract base class for the two kinds of ACL entries, PrivilegeAssignment,
and RoleAssignment. There can be only one ACLEntry for each subject. Attempts to add a second entry for same
subject shall generate a duplicate entry error (see Section 12.3.2.3). This class has no attributes or associations.
11.2.5 PrivilegeAssignment
11.2.5.1 This class defines an association between a given subject (either a Principal or a Role) and its set of
assigned privileges on the equipment. A PrivilegeAssignment for a Principal establishes all privileges that are
specifically granted to the Principal. A given Principal must either have a PrivilegeAssignment ACLEntry or a
RoleAssignment ACLEntry (see Section 11.2.6); it cannot have one (or more) of each. A PrivilegeAssignment for a
Role defines the role itself and the privileges that will be granted to any Principal that is assigned to that Role (see
Section 11.2.6). There can be only one PrivilegeAssignment ACLEntry for a given Role.
Table 8 PrivilegeAssignment Association Definitions
Association Role Name Definition Comments
subject The Principal or Role that is being granted privileges. One and only one element of any type
derived from Subject, described in
Section 11.2.7.
privileges The set of privileges being granted. List of one or more elements of type
Privilege, described in Section 11.2.10.
11.2.6 RoleAssignment
11.2.6.1 This class assigns a specific Principal to a Role. The identified Role must have a PrivilegeAssignment
ACLEntry elsewhere in the ACL. All privileges assigned to the identified Role are granted to the identified
Principal’s sessions. A given Principal must either have a RoleAssignment ACLEntry or a PrivilegeAssignment
ACLEntry (see Section 11.2.5); it cannot have one (or more) of each.
11.2.6.2 A PrivilegeAssignment ACLEntry for a Role cannot be deleted from the ACL until all Principals that were
assigned to that Role have been removed from it by deletion of their RoleAssignment ACLEntry. Any authenticated
sessions that were established for such Principals prior to the deletion of their RoleAssignment ACLEntry shall
continue to be operable with that Role’s privileges until the session is terminated. Subsequent attempts by such