Mailing Lists: Apple Mailing Lists
Image of Mac OS face in stamp
 
[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
inaccessible.

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
protocol).

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 data.

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 nature, yet.
--
The opinions expressed in this message are mine,
not those of Caltech, JPL, NASA, or the US Government.
email@hidden, or email@hidden
_______________________________________________
darwin-development mailing list | email@hidden
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/darwin-development
Do not post admin requests to the list. They will be ignored.


Visit the Apple Store online or at retail locations.
1-800-MY-APPLE

Contact Apple | Terms of Use | Privacy Policy

Copyright © 2007 Apple Inc. All rights reserved.