4.1.23 How does security context get established between client and server?

 

Olivier Onimus

(July, 1998) : This is done by sending client's credentials. The server can authenticate the client and get the session key with which the communication will be encrypted. Then the communication will be encrypted, using this context. The credentials are not sent anymore, only a reference on an existing context.

Jonathan Biggar

(July, 1998) : [in addition to the above] The encryption is optional, depending on the Quality of Protection (QoP) you have chosen.

Nick Battle

(July, 1998) : [in addition to the above] The Credentials object (capital C) isn't naively transported to the target in an object-relocation sense, though part of the originator's Credentials are re-instantiated at the target (where they're known as received credentials) so that they can be queried for such things as the user's credential attributes.

It's important to realise that these received credentials are not identical to the originator's since (for example) they may not necessarily be used for making further on going associations (called delegation), and they certainly won't allow the target to set_attributes (eg. change the current active role of the client). Perhaps "reconstructed" is a better way to view it.

The session key doesn't actually come from the initiator's Credentials, but rather from a complex (and mechanism specific) protocol message that is separate from the Credentials data - look at the SECIOP protocol EstablishContext message and the specific message contexts for mechanisms such as Kerberos and CSI-ECMA.

[ed: The communication is encrypted] if that's what policy requires. The message may just be integrity protected, or it may require no protection at all. There is also replay protection which is context based.

Subsequent SECIOP messages are all MessageInContext, quoting the context reference that was created when the target was first contacted.