Subject: RE: Soliciting additional GSS/Kerberos interoperability results

From: "Paul Leach" <[email-masked]>
Date: Fri, 11 May 2001 13:11:54 -0700

Your tale is interesting and instructive.

Um -- isn't the case that an "abstraction" that can't be made to work on
top of the things of which it is supposed to be an abstraction, is a
_broken_ abstraction?

I think it is GSSAPI that is an inadequate abstraction, not Kerberos
that has incorrect protocol features.

In your example, you laughed at the customer because the abstractions
you like didn't meet their needs. Instead, I would say that gss_wrap()
and gss_getmic() shouldn't exist, precisely because they don't present
an abstraction that permits external configuration of security. There
should be something like gss_process_message, which either integrity
checks or encrypts depending on how the security context was set up.

Abstractions aren't automatically good. They have to be the _right_
abstractions.

Paul

---

From: Martin Rex <[email-masked]>
Date: Fri, 11 May 2001 22:53:47 +0200 (METDST)

> that has incorrect protocol features.

The original Kerberos design was fine.  It always seperated KDC from
TGS even though in most implementations it was the same service.

Now there are people that want to inline a nameservice into
the ticket protocols and claim that they are not violating the
Kerberos design principles...  Look at DCE how to add a name
service to the Kerberos architecture.  Not that I'm a DCE-fancier,
but *some* aspects of their architecture are quite good.

> checks or encrypts depending on how the security context was set up.

I also mentioned that when our application is configured for authentication
only, that it will not do any message protection calls at all, so even
gss_process_message wouldn't have helped.

The Second "S" in GSS-API stands for "service".  It is something that
is available for use to the application at the discretion of the
application.

The thing is that the application can open communication channels
and communicate in whichever fashion it likes.  It doesn't even
need to call GSS-API and can communicate totally unprotected.

Every application can do that, even with RPC-style transports that
try to force their policy onto the communication.  E.g. Microsoft
IIS servers communicate insecurely after a hacker breaks in
through one of the many holes and installs a CMD with netcat
on an arbitrary port.  :)

> Abstractions aren't automatically good. They have to be the _right_

Hey, we're at the IETF.  We're trying to create workable solutions
for the real world.  If you're looking for OSI or CORBA stuff, you're
in the wrong movie.

When GSS-API was designed there was a focus on a certain environments,
one was the distributed environment of DCE, the other was MIT Kerberos. 
Although some of those involved were wandering in another universe
(hint: GSS-IDUP) the result is a pretty good, robust and useful
spec and many implementations.  It might not fit everyone, but
where it fits, it fits extremely well.

-Martin