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

From: Martin Rex <[email-masked]>
Date: Wed, 8 Nov 2006 21:54:19 +0100 (MET)

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
[email-masked]
https://www1.ietf.org/mailman/listinfo/tls

---

From: "Liqiang(Larry) Zhu" <[email-masked]>
Date: Wed, 8 Nov 2006 16:38:20 -0800

>      gssapi authentication into the TLS handshake.
 
yes, this is what the initial proposal meant.
 
> 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().

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

> 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.
 
> 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:[email-masked]]
Sent: Wed 11/8/2006 12:54 PM
To: Liqiang(Larry) Zhu
Cc: [email-masked]; Stefan Santesson; [email-masked]
Subject: Re: [TLS] SPNEGO over TLS - proposed new work item

OK.

        

-Martin

---

From: Stefan Santesson <[email-masked]>
Date: Fri, 10 Nov 2006 03:34:47 +0000

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: [email-masked]
Cc: [email-masked]; Stefan Santesson; [email-masked]
Subject: RE: [TLS] SPNEGO over TLS - proposed new work item

-- Larry

OK.

-Martin

---

From: Martin Rex <[email-masked]>
Date: Fri, 10 Nov 2006 20:40:19 +0100 (MET)

Stefan Santesson wrote:
> 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.

A thought that came to me during todays tls meeting was the following:

With exiting SSL/TLS (and -implementations), the authenticated peer
becomes part of the SSL session state in the SSL session cache.

When including an "external" authentication in the TLS handshake,
what happens with the information about the authenicated peer,
how is it "persistet", so that it will be transparently available
when that SSL session is later resumed?

Some features of existing GSS-API mechanisms (and future features,
in particular about authorization attributes and subject alt name
retrieval) might be extremely non-trivial to persist in the
SSL session cache.

-Martin

---

From: Martin Rex <[email-masked]>
Date: Sat, 11 Nov 2006 04:17:31 +0100 (MET)

Followup on myself...

> becomes part of the SSL session state in the SSL session cache.

I meant the peers cert and cert chain (when one was sent) becomes
part of the SSL session.

> retrieval) might be extremely non-trivial to persist in the

At first glance, one may think about using "gss_export_sec_context()"
and "gss_import_sec_context()".  But even when using the transfered
context only to retrieve information about the authenticated identity
on session resume, it may not work.

potential problems:
 - SSL sessions can be forked in high numbers (and it is actually
   the most interesting feature of SSL session caching), while
   it is undefined whether a exported gssapi security context can be
   imported more than once.  It may work for many pure user-space
   library implementations of gssapi mechanisms.

 - Even if it does work (not covered by the GSS-API v2 spec),
   the actual use of message protection facilities on a duplicated
   and multiple times imported security context token will likely
   have serious security implications, like re-use of same crypto-keys
   with same sequence numbers, and in the case of symmetric stream
   ciphers for confidentiality protection, the exact same keystream
   may get used over and over again...

 - weird things like Microsoft's impersonation model might become
   tricky to implement.

 - credential delegation within gss-api will not work in a straightforward
   fashion -- how does the application recieve the gssapi cred handle
   and how can it later release it.  How will multiple import of
   an exported security context token affect a delegated credential?

A TLS-integrated (instead of HTTP-based GSS-API authentication) will
also not work with existing SSL accellerators, and create a burdon
for server-side (=reverse) proxies/loadbalancers.

Btw. for large AppServers there are real performance benefits when the
client authentication is not performed at the TLS layer (and **NOT** tied
to the TLS channel) but instead at the HTTP or application level.
The processing load (including the costly client authenication)
can be much better loadbalanced to a farm of backend servers.

-Martin