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

[Martin Rex <Martin.Rex at sap.com>]

Nicolas Williams wrote:
> 
> 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.

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 www at target.f.q.d.n 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

_______________________________________________
TLS mailing list
TLS at lists.ietf.org
https://www1.ietf.org/mailman/listinfo/tls