4.3.8 Authentication Options Using H.350

There are two options for authentication at this point:

1. Use the username / password stored in the h235Identity or sipIdentity attributes
2. Use the Enterprise username / password directly.

For the latter approach, the gatekeeper or SIP proxy would need to be trusted by the enterprise directory server. The trust relationship is necessary in order for the server to have access to user passwords. Access to the passwords is necessary in order for the call server to verify the password presented by the user via the endpoint. This scenario may not be permitted by the managers of the enterprise directory service.

As an alternative, the H.350 service manager can utilize the user's enterprise credentials to "unlock" the protocol-specific credentials. In this scenario, both the endpoint and the gatekeeper will use the security credentials stored in the commObject associated with the current endpoint. The endpoint will access the commObject in order to retrieve its configuration including the h235IdentityID / h235IdentityPassword or userCertificate, as needed, and similarly for a SIP endpoint. The advantage of this approach is that the endpoint and gatekeeper will be using the same data store so they will naturally be using the same secret to negotiate the authentication. The endpoint can access the H.350 LDAP server with the user's enterprise credentials and the gatekeeper can access the H.350 LDAP server with its own privileged credentials. This approach leverages the enterprise authentication system to access other credentials stored elsewhere. Yet it hides this fact 'behind the scenes' so that the end-user is completely unaware that a separate password is being using to negotiate the H323 or SIP authentication. All the user must do is to present their enterprise authentication credentials. This approach also offers some autonomy between the H.323 system and the enterprise system.

The greatest drawback is management of the h235Identity or sipIdentity credentials. How does one set the credentials? Should they be permanent? If they change, how frequently should they change? Also, some care must be taken in configuring the H.350 server to assure that, in addition to the callserver's access to the videoconferencing credentials, only the owner of a password is able to read or retrieve that password. This problem is discussed in further detail in section .

Other scenarios are certainly possible. For example, a SIP proxy employing an some relational database could possibly be configured so that authentication is actually accomplished at a separate authentication service. As another example, a gatekeeper could possibly make use of a RADIUS server to directly authenticate with their enterprise credentials. The main shortcoming of any such approach is that they rely on standards-based but non-standardized approaches to their interconnection; so, it is hard to predict how one service might tie into another. Therefore, each protocol requires that if authentication is used, it must be from client (endpoint) to application server (call server). Any implementation interested in leveraging enterprise credentials needs to be able to stuff its solution into this basic constraint.