[TLS] duplication session with GSSAPI PRF

I've been updating my personal code base, trying to accomplish a conforming TLS1.0 whilst also 
experimenting in line with the conversation on what the GSS API I-D actually says or may imply
(ignoring the kerberos backstory).

Lets say the first connection uses the proposed GSSAPI handshake , creating partial session state. Per the 
documented negotiation and payloads, a pre-master secret is created using the API's PRF, based on the
various GSS Tokens.. Im not sure what happened to the ClientKeyExchange Message. Is it sent? Presumably 
not... given there is no point: its function already happened in the GSSAPI token exchange. If it is sent,
what is the value? (See below.)

Presumably, another "GSS_API call" is then made to generate a master key for the proposed connection. This 
may do the same calculation as for RSA/DH/Fortezza, or not. Perhaps the value is read from an existing
GSSAPI token? Both GSS peers obviously can do this, upon explicit or implied ClientKeyExchange.

Another API call is presumably used by each party to use the masterkey as seed to generate the TLS 
Connection values., using the Hello nonces. The premaster secret is then destroyed (as are any means of 
regenerating it), per requirements.

When now we encrypt or mac records once the session status is active, where we presumably also
make GSSAPI calls to  encrypt/mac the records, using GSSAPI like a general CSP.

---

OK, I now duplicate that active connection (session state and connect state, but no API tokens/handles), attempting to 
create a parallel TLS connection, updating the read/write state. I thus send or respond with a client hello, with the current active 
sessionid, and new nonce. Per the rules, my client performs the session duplication/resumption flow. The
socket directs the output over "some reliable byte channel"

At this point I have no API tokens or API handles, to rebuild access to my GSSAPI session. Lets say I can 
somehow make a new handle to GSS, and from the masterkey alone, GSS gives me (a) a function to generate 
some new connection state according to the SSL algorithm (including export rules, nonce inputs), and (b) a handle
to a CSP-like object, so I can encrypt/mac on each of the connection read/write states, as we move to
final message exchanges on the resuming session (with new connection state).
--------

1., Do I have the right mental model, yet? Im not sure whether or not the proposal is intending to use the negotiated
GSS mechanism *set* fully, or JUST the PRF element of whatever mechanisms are indicated? I.e. is GSSAPI becoming a general 
schannel-like CSP?

2. The I-D implies that ClientKeyExchange message DOES flow. Im just not sure what is in it, and is it dependent on the 
GSSAPI mechanism that was negotiated? Does it convey an opaque token from the GSS Handshake flow? 

It doesnt seem to need to, given at an earlier point all is finished: "After successful completion of the 
gss_token messages,...the client and server each obtain 46 bytes of key random data using the GSS-API PRF. 
This data is the TLS pre-master secret." 

Perhaps it ALWAYS simply indicates "gss_prf", with zero parameters?

Peter.
_________________________________________________________________
Get the Live.com Holiday Page for recipes, gift-giving ideas, and more.
www.live.com/?addtemplate=holiday