[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Kerberos Feature Request
At 11:05 AM -0500 2/11/04, Ken Hornstein wrote:
> >Jeffrey Altman objects that I want an API, not an RFC, so IETF
>>shouldn't be involved, but I think the example I just gave would be
>>an RFC. I'm trying to limit my care-about's though. I just want a
>>general way to make use of the feature, which is currently pretty
>I guess I don't understand why you need an RFC. From a protocol
>standpoint (the main point of interest of the IETF), the work has, from
>my perspective, already been done. How you transmit authorization data
>is completely defined within the protocol. (And I will echo others:
>you should really read the clarifications document for the most current
>information on the handling of authorization data within the Kerberos
After being jumped on for mis-using the Microsoft term PAC when I
meant the generic Kerberos term "authorization data" I went and
RE-read the relevant sections of 1510 and the DRAFT clarifications
(including the specific section of the latter that JA pointed at).
As far as I can see there is nothing in them that addresses the KDC
to (unspecified) authorization service interface that would be
necessary in order for the KDC to acquire KDC-ISSUED authorization
If someone tells me that the IETF is interested and discussing the
issue then I will join and participate as much as I can. If some
proposals that I'm writing now get funded then I will definitely join
and might even lead the discussion if it still seems appropriate.
In the mean time I'm actually satisfied with JA's proposed callout as
a solution to the issue I raised, and I agree that that solution is
an "implementation issue" that does not call for a standard RFC. The
caveat is that it's not my solution unless multiple KDC
implementations provide the same callout.
>Now, currently the authorization data is what you call "pretty
>inaccessible". If you're speaking in terms of the GSSAPI, I would
>agree. However, if you are using the MIT krb5 API, then I wouldn't
>agree, because you can get access to the authorization data on
>application servers via the MIT krb5 API (which is what you really
>care about from an application server perspective). You can utilize
>this API feature no matter who's KDC you are using.
Doesn't the Kerberos FAQ recommend that you use GSSAPI in preference
to the MIT API? ;-)
>Now, it's true that currently an MIT KDC has no way of inserting
>authorization data into service tickets. That, however, is purely an
>_implementation_ issue. You could add such code today, and it wouldn't
>require a protocol change at all. Where you get the authorization data
>from is completely up to you; the _protocol_ doesn't care, and the
>Kerberos RFC shouldn't require any modification. This is, of course,
>assuming that I'm understanding what you're asking for.
I think I agree with you. Note however that another possible
solution would be a revision of RFC2307 that defines an LDAP place to
put authorization data.
What wasn't perhaps clear is that my concerns are not with the
protocol specifically, but with how an organization can implement
single-sign-on authorization without being tied to a single vendor.
A standardized relationship between Kerberos and LDAP for
authorization data is probably how I have to solve the problem for
JPL, but the audience I'm addressing needn't (and shouldn't and
didn't) limit the solutions to that space.
As I said before I'm perfectly happy with a cross-KDC standard
callout function. It seems the fastest, simplest way to go. I might
also be happy with a new protocol for how a KDC might acquire
authorization data, but no one (else) has suggested anything of that
The opinions expressed in this message are mine,
not those of Caltech, JPL, NASA, or the US Government.
Henry.B.Hotz@jpl.nasa.gov, or firstname.lastname@example.org