Kerberos authentication and authentication (proxy ticket forwarding)

[Mike Spreitzer <sp...@parc.xerox.com>]

It seems to me that it would be good to have an open standard for how to do
Kerberos authentication and authorization for the web, and that you guys
would support this and implement it; does this sound right to you?

The authorization part I'm referring to is the ability to forward proxy
tickets, including ticket-granting tickets, from client to server.

Kerberos is already established in the UNIX community, and is about have a
significant presence in the Windows community (due to it being the basis
for Windows 2000 security).  This presents us with the happy prospect of
something those two communities can agree on!

We already have RFC 2712, which tells how to use Kerberos for
authentication, integrity, and confidentiality in TLS (and specifies that
no X.509 certificates are exchanged).  However, TLS has not traditionally
taken any farther than this, so using it to forward tickets seems a bit
odd.  But not unthinkable; RFC 1964 standardizes a way to put tickets in
the checksum field of the Kerberos "Authenticator" (and the Authenticator
*is* used in RFC 2712).  This might be a possible way to go.  Another
possibility is whatever Microsoft has already implemented for IE&IIS in
Win2K.

What do you think?

Thanks,
Mike

RE: Kerberos authentication and authentication (proxy ticket forwarding)

[Mike Spreitzer <sp...@parc.xerox.com>]

> > ... it being the basis
> > for Windows 2000 security).
>
> My understanding (and this is out-of-date information) was that the
> implementation would be different enough to be annoyingly
> incompatible. Has this changed?

My understanding is that Windows 2000 will use a specialization of Kerberos
v5.  That is, every ticket Win2K produces will indeed be a real Kerberos v5
ticket, but not every K5 ticket will be equally useful to Win2K.
Specifically, Win2K has a specific idea of what appears in the
"authorization data" field of a ticket.  I've seen this asserted in a
number of places.  One example is the on-line MSDN site; see
<http://msdn.microsoft.com/library/backgrnd/html/msdn_distsecserv.htm> for
example (look in the section entitled "Kerberos Interoperability").  Note
that said page also has a vague reference to RFC 1964, and it's been
suggested that IE & IIS use this in their Kerberos flavor of HTTP
authentication.

Mike

RE: Kerberos authentication and authentication (proxy ticket forwarding)

[Mike Spreitzer <sp...@parc.xerox.com>]

> I would support it very much. Implementing it, though, gets legally
> dicey, unfortunately. Hmmmm, though Bones was exportable. I'll let the
> heavyweights answer this one.

I will too, however I'll note a reason I'm hopeful of a good outcome.  I
expect that what needs to be written down is simply a very straightforward
application of a very few existing standards.  I suspect that the necessary
Apache module could be written by someone that already has the necessary
background in about a day.  If worse comes to worse, I expect there are
people living in free countries who are qualified to write such a module.

> My understanding (and this is out-of-date information) was that the
> implementation [of Kerberos in Win2K] would be different enough to be
annoyingly
> incompatible. Has this changed?

In my previous reply I indicated that I understand Win2K to use a
specialization of Kerberos.  That means that general Kerberos code should
work on Win2K as well as elsewhere.  More specifically: any code that
doesn't care what's in the "authorization data" field of a ticket will work
just fine.  I expect that's a lot of clients and servers (as they'll just
discriminate on names), and strongly expect it includes middleware like web
browsers and servers.

In this neighborhood lurks a messy detail: the way in which Kerberos
credentials are managed locally varies from OS to OS.  I'm not an expert,
but I think that in UNIX the actual tickets are kept in some magic system
process.  In Win2K, the SSPI is used to get the tickets into and out of the
local security infrastructure.  So there has to be some OS-dependent code.
But I suspect it won't be an intolerable amount.

Thanks,
Mike

Re: Kerberos authentication and authentication (proxy ticket forwarding)

[Manoj Kasichainula <ma...@io.com>]

On Thu, Nov 04, 1999 at 11:43:24PM -0800, Mike Spreitzer wrote:
> It seems to me that it would be good to have an open standard for how to do
> Kerberos authentication and authorization for the web, and that you guys
> would support this and implement it; does this sound right to you?

I would support it very much. Implementing it, though, gets legally
dicey, unfortunately. Hmmmm, though Bones was exportable. I'll let the
heavyweights answer this one.

> significant presence in the Windows community (due to it being the basis
> for Windows 2000 security).

My understanding (and this is out-of-date information) was that the
implementation would be different enough to be annoyingly
incompatible. Has this changed?

-- 
Manoj Kasichainula - manojk at io dot com - http://www.io.com/~manojk/
"I realized it was Michael Bolton, and my bowels let loose." - Butthead

Re: Kerberos authentication and authentication (proxy ticket forwarding)

[Rodent of Unusual Size <Ke...@Golux.Com>]

Mike Spreitzer wrote:
> 
> It seems to me that it would be good to have an open standard
> for how to do Kerberos authentication and authorization for
> the web, and that you guys would support this and implement
> it; does this sound right to you?
	:
> What do you think?

I'd like to see this.
-- 
#ken    P-)}

Ken Coar                    <http://Web.Golux.Com/coar/>
Apache Software Foundation  <http://www.apache.org/>
"Apache Server for Dummies" <http://ASFD.MeepZor.Com/>

RE: Kerberos authentication and authentication (proxy ticket forwarding)

[Mike Spreitzer <sp...@parc.xerox.com>]

> I wonder if this should just be done through PAM?

PAM doesn't solve the problem I'm addressing.  The problem I'm addressing
is the need for some form of delegation.  That is, given that the user has
already "logged in" in one way or another (this is what PAM is for, right?)
to "his" machine, and wants to invoke an operation on a remote web server,
and that remote operation in turn needs to invoke another even more remote
operation *as the original user*, what enables the first web server to act
on the user's behalf?  The standard answer in the Kerberos setting is that
the client forwards proxy tickets (either specific service tickets or
ticket granting tickets) to the first server.

Re: Kerberos authentication and authentication (proxy ticket forwarding)

["Kevin A. Burton" <bu...@relativity.yi.org>]

I wonder if this should just be done through PAM?

Kevin

Mike Spreitzer wrote:
> 
> It seems to me that it would be good to have an open standard for how to do
> Kerberos authentication and authorization for the web, and that you guys
> would support this and implement it; does this sound right to you?
> 
> The authorization part I'm referring to is the ability to forward proxy
> tickets, including ticket-granting tickets, from client to server.
> 
> Kerberos is already established in the UNIX community, and is about have a
> significant presence in the Windows community (due to it being the basis
> for Windows 2000 security).  This presents us with the happy prospect of
> something those two communities can agree on!
> 
> We already have RFC 2712, which tells how to use Kerberos for
> authentication, integrity, and confidentiality in TLS (and specifies that
> no X.509 certificates are exchanged).  However, TLS has not traditionally
> taken any farther than this, so using it to forward tickets seems a bit
> odd.  But not unthinkable; RFC 1964 standardizes a way to put tickets in
> the checksum field of the Kerberos "Authenticator" (and the Authenticator
> *is* used in RFC 2712).  This might be a possible way to go.  Another
> possibility is whatever Microsoft has already implemented for IE&IIS in
> Win2K.
> 
> What do you think?
> 
> Thanks,
> Mike

-- 

Kevin A Burton
http://relativity.yi.org
Mobile:  408-910-6145
"...there is something outside yourself that has to be served, when that
need is
gone, when belief has died... what are you?  A man without a Master."