Re: GSS-API and SSL - their coexistence, and related issues

[Matt Hur <[e-mail]>]

At 04:33 PM 3/12/97 -0500, Bill Buffam wrote:
8<
>8
>(c) We can apparently embrace Kerberos migration within the SSL
>mechanism, as defined in 
>ftp://ftp.ietf.org/internet-drafts/draft-ietf-tls-kerb-cipher-suites-00.txt
>This implies that SSL (or TLS or whatever it becomes) becomes the
>unifying framework within which all future session-oriented security
>mechanisms will live. It appears to set the stage for GSS-API and
>SSL/TLS to compete for the role of unifying orchestrator of
>session-oriented security. The very existence of this draft seems to me
>to be a tacit admission that current SSL techniques are more
>developer-friendly than GSS-API. Perhaps the authors could comment.
>

The Kerberos cipher suite draft does not imply a preference of SSL over
GSS-API.  It simply acknowledges a general acceptance of SSL.

We view support for Kerberos cipher suites in SSL as simply a mechanism to
provide more coverage and interoperability for users who are registered
with Kerberos realms.  This is especially apparent within the enterprise
environment.

SSL (or TLS) is currently a dominant public key based protocol.  Since it
is so easy to add a Kerberos authentication method, it seemed like a
"no-brainer" to add support for Kerberos cipher suites (in that you can get
a big payoff in interoperability - it took about a week and a half to do
our reference implementation).

We are trying to be pragmatic about interoperability (espcially since our
company's primary customers are large enterprises).  If an organization has
a Kerberos infrastructure in place, then they should be able to use
Kerberos for authentication to services that are secured via protocols that
have typically utilized public key cryptography for authentication.
Whether this solution leads to a migration to a public key infrastructure
or not is orthogonal to the issue of interoperability.  Likewise, if an
organization has a public key infrastructure in place, then they should be
able to use public key credentials to authenticate to Kerberized services
(this is accomplished with PKINIT, another Internet draft with which we
have been intimately involved).  Again, whether or not this is a migratory
solution is orthogonal to the issue of interoperability.

We would like to see support for Kerberos cipher suites in SSL/TLS.  We
think that this is a pragmatic approach to interoperability in large scale,
real world deployments.
We talked with the folks over at Netscape about supporting Kerberos cipher
suites in their SSL implementation.  If you are developing SSL/TLS
implementations, we would like to hear from you, and we would be interested
in providing support for this endeavor.  We haven't talked with the folks
at Microsoft yet, but we would appreciate thier input, since they are
developing both Kerberos and SSL/TLS-based solutions as part of their
security infrastructure.

You can download a simple reference implementation from
ftp://nii.isi.edu/pub/ssl-krb.

Regards,
Matt Hur

8<
>8
>-- 
>
>Bill Buffam
>Unisys, Malvern PA
>[e-mail]
>
>


----------------------------------------------------------------
Matt Hur                       CyberSafe
[e-mail]         1605 NW Sammamish Road, Suite 310
[phone]                 Issaquah, WA 98027-5378
                               http://www.cybersafe.com