Re: [TLS] SPNEGO over TLS - proposed new work item

[Martin Rex <martin.rex@xxxxxxx>]

Liqiang wrote:
> 
> In the proposal below encrypt() means Gss_Wrap(), the client generates a
> random quality and uses GSS_Wrap() to encrypt that random quality and
> send it to the server, that is the basis of the SPNEGO key exchange
> algorithm. Note this does not changes anything in the TLS record layer,
> the output of GSS_Wrap() is embedded in a TLS key exchange message.
> 
> We understand SPNEGO does not support PROT_READY and we expect that
> GSS_Wrap() won't be invoked until the context has been fully
> established.

OK.

My confusion might be caused by the wording of the proposal, which
talks about one single API call instead of an entire (GSS/SPNEGO)
handshake with multiple message exchanges:

> > 
> >   - ClientKeyExchange message: After GSS initialize Security
> >     context call is done, the client calls GSS encrypt message
> >     to encrypt the premaster secret. NOTE: the ClientKeyExchange
> >     is always protected under the public key obtained from the
> >     Server cert. 

was this supposed to mean something like this:

      - ClientKeyExchange message: the client uses the message
	protection services from the directly preceding
        successfully completed GSS/SPNEGO handshake
	to additionally encrypt the premaster secret, i.e. using
        gss_wrap(conf=true) to cryptographically link the
        gssapi authentication into the TLS handshake.
	 
> 
> We have received significant positive feedbacks so far. For example, we
> will be able to save a message by using GSS_PRF() instead of GSS_Wrap().

gss_prf() is a fairly new optinal extension, and whether it is available
is implementation defined.  You should probably use distinct tls
ciphersuite ids to identify which api call is used in order to provide
interoperability with gssapi mechanisms that don't have gss_prf().


But what I'm wondering is the following:
I keeps coming up everywhere--the decision of the client which
authentication method to use might be far from simple/straightforward,
and a rather simple ciphersuite id or mechanism OID might be
insufficient for an adequate decision/selection.

The existing client credential negotiation scheme in SSL/TLS is more
flexible: the server sends an entire list of trusted CAs to the client,
and the client uses it to determine whether it is in the posession
of a suitable credential.

Extending this scheme to SPNEGO would likely be benefical, but also
quite challenging, i.e. dealing with mechanism-specific (lists of) hints
providing guidance to the client for selection of the most adequate
client credential (and gss-api mechanism)...


-Martin

_______________________________________________
TLS mailing list
TLS@xxxxxxxxxxxxxx
https://www1.ietf.org/mailman/listinfo/tls