Re: choosing principal names

On Wed, Oct 5, 2011 at 5:49 PM, Henry B. Hotz <[email protected]> wrote:
> On Oct 5, 2011, at 10:56 AM, Nico Williams wrote:
>> On Wed, Oct 5, 2011 at 11:55 AM, Love Hörnquist Åstrand <[email protected]> wrote:
>>> I think there should be very little kerberos programmers, there should be more gss programmers.
>>
>> +1
>
> Hmmm.  I think I agree in general, but. . .
>
> Should GSSAPI be "general" as in not just Kerberos?  (It isn't, really, in practice.)

I don't agree that it isn't in practice.

First, there's a number of working GSS mechanisms.  Granted, few are
as widely used as Kerberos.

Second, more working GSS mechanisms are coming.

Third, it is possible to write GSS applications that are mostly
mechanism-agnostic, particularly given all the extensions we've added.
 Granted, we never did get around to writing an FYI RFC tutorial to
using the API... :(

> Should (does?) Kerberos support functionality which is not defined for GSSAPI?  (Level of Assurance is required sometimes and you can't really do it with GSSAPI.  Of course the Kerberos solutions are ugly, proprietary, and maybe both.)

Perhaps the only thing in Kerberos which the GSS-API did not -but
should have- exposed is the notion of "realm".  With naming extensions
we'll be able to get at this in a truly mechanism-agnostic way, but
for now apps that need to can just inspect the principal name (since
they'll get the raw form) even though doing so makes them less
mechanism-agnostic.

As for cryptographic algorithm suite policies... the GSS-API is badly
broken in this respect :(  I've written about this many times on
KITTEN WG's list.

Nico
--