[475] in Kerberos_Protocol

home help back first fref pref prev next nref lref last post

RE: Ticket extensions in Kerberos revisions

daemon@ATHENA.MIT.EDU (John Brezak)
Wed May 3 20:36:22 2000

Content-Class: urn:content-classes:message
Mime-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01BFB528.7A7572E0"
Date: Wed, 3 May 2000 10:53:24 -0700
Message-Id: <19398D273324D3118A2B0008C7E9A5690AE47D48@SIT.platinum.corp.microsoft.com>
From: "John Brezak" <jbrezak@Exchange.Microsoft.com>
To: "Nicolas Williams" <willian@ubsw.com>,
        "Booker C. Bense" <bbense@networking.stanford.edu>
Cc: <ietf-cat-wg@lists.Stanford.EDU>, <krb-protocol@MIT.EDU>

This is a multi-part message in MIME format.

------_=_NextPart_001_01BFB528.7A7572E0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

When a Windows 2000 KDC gets a TGS-REQ with a TGT without Windows 2000
authzdata - such as a TGT from a trusted Kerberos realm, it will use the
cname in the ticket to locate an account in the Windows 2000 domain that
will be used to construct the authzdata and insert the authzdata into
the ticket. This is referred to as the cross-realm scenario, where the
Kerberos realm has a trust with the Windows 2000 forest.

The Kerberos realm is acting as the authentication service (issues TGTs
for users) and the Windows 2000 domain is acting as the authorization
service (decorates service tickets with the needed authzdata) to access
Windows 2000 services that are using the Windows 2000 domain security
model for access control.

In the end the ticket's authzdata is used to construct an access token
for the service.=20

In the case where Windows 2000 systems are not a member of any domain, a
Kerberos realm can be used for authentication, but authorization is
based on establishing mappings between the cname in the ticket with a
local (SAM) account on the computer. The mapping is used to create the
access token. This is very similar to the mapping mechanism between
Kerberos principal names and /etc/passwd names on Unix systems to
establish a local uid for access checking.


> -----Original Message-----
> From: Nicolas Williams [mailto:willian@ubsw.com]
> Sent: Wednesday, May 03, 2000 8:25 AM
> To: Booker C. Bense
> Cc: ietf-cat-wg@lists.Stanford.EDU; krb-protocol@mit.edu
> Subject: Re: Ticket extensions in Kerberos revisions
>=20
>=20
>=20
> On Wed, 03 May 2000, Greg Hudson <ghudson@MIT.EDU> wrote:
> > >> As Ken pointed out, it is significant to save apps the=20
> extra work,
> > >> the extra tickets (why should a server ever have to "log=20
> in" -- get
> > >> a TGT?), etc.
> >=20
> > > - Because it's secure and extensible and a much better model?=20
> >=20
> > Separating out authorization database from the KDC database does not
> > implicitly require the servers (other than the authorization server)
> > to "log in."
> >=20
> > Here is an example:
> >=20
> >         1. User gets TGT (containing no auth data)
> >         2. User contacts authorization server and presents a ticket
> >            and authenticator, and asks for authorization data for
> >            "fooservice".
> >         3. Authorization server gets credentials for "fooservice".
> >         4. Authorization server sends to user its ticket (not the
> >            session key, of course) and sends the authorization data
> >            sealed using its session key.
> >         5. User contacts "fooservice" and presents its normal
> >            ticket and authenticator, plus the bundle it got from the
> >            authorization server.
> >=20
> > The server can now verify the authorization data using the=20
> session key
> > located in the authorization server's ticket.  No need for=20
> the server
> > to go off and check.
>=20
> Hey, that's pretty good. This would solve the problem of=20
> anonymous user
> login info lookups as well. So if such a system could be standardized
> then we can get rid of the Kerberos extensions altogether.
>=20
> Nico
> --
>=20
> =
-++**=3D=3D--++**=3D=3D--++**=3D=3D--++**=3D=3D--++**=3D=3D--++**=3D=3D--=
++**=3D=3D
> This message was posted through the Stanford campus mailing list
> server.  If you wish to unsubscribe from this mailing list, send the
> message body of "unsubscribe ietf-cat-wg" to=20
> majordomo@lists.stanford.edu
>=20

------_=_NextPart_001_01BFB528.7A7572E0
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3DUS-ASCII">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
6.0.4356.0">
<TITLE>RE: Ticket extensions in Kerberos revisions</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/plain format -->

<P><FONT SIZE=3D2>When a Windows 2000 KDC gets a TGS-REQ with a TGT =
without Windows 2000 authzdata - such as a TGT from a trusted Kerberos =
realm, it will use the cname in the ticket to locate an account in the =
Windows 2000 domain that will be used to construct the authzdata and =
insert the authzdata into the ticket. This is referred to as the =
cross-realm scenario, where the Kerberos realm has a trust with the =
Windows 2000 forest.</FONT></P>

<P><FONT SIZE=3D2>The Kerberos realm is acting as the authentication =
service (issues TGTs for users) and the Windows 2000 domain is acting as =
the authorization service (decorates service tickets with the needed =
authzdata) to access Windows 2000 services that are using the Windows =
2000 domain security model for access control.</FONT></P>

<P><FONT SIZE=3D2>In the end the ticket's authzdata is used to construct =
an access token for the service. </FONT>
</P>

<P><FONT SIZE=3D2>In the case where Windows 2000 systems are not a =
member of any domain, a Kerberos realm can be used for authentication, =
but authorization is based on establishing mappings between the cname in =
the ticket with a local (SAM) account on the computer. The mapping is =
used to create the access token. This is very similar to the mapping =
mechanism between Kerberos principal names and /etc/passwd names on Unix =
systems to establish a local uid for access checking.</FONT></P>
<BR>

<P><FONT SIZE=3D2>&gt; -----Original Message-----</FONT>

<BR><FONT SIZE=3D2>&gt; From: Nicolas Williams [<A =
HREF=3D"mailto:willian@ubsw.com">mailto:willian@ubsw.com</A>]</FONT>

<BR><FONT SIZE=3D2>&gt; Sent: Wednesday, May 03, 2000 8:25 AM</FONT>

<BR><FONT SIZE=3D2>&gt; To: Booker C. Bense</FONT>

<BR><FONT SIZE=3D2>&gt; Cc: ietf-cat-wg@lists.Stanford.EDU; =
krb-protocol@mit.edu</FONT>

<BR><FONT SIZE=3D2>&gt; Subject: Re: Ticket extensions in Kerberos =
revisions</FONT>

<BR><FONT SIZE=3D2>&gt; </FONT>

<BR><FONT SIZE=3D2>&gt; </FONT>

<BR><FONT SIZE=3D2>&gt; </FONT>

<BR><FONT SIZE=3D2>&gt; On Wed, 03 May 2000, Greg Hudson =
&lt;ghudson@MIT.EDU&gt; wrote:</FONT>

<BR><FONT SIZE=3D2>&gt; &gt; &gt;&gt; As Ken pointed out, it is =
significant to save apps the </FONT>

<BR><FONT SIZE=3D2>&gt; extra work,</FONT>

<BR><FONT SIZE=3D2>&gt; &gt; &gt;&gt; the extra tickets (why should a =
server ever have to &quot;log </FONT>

<BR><FONT SIZE=3D2>&gt; in&quot; -- get</FONT>

<BR><FONT SIZE=3D2>&gt; &gt; &gt;&gt; a TGT?), etc.</FONT>

<BR><FONT SIZE=3D2>&gt; &gt; </FONT>

<BR><FONT SIZE=3D2>&gt; &gt; &gt; - Because it's secure and extensible =
and a much better model? </FONT>

<BR><FONT SIZE=3D2>&gt; &gt; </FONT>

<BR><FONT SIZE=3D2>&gt; &gt; Separating out authorization database from =
the KDC database does not</FONT>

<BR><FONT SIZE=3D2>&gt; &gt; implicitly require the servers (other than =
the authorization server)</FONT>

<BR><FONT SIZE=3D2>&gt; &gt; to &quot;log in.&quot;</FONT>

<BR><FONT SIZE=3D2>&gt; &gt; </FONT>

<BR><FONT SIZE=3D2>&gt; &gt; Here is an example:</FONT>

<BR><FONT SIZE=3D2>&gt; &gt; </FONT>

<BR><FONT SIZE=3D2>&gt; =
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 1. User gets TGT =
(containing no auth data)</FONT>

<BR><FONT SIZE=3D2>&gt; =
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 2. User contacts =
authorization server and presents a ticket</FONT>

<BR><FONT SIZE=3D2>&gt; =
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
and authenticator, and asks for authorization data for</FONT>

<BR><FONT SIZE=3D2>&gt; =
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&quot;fooservice&quot;.</FONT>

<BR><FONT SIZE=3D2>&gt; =
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 3. Authorization =
server gets credentials for &quot;fooservice&quot;.</FONT>

<BR><FONT SIZE=3D2>&gt; =
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 4. Authorization =
server sends to user its ticket (not the</FONT>

<BR><FONT SIZE=3D2>&gt; =
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
session key, of course) and sends the authorization data</FONT>

<BR><FONT SIZE=3D2>&gt; =
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
sealed using its session key.</FONT>

<BR><FONT SIZE=3D2>&gt; =
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 5. User contacts =
&quot;fooservice&quot; and presents its normal</FONT>

<BR><FONT SIZE=3D2>&gt; =
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
ticket and authenticator, plus the bundle it got from the</FONT>

<BR><FONT SIZE=3D2>&gt; =
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
authorization server.</FONT>

<BR><FONT SIZE=3D2>&gt; &gt; </FONT>

<BR><FONT SIZE=3D2>&gt; &gt; The server can now verify the authorization =
data using the </FONT>

<BR><FONT SIZE=3D2>&gt; session key</FONT>

<BR><FONT SIZE=3D2>&gt; &gt; located in the authorization server's =
ticket.&nbsp; No need for </FONT>

<BR><FONT SIZE=3D2>&gt; the server</FONT>

<BR><FONT SIZE=3D2>&gt; &gt; to go off and check.</FONT>

<BR><FONT SIZE=3D2>&gt; </FONT>

<BR><FONT SIZE=3D2>&gt; Hey, that's pretty good. This would solve the =
problem of </FONT>

<BR><FONT SIZE=3D2>&gt; anonymous user</FONT>

<BR><FONT SIZE=3D2>&gt; login info lookups as well. So if such a system =
could be standardized</FONT>

<BR><FONT SIZE=3D2>&gt; then we can get rid of the Kerberos extensions =
altogether.</FONT>

<BR><FONT SIZE=3D2>&gt; </FONT>

<BR><FONT SIZE=3D2>&gt; Nico</FONT>

<BR><FONT SIZE=3D2>&gt; --</FONT>

<BR><FONT SIZE=3D2>&gt; </FONT>

<BR><FONT SIZE=3D2>&gt; =
-++**=3D=3D--++**=3D=3D--++**=3D=3D--++**=3D=3D--++**=3D=3D--++**=3D=3D--=
++**=3D=3D</FONT>

<BR><FONT SIZE=3D2>&gt; This message was posted through the Stanford =
campus mailing list</FONT>

<BR><FONT SIZE=3D2>&gt; server.&nbsp; If you wish to unsubscribe from =
this mailing list, send the</FONT>

<BR><FONT SIZE=3D2>&gt; message body of &quot;unsubscribe =
ietf-cat-wg&quot; to </FONT>

<BR><FONT SIZE=3D2>&gt; majordomo@lists.stanford.edu</FONT>

<BR><FONT SIZE=3D2>&gt; </FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01BFB528.7A7572E0--

home help back first fref pref prev next nref lref last post