tslnego handshake leading to session names

Remembering that within ws-trust handshakes of RSTs and RSTR (and RSTR and RSTR) shared BETWEEN THE PEERS we expect to see the components of the SSL handshake, we can document what actually happens for a very obvious setup:


we see the 2 peers, using messages, to signal within ws-trust messages what are actually the SSL handshake messages:


The originator of the flow sends the RST (#1), and thereafter the peers exchange RSTRs (#2, #3, #4).

#1 #2 rougly correspond to the SSL hellos and the key transport messages. #3 and #4 roughly correspond to the SSL derive and agree session key messages.

In #4, we see how the SSL session information get transformed into proof keys, with two responses (Formally) in the single collection response.

What we see is that the RSTR itself can provide proof keys (rather than a signed SAML assertion, stored in the requested security token). WE see that the SCT token actually “requested” is little more than a name, and all the work is done in the proof keys and the proof key authenticator (4.2). Of course the latter plays the role of the SAML assertions signature, ensuring that the #4.1 field binary exchange is authentic.

We then see that this “’Tunnel” is used to send the username token to the server (along with the rest of the SOAP request):


We see 2 derived keys, one of which (_1) is the encryption key for 2 headers and the body. We can guess that header _9 is the username token, and _8 is perhaps the (encrypted) signature of that token. Lets GUESS that derived key _0 is used to symmetrically sign that signature. The derived keys use different bytes of the longer material derived during the ssl session.

This is not really “messaging security”. This is more like a segmented SSL record layer represented in XML (post handshake), with different fragments. There are even 2 SSL-derived SSL sessions going on, to give the encrypted-signed token

Well that was fun. Now I get it (8 years later)!

If we turn off the SSL-centric server cert learning process (and preset the client to know the servers layer 7 cert) we see a more classical messaging exchange that frames 4 operations with a SCT create/cancel message exchanges:


If we then turn off SCT framing, we just get separate session tokens – derived from the username token itself:


In any of the case, the server code to know the session (derived from the SSL tunnel within RST/RSTR, negotiated as SCT, or one-shot  from username tokens) is



About home_pw@msn.com

Computer Programmer who often does network administration with focus on security servers. Very strong in Microsoft Azure cloud!
This entry was posted in ssl, SSO. Bookmark the permalink.