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

We had a design meeting today to conclude discussions about this proposal that has surfaced during the IETF week.

As such the proposal has changed in the way that SPNEGO has been removed from the proposal and replaced with direct exchange of GSS-API tokens.

The slides for the presentation tomorrow has been sent to Eric and should be up on the meeting materials page before the TLS meeting.

A first draft will be available for consideration short after this IETF and Jeff Altman has agreed to help as co-editor.

Stefan Santesson

Senior Program Manager

Windows Security, Standards

From: Liqiang(Larry) Zhu
Sent: den 8 november 2006 16:38
To: martin.rex@xxxxxxx
Cc: martin.rex@xxxxxxx; Stefan Santesson; tls@xxxxxxxx
Subject: RE: [TLS] SPNEGO over TLS - proposed new work item

Martin Rex wrote:

> 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.

yes, this is what the initial proposal meant.

> 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().

it should be fairly straightforward to implement PRF(), but we may also define

another set of cipher suites where the key exchange does NOT use PRF(), rather just use GSS_Wrap().

> 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.

this is an excellent point. Folks here do realize the same issue here. the two negotiation layers (SPNEGO and TLS) should be coordinated in some way, or do we need both negotiations? these are kinds of issues that must be addressed when we have a draft.

> 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.

this argues for using TLS negotiation mechanisms and removal of SPNEGO, if I understand this correctly. Either way, I can clearly see your points.

> 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)...

I agree. this has prompted to the thinking of how to solve this in the most efficient and generic way, and I am pondering ...

-- Larry

From: Martin Rex [mailto:martin.rex@xxxxxxx]
Sent: Wed 11/8/2006 12:54 PM
To: Liqiang(Larry) Zhu
Cc: martin.rex@xxxxxxx; Stefan Santesson; tls@xxxxxxxx
Subject: Re: [TLS] SPNEGO over TLS - proposed new work item

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