semi合集-English.pdf - 第3354页

SEMI E132-0305 © SEMI 2004, 2005 7 same. Specifics of algorithms and protocols will b e detailed in a separate technology mapping specification. The terms server a nd equipm ent are used interchangea bly. 10.1.1 Session …

100%1 / 7923
SEMI E132-0305 © SEMI 2004, 2005 6
communicate the credentials will not be defined in this document, and may be as simple as configurations inside the
client application.
9.2.2 Client — The client holds any issued credentials assigned to it, and authenticates to the equipment to establish
an authenticated session.
9.2.3 Equipment — The role of equipment in the administration model is to establish the security admin entity for
the equipment, hold any defined authorizations, authenticate clients to establish a session, determine client
authorization levels and enforce them for the established session.
9.2.4 Interfaces — The authentication, administration, and session establishment interfaces will be defined in later
sections along with the concepts of establishing client identities and authorizations, though the actual technology
and protocols used maybe defined in further detail in a separate adjunct standard.
9.3 Challenge/Response Authentication
9.3.1 The authentication process begins when a client first attempts to establish a communication session with the
equipment. Upon receiving this request, the equipment challenges the client to prove its identity to the equipment.
The client must encrypt some session-generated data using a private or secret key (e.g. a password) that only the
claimed client would know. The equipment can verify client’s claim using the corresponding public key or shared
secret key assigned to the client to decrypt the data, if decrypted data matches plaintext then client is verified.
9.3.2 For communication technologies in which a separate outgoing connection must be established in order for the
equipment to send events, the equipment must also verify that the receiving address is valid. This is achieved by
sending a ping message to the client endpoint (see Section 15.1.1). This specification currently does not define a
mechanism by which a client can transfer an established session to a different endpoint.
9.4 Authorization
9.4.1 Any client application 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 general operational flow is as follows:
Authentication and Credentials Exchange — Client application authenticates to equipment as to its identity and
establishes an authenticated session.
Session Established — Equipment optionally caches client application’s privileges and associates these
privileges with the newly-created session.
Service Request — Client application makes a service request.
Privilege Validation — Equipment validates the client application’s request against its assigned privileges.
Session Closed — Client application closes session, all session state information are reset or cleaned.
9.4.2 Since the client does not authenticate itself for each service request, privilege validation is performed against
the authenticated session created for that client. This does not necessarily mean that the implementation of a session
requires the use of a stateful or connection-oriented communication protocol, or that authentication must be
performed during every protocol-level reconnect. If the implementation protocol is connectionless, the session can
be identified by some mutually agreed upon session identifier, negotiated during the authentication process required
to establish a session.
NOTE 2: This specification does not define a mechanism for controlling end-user access to equipment services or information.
The authentication and authorization scheme defined in this specification applies at the application level only. Management of
end-user access to equipment functions and information is strictly the responsibility of applications that make use of the
authenticated communication sessions defined in this specification.
10 Authentication
10.1 Authentication Message Flow — The authentication message flow during a normal session establishment is
presented in Figure 5. Arrows represent the major messages exchanged during the handshake, with side notes
clarifying the key data exchanged in each message. Depending on the actual messaging/transport protocols and
encryption algorithms used, some additional messages or data parameters may be added, but the concept remains the
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.