This topic describes the process by which applications that perform their network communications via a mechanism other than DCE RPC can use GSSAPI and DCE security to authenticate and otherwise protect their communications. (These alternative communications mechanisms are called peer-to-peer, to distinguish them from RPC.)
In peer-to-peer communications, the application component that establishes the secure connection is called the context initiator or simply initiator. The context initiator is analogous to a DCE RPC client. The application component that accepts the secure connection is called the context acceptor or simply acceptor. The context acceptor is analogous to a DCE RPC server.
The peer application components establish a secure connection in the following way. (The reader will notice that the underlying security aspects are identical to those of the preceding RPC case, the only differences being in the explicit routine-invocation and communications aspects.)
1. The context initiator uses the gss_init_sec_context( ) routine to request from the DCE security server a service ticket (as previously described) that will allow the initiator to talk to the context acceptor.
The initiator's security runtime creates an envelope that contains:
· The initiator's PTGT
Note: It is assumed that the initiator's security runtime already possesses a PTGT; that is, GSSAPI itself does not handle login.
· The acceptor's principal name, protected under conversation key 5
The initiator's security runtime sends the envelope to the TGS. (As in Authenticating an ApplicationAuthenticating an Application, step 4, this communication happens via RPC, but this use of RPC is hidden from the application because it's an implicit RPC being made by the security runtime, not an explicit RPC by the application initiator itself.) The TGS issues a service ticket to the initiator, encrypted in the acceptor's secret key, exactly as described in Authentication Using Authenticated RPC, step 5.
2. The initiator's security runtime recovers conversation key 6 as described in Authentication Using Authenticated RPC, step 6, and then hands to the GSSAPI the service ticket (including EPAC chain) and conversation key 4.
3. GSSAPI holds onto conversation key 6 and creates a GSSAPI token containing the service ticket.
This GSSAPI token is then returned to the initiator, which forwards it to the acceptor (via the application's chosen communications mechanism). (Compare this with Authentication Using Authenticated RPC, step 6.)
4. The acceptor calls the gss_accept_sec_context( ) routine, which passes the token to the acceptor's security runtime.
5. The acceptor's security runtime processes the token, in particular recovering conversation key 6, exactly as described in Authentication Using Authenticated RPC , step 7.
6. The acceptor's GSSAPI holds onto conversation key 6 and the EPAC chain, and creates a GSSAPI token containing the success message. It passes the token to the acceptor. (Again, refer to Authentication Using Authenticated RPC, step 7.)
7. The acceptor forwards the GSSAPI token to the initiator.
8. The initiator passes the token to its GSSAPI, which sends it to the security runtime by calling the gss_init_sec_context( ) routine again.
9. The initiator's security runtime tries to decrypt the message. If this succeeds, it returns a success status to the GSSAPI that the acceptor's identity is authenticated. If not, it returns a failure status to the GSSAPI. (Compare this to Authentication Using Authenticated RPC, step 8.)
The context acceptor and context initiator can then use conversation key 6 in future communications by calling the gss_sign( ) and gss_seal( ) routines. (Compare this scenario with the RPC remarks following Authentication Using Authenticated RPC, step 8.) The context acceptor can get the initiator's EPAC chain in the form of an rpc_authz_cred_handle_t object so it can perform a DCE ACL check by calling the gssdce_extract_creds_from_sec_context( ) routine. If the context initiator wants to talk to a different context acceptor, it must acquire a ticket to that context acceptor.