Subject: [TLS] Negotiation in draft-santesson-tls-gssapi

From: Nicolas Williams <[email-masked]>
Date: Wed, 18 Jul 2007 17:56:34 -0500

If this protocol will not provide a way for the server to tell the
client what GSS-API mechanisms it supports or any other GSS-API
mechanism negotiation facility then I think the server MUST support
SPNEGO, else the client and server have to agree a priori on what mechs
to use.

Nico
-- 

_______________________________________________
TLS mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/tls

---

From: Larry Zhu <[email-masked]>
Date: Wed, 18 Jul 2007 15:57:37 -0700

I agree with the proposed the change.

--larry

-----Original Message-----
From: Nicolas Williams [mailto:[email-masked]] 
Sent: Wednesday, July 18, 2007 3:57 PM
To: [email-masked]
Subject: [TLS] Negotiation in draft-santesson-tls-gssapi

Nico
--

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 18 Jul 2007 18:09:59 -0500

I just noticed Martin's objection that mechanism negotiation must be
done at the TLS level to avoid a failure mode where GSS is selected but
no common mechanism is found, yet non-GSS/PSK TLS would have worked.

The current version of the I-D allows TLS to continue to make progress
if the GSS security context establishment fails.  This is good, but if
negotiation could be done at the TLS level then we can optimize
round-trips in this corner case.  I'm not sure if we care.

---

From: Martin Rex <[email-masked]>
Date: Thu, 19 Jul 2007 01:12:54 +0200 (MEST)

> SPNEGO, else the client and server have to agree a priori on what mechs

This observation is correct.

But I would very much dislike calls into SPNEGO by TLS (because
you really DO NOT want to layer it below TLS, where none of the
fancy GSS-API extensions is accessible that everyone is inventing),
unless you pave wide information highways through your TLS stack
or alternative break the abstraction, extort GSSAPI object handles
and function pointers held and managed by TLS to frob the GSSAPI
and SPNEGO implementations directly from above TLS (bypassing TLS).

This is why I want the negotiation of a common mechanism (OID)
be part of the Hello extension.  Its more of a selection according
to the preferences of the server.  It needs to be provided as
a simple OID list to the TLS stack on both sides, and that could
even be done in a generic fashion (not limited to a particular
TLS extension).

I just sent Larry a kind-of brain dump:

The whole idea and concept that I envison is still under construction
in my mind, but I do have a quite good feeling about it.

There are a lot of things/issues to address, not only wire formats
for new/additional messages, but also new semantics and
new requirements for the SSL/TLS module APIs to control
the new semantics.  Inserting a new code layer "TLSplus" that looks
like a TLS implementation (with additional features) to the application
and does all the new magic is inevitable, I believe.

For such an additional TLSplus code layer, we ought to
define several (abstract) characteritics and semantics
and provide rough guidelines how implementors might add
value, bells and whistles, depending on what (primarily
the server application) wants or needs.

Off the top of my mind here is a crude list of characteristics
that I consider important, and I believe that some of these can
not be met with the current proposal:

 - will work with pretty much every existing and conceivable
   GSS-API mechanism (even v1), requiring no changes to the mechanism

 - minimal and generic extension(s) to TLS (not tied to any GSS-API
   mechanism, and maybe not limited to the gssapi-over-tls extension)

    - Hello extension with ability to enable the server to select
      a common (gssapi) mechanism (OID), ignoring of the extension
      and regular SSL-Handshake if no common mechanism is found

    - include support for server name extension (virtual hosting)
      which also means server-side mechanism preference lists that can
      be limited to a particular virtual host and provide
      a hint for the server for selection of a suitable
      gssapi acceptor credential (above TLS)

    - a new ContentType at the TLS record layer to reliably
      distinguish (and prevent confusion) of GSS-API token
      exchanges (following a successfully completed SSL handshake)
      from application data.  A minimal framing protocol for
      the GSS-API token exchange to convey token length in order
      to support GSS-API context level tokens >16KByte,
      and maybe token type (in order to allow of a textual
      error message to the client over the established protected
      TLS channel when the acceptor side encounters and error
      when trying to establish the security context (this is
      not part of GSS-API but of the gssapi-over-tls extension).

    - semantics/constraints of the server certificate path validation
      for the client if the the gssapi-over-tls authentication extension
      is requested and a common gssapi mechanism is found and asserted
      by the server in the server hello message. 

    - probably a possibility to ask the TLS (server) implementation
      to store a (size-limited) flat-memory-object of TLSplus
      state along with a cached TLS session that is available on SSL/TLS
      session resumption and flushed when TLS flushes the session cache entry.
      Depending on the application's desires and requirements, the
      TLSplus layer may want to (or need to) persist some GSS-API
      specific information so that this information can also be
      provided to the calling application on SSL/TLS session resumption.
      For the underlying TLS implementation, this ought to be transformed
      into an opaque flat-memory-object that can be free() whenever
      the associated SSL session cache element is flushed from the cache.

 - will allow the application to access arbitrary GSS-API attributes
   and extensions with no changes to the TLS implementation and
   no violation of layering principles (like using meta-knowlege to
   frob software-layer below TLS directly) and not having to expose
   internal object handles created and managed by TLS.

 - no changes necessary to the gssapi-over-tls spec and neither the
   TLS implementation if additional or new features of a gssapi
   mechanism become available and used by the application caller
   (only changes to TLSplus, and for new GSS-API features to
    the gssapi implementation itself).

 - no changes necessary to the gssapi-over-tls spec the GSS-API
   mechanism, TLSplus or the application when new features are
   added to the underlying TLS implementation

 - orthogonality to TLS, i.e. benefit as much as possible from
   improvements to TLS, like new or stronger ciphersuites,
   new PRF or new TLS version, without changes to TLSplus, GSS-API, app
   and gssapi-over-tls spec -- which pretty much precludes to
   hardware/require any particular ciphersuites in gssapi-over-tls itself.

 - protection of the client identity from network-level sniffing
   (something which not currently available for the SSL client
    certificate).

Since I've been implementing a SAP-internal small "abstraction layer"
on top of SSL and providing support for this and the accompanying
OEM SSL library that we ship over the last 6 years, and for
gssapi based single sign-on over the last 10 years, my thoughts
are very close to real code that could&would implement all the
necessary stuff.

I firmly believe that any solution should allow both, the
TLS protocol&extensions and the GSS-API protocol&extensions to
evolve independently and provide new features with close to no
mutual interference between GSS-API, TLS and the gssapi-over-tls spec.

-Martin

---

From: Martin Rex <[email-masked]>
Date: Thu, 19 Jul 2007 02:35:42 +0200 (MEST)

> SPNEGO, else the client and server have to agree a priori on what mechs

While thinking a little longer about SPNEGO a number of problems
come to mind.

A common mechanism OID between initiator and acceptor only means
that they will be able to parse each other GSS-API tokens,
it does by no way mean that authentication will work.

How common is it that companies (ultimately two rival companies)
have mutual trust configured between their company-internal
Kerberos realms and maintain each others Kerberos principals names
on their ACLs?

Think about login to a public internet-accessible Web-Server for
customers, partners, friends, interested parties and even rivals
with product information and discussion forums.

We DO use our PKI-based company-internal Single Sign-On infrastructure
to login to our public Web-Servers, and we do issue SSL client certs
to customers and partners for login as well.  password-based logon
is possible as well.

If we didn't have PKI-based Single Sign-On, but instead kerberos
or gssapi-based logon and also our partners had that, and both
of us had gssapi-over-tls authentication enable in our browsers,
then we would have the situation that SSO works for us and
constantly fails if only the "common mechanism" selection
of SPNEGO would be available.

Trying to "poll" for suitable gssapi mechanism by calling
gss_init_sec_context() for every gssapi mechanism feeding
the intended [email-masked] when compiling the mechanism OID
list for SPNEGO is not a good idea.  There are gssapi mechanisms
that interactively prompt for a password for each and every
credential access (incurred by gss_init_sec_context()) and which
check/verify the target name only on receipt of the second token,
which could result in 40 password-popups for a single Web-Page
with 39 embedded frames,gifs,css and js...

When supporting virtual hosts in a fashion as I have depicted
in a previous message, then this issue could be easily solved
by configuration.  Assign a seperate hostname for company-internal
usage that will be sent by the client browser with gssapi-over-tls
extension and configure it with a virtual-host specific mechanism
list for the hello-extension negotiation.  Do not list Kerberos
on the "externally facing" virtual host -- problem solved.

Another potentially beneficial feature for developers:
I can set up a single Web-Server, configure it with several
different virtual hosts and individual mechanism lists,
so that I can perform interoperability tests between browser
and server for all gssapi mechanism just by suppling a
particular URL, without having to reconfigure and restart
client or server.

-Martin

---

From: Larry Zhu <[email-masked]>
Date: Wed, 18 Jul 2007 17:41:49 -0700

The current ID gives us the means to do both, the GSS data can be in
clear text or encrypted. The GSS-API token can contain the real GSS
mechanism tokens protected by certificate-based TLS.

Comparing Martin's rough proposal, the current ID optimizes for the
minimal # of roundtrips and gives us more a more generic and more
extensible solution. 

The # of roundtrip is important for some applications and environments.
Therefore the current ID wins with a clear cut in term of the required #
of round-trips.

--larry

-----Original Message-----
From: Martin Rex [mailto:[email-masked]] 
Sent: Wednesday, July 18, 2007 4:13 PM
To: Nicolas Williams
Cc: [email-masked]
Subject: Re: [TLS] Negotiation in draft-santesson-tls-gssapi

    - probably a possibility to ask the TLS (server) implementation
      to store a (size-limited) flat-memory-object of TLSplus
      state along with a cached TLS session that is available on SSL/TLS
      session resumption and flushed when TLS flushes the session cache
entry.
      Depending on the application's desires and requirements, the
      TLSplus layer may want to (or need to) persist some GSS-API
      specific information so that this information can also be
      provided to the calling application on SSL/TLS session resumption.
      For the underlying TLS implementation, this ought to be
transformed
      into an opaque flat-memory-object that can be free() whenever
      the associated SSL session cache element is flushed from the
cache.

   hardware/require any particular ciphersuites in gssapi-over-tls
itself.

-Martin

---

From: Martin Rex <[email-masked]>
Date: Thu, 19 Jul 2007 04:05:13 +0200 (MEST)

Larry Zhu wrote:
> clear text or encrypted.

*I* certainly can not see that in the current draft.

>
> The GSS-API token can contain the real GSS

How?  You mean by renegotiation -- similar to how one can
protect the SSL client cert?  that would add roundtrips, wouldn't it?

> minimal # of roundtrips and gives us more a more generic and more

If you coalesce the first GSS-API context establishment roundtrip
onto the TLS finished messages you have the same amount of roundtrips
for a TLS+rfc-1964 kerberos authentication than for a plain TLS
handshake.   

Did I miss a clever roundtrip reduction of the TLS handshake
in the current ID, or could there be an error in your counting?

> Therefore the current ID wins with a clear cut in term of the required #

When SPNEGO is used in the current proposal and the optimistic
token is wrong on the, then the current ID incurs an additional roundtrip.
My proposal didn't need an optimistic token and therefore can not
suffer such an additional-roundtrip penalty.

To me, this looks like equal roundtrips, and a loss for the current ID
if the optimistic token is wrong compared to my envisoned architecture.

-Martin

---

From: Larry Zhu <[email-masked]>
Date: Wed, 18 Jul 2007 20:18:55 -0700

Martin Rex wrote:

> Larry Zhu Wrote:

> protect the SSL client cert?  that would add roundtrips, wouldn't it?

you can do this in the most straightforward way,  when the TLS protection for the GSS data is in place, it should be no worse than what is in your proposal. The difference is that this draft leaves the options open by not requiring a TLS handshake up front.

 An appendix can be added to illustrate how this can be done.

________________________________

From: Martin Rex [mailto:[email-masked]]
Sent: Wed 7/18/2007 7:05 PM
To: Larry Zhu
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [TLS] Negotiation in draft-santesson-tls-gssapi

-Martin

---

From: Martin Rex <[email-masked]>
Date: Thu, 19 Jul 2007 05:49:41 +0200 (MEST)

> in the current ID, or could there be an error in your counting?

Rechecking the spec and OpenSSL, I realize that, although such
an optimization should be technically possible, it would somewhat bent the
TLS existing handshake and require quite non-trivial changes to the
TLS state machine and semantics of SSL_connect when trying to implement
the gssapi-over-tls authentication with inital context token coalesced
to the TLS finished messages in an entirely seperate code layer
"TLSplus" above TLS.

I notice, however, that I still consider the necessary contortions
to run the entire GSS-API context establishment within TLS and
the TLS handshake according to the current ID _MAGNITUDES_ worse
if one also wants to make use of all the various GSS-API
features and extensions.

For cached&resumed SSL sessions, there are no additonal roundtrips
in either case (just the unexplained dirty hacks for the current ID
in order to get access to GSS-API attributes of the original
full SSL handshake).

Personally, I do not consider the additional roundtrips of the
GSS-API context establishment a showstopper.  The overhead of
rfc4559 Negotiate is worse (in particular with IIS6 as a backend!),
and still it is surprisingly usable--well, at least with a sane
backend that issues a secure session id upon inital rfc4559
authentication and does not constantly throw 401 Unauthorized
for each and every request on an established TLS-protected
communication channel.  That IIS6 curiosity reliably prevents
pipelining of requests.  

Because of this, I can easily understand that Microsoft has a significant
performance issue with their deployed software using rfc4559.
But frankly, I strongly doubt that one additional roundtrip on
a full SSL handshake is going to be performance killer.
As I mentioned before, when I was involved in Analyis of Performance
issues with HTTPS-protected communication in High-end installations
of our software, the only time when the SSL handshake became an
issue was when the server SSL session cache size was too small
leading to a 50:1 ratio in full handshakes vs. session resumes
compared to a 1:30 ration in full handshakes vs. session resumes
on new network connetions with a sufficiently large session cache size.  

-Martin

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 19 Jul 2007 18:16:40 -0500

> protect the SSL client cert?  that would add roundtrips, wouldn't it?

By nesting TLS.

> for a TLS+rfc-1964 kerberos authentication than for a plain TLS

The way TLS works it depends on the finished message derivation having
as input all preceding hello and handshake messages, and in order.  This
means that at most one GSS-API token can be sent in the same "write" as
a Finished message.  There is no way to piggyback a 1 round-trip GSS
context token exchange onto the full handshake pictured in figure 1 of
RFC4346.  Nor is there a way to piggiback the first context token into
the client Hello message without first extending the client Hello, but
how can we extend the client Hello?  (AFAICS we cannot.)

> in the current ID, or could there be an error in your counting?

I think Larry meant that if the GSS-API context fails to be established
then we can fallback on other TLS key exchange and/or authentication
methods, which means that in some cases the use of the GSS-API will only
add round-trips.

One reason the GSS-API security context establishment might fail is that
the client tried a mechanism not supported by the server.  This is
preventable, either by using SPNEGO or by extending the server Hello to
allow the server to advertise what mechanisms it supports and has
acceptor credentials for.

That is, by providing for negotiation of GSS mechanisms, one way or
another, we can eliminate a situation in which this extension might do
nothing more than add a round-trip.

BTW, the protocol in figure 1 of draft-santesson-tls-gssapi is
confusing: the server can't be the first to send a TokenTransfer unless
it sends an empty one (because the GSS-API is an initiator-sends-first
framework).

Nico
--

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 19 Jul 2007 18:19:42 -0500

> if one also wants to make use of all the various GSS-API

One should not.  This I-D is roughly akin to RFC4462 (SSHv2 w/ GSS).

> in order to get access to GSS-API attributes of the original

Correct.

> GSS-API context establishment a showstopper.  The overhead of

Me either.  But that's not what Larry meant, I think.  See my other
reply just now.

Nico
--

---

From: Larry Zhu <[email-masked]>
Date: Thu, 19 Jul 2007 16:19:16 -0700

Nicolas Williams wrote:
> confusing: the server can't be the first to send a TokenTransfer
unless it sends an empty one (because the GSS-API is an
initiator-sends-first 
> framework).

This is a typographical error that has been fixed in -03 at
http://www.secure-endpoints.com/tls-gss/draft-santesson-tls-gssapi-03.tx
t.

-----Original Message-----
From: Nicolas Williams [mailto:[email-masked]] 
Sent: Thursday, July 19, 2007 4:17 PM
To: Martin Rex
Cc: Larry Zhu; [email-masked]
Subject: Re: [TLS] Negotiation in draft-santesson-tls-gssapi

By nesting TLS.

Nico
--

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 19 Jul 2007 18:28:45 -0500

> Kerberos realms and maintain each others Kerberos principals names

Funny, I sent an e-mail to Sam last night proposing that we talk
tomorrow (we'll be in the same city) about the identity selection
problem.

I think it'd be nice to have a way to negotiate which "federation" (to
borrow a suitable term from the world of Liberty and other identity
schemes) to use.  I picture a (forgive me) stackable pseudo-mechanism by
which the client and server can agree on a federation.  In general it
should be sufficient, and better, for the server to tell the client what
the federations are that it participates in, ASAP, so that in protocols
where there's a chance to do that before the GSS context establishment
starts then no round-trip penalty is incurred.

However, there are issues to think about.  Protecting the negotiation is
an obvious one.  Privacy protection of the client's identity(ies) is
another.

One thing that seems nice is that "federation" names can be independent
of authentication mechanisms.  A PKI, Kerberos and or Liberty federation
would be a world of domains/realms where entities (such as users and
servers) should be able to authenticate each other provided that they
have valid credentials).

Federated world negotiation is part of the identity selection problem.
Of course, the identity selection problem is still non-trivial to solve
even if we solve the federated world negotiation problem.

Nico
--

---

From: Martin Rex <[email-masked]>
Date: Fri, 20 Jul 2007 01:54:25 +0200 (MEST)

Nicolas Williams wrote:
> a Finished message.

This is be a YES (to sending one context-level gss-api token).

>                        There is no way to piggyback a 1 round-trip GSS
> RFC4346.

This is a NO.

I'm confused.

What I was thinking of was piggybacking the initators first context level
token onto the client's finished message and the acceptors first context
level token onto the servers finished message.

I admit that I'm not sufficiently familiar with the crypto of the SSL/TLS 
handshake to determine whether this is possible.

I just noticed, that technically implementations like OpenSSL have
implemented the exchange of the Finished messages in a half-duplex
fashion.  I don't know whether this is strict requirement from the
protocol or whether it is because it is easier to implement and
it wouldn't be a good idea to let the client application send data
before the server's finished message was received and verified.

If the latter, then there is no technical issue against sending
the initiators first context level token without waiting for
the servers finished message.  

But for architectures like OpenSSL, piggybacking on the client
finished message would require a significant change of the
clients state machine and SSL_connect API semantics, which is
why *I* would not put such an optimization into OpenSSL...

If I understand Microsoft's software architecture correctly,
then they have a TLS implementation without transport,
where adding such an optimization should be _much_ easier
to add and be fairly compatible to the exitinge API semantics.

>
> Nor is there a way to piggiback the first context token into

Hello extensions should work with SSLv3 already.
Is there a size limitation on the Hello extension?
(because there is no size limitation on the gssapi context level tokens). 

> acceptor credentials for.

Coming up with good "fallback semantics" will be challenging.
Fallback to the regular TLS handshake when there is no common
gssapi mechanism is fine (similar to my idea).

Fallback if the security context establishment fails is not
necessarily a good idea, because if you really want gss-api
based authentication and that fails for a technical reason,
you will not see the GSS-API error, but instead get a
fallback to the TLS handshake.

Several serious bugs in Microsoft Kerberos go unnoticed because
of the fallback to NTLM kicking in for most of Microsoft's own
communication protocols.  On the one hand this is a security problem
(NTLM authentication is significantly weaker than Kerberos), and
on the other it becomes a showstopper for (mosty non-Microsoft-only)
scenarios where the use of Kerberos is a requirement. 

Fallback for an unsupported/unavailable feature is usualls OK,
fallback for a security-relevant error is often the cause of
security vulnerabilities or mysterious behaviours (works sometimes
but not always).  

-Martin

---

From: Martin Rex <[email-masked]>
Date: Fri, 20 Jul 2007 02:20:29 +0200 (MEST)

> (because there is no size limitation on the gssapi context level tokens). 

A while back we had a discussion about changing the TLS PRF.
Then it was suggested that it should be OK if both parties have
to keep all SSL handshake messages around in order to compute
the finished messages.

I don't think this would be a good idea if there is no size limit
on the size of the entire SSL/TLS handshake.  Do we really want
to have the entire GSS-API token exchange WITHIN the TLS handshake?

Even in the "good" case, this may be a significant amount of
data.  The initial SPNEGO token may be carrying a wrongly guessed
initial context token of a gssapi mechanism not offered by the
server, and then you also get the full handshake of the
common mechanism.

The decision of a TLS server to abort a handshake because of an
excessively large Hello extension itself might be easier than
to tell from which size on a huge optimistic context token for an
(potentially unsupported) gssapi mechanism in the SPNEGO token
should be considered an offense or attack deserving a FATAL SSL alert...

-Martin

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 19 Jul 2007 23:33:35 -0500

> > context token exchange onto the full handshake pictured in figure 1 of

The Finished messages provide a verifier for the entire preceding
handshake.  Therefore the entire preceding handshake MUST end no later
than when the first finished message is sent.  See Fig. 1 of RFC4346.

> level token onto the servers finished message.

If you do that then what you have isn't TLS (or you're nesting TLS, in
which case you'll be having another exchange of Finished messages).

> Hello extensions should work with SSLv3 already.

For client hello?

> (because there is no size limitation on the gssapi context level tokens). 

TLS has a record size limit -- to exceed it you must fragment.

> fallback to the TLS handshake.

That's up to the client.

Nico
--

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 19 Jul 2007 23:51:41 -0500

> to have the entire GSS-API token exchange WITHIN the TLS handshake?

Well, we could have the Finished message construction modified so as to
substitute a hash of each GSS context token in place of that token.

> should be considered an offense or attack deserving a FATAL SSL alert...

I don't think we want to have the initial context token go in the client
Hello message, even if it turns out that we could.  I'm willing to eat
that round-trip (even though I might be -- I haven't decided :) --
concerned about additional round-trips in the GSS-fails case).

Nico
--

---

From: Bodo Moeller <[email-masked]>
Date: Fri, 20 Jul 2007 18:30:54 +0200

> before the server's finished message was received and verified.

To protect the application data, generally you wouldn't want to start
sending anything before having verified the server's Finished message.
Usually, certificate-based authentication ensures that the client
knows that it is talking to the proper server, i.e. only the server
will have the same symmetric key material -- but still an adversary
could have attacked the TLS handshake to manipulate the negotiation
process.  So you might be using a symmetric cipher that is less secure
than intended, or even an authentication-only cipher (NULL encryption).
Verifying the other party's Finished message allows both parties to
detect such attacks, provided that the ciphersuite and keys in use
at least do provide sufficiently strong authentication.

If you don't worry about the confidentiality of the data that you are
sending immediatly after encryption has started, then there is no
security need to delay sending this data until having received and
verified the server's Finished message.  But this is an exception.
A general-purpose TLS library that doesn't know anything about the
application data that it has to protect really needs to wait for the
Finished message.

Bodo