[29724] in Kerberos
Re: Conceptual Questions.
daemon@ATHENA.MIT.EDU (Ken Raeburn)
Wed Apr 23 12:21:02 2008
From: Ken Raeburn <raeburn@MIT.EDU>
To: "Tadoori (EXT), Vilas" <vilas.tadoori.ext@siemens.com>
In-Reply-To: <0419C2808E620348A3119DCCE2A7A69506CFAD9D@USCIMPLM004.net.plm.eds.com>
Message-Id: <11D7E296-A517-4C1C-AADF-1CC105DFCB56@mit.edu>
Mime-Version: 1.0 (Apple Message framework v919.2)
Date: Wed, 23 Apr 2008 12:18:42 -0400
Cc: kerberos@MIT.EDU
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: kerberos-bounces@MIT.EDU
On Apr 23, 2008, at 03:10, Tadoori (EXT), Vilas wrote:
> Hi All,
>
> I have few questions and would appreciate if you can help me out on
> the
> same.
>
> 1) Is it possible for the client-side application to obtain a
> security
> token from the Host OS without talking to the Kerberos server ?
In theory, you can use a service's secret key (such as that of the
"host" service, used for login-type services) to create credentials
that can be sent to the service and "prove" the sender to be, well,
anyone you want. For example, a setuid-root program could look at the
uid invoking it and print up credentials using the associated user name.
However, these credentials cannot be used with any other service, only
with that one. The Authentication Service and Ticket-Granting Service
on the KDC are the only ones that can generate credentials useable
with other services.
So, if you're looking for generally-useable credentials for network
services, the answer is probably "no".
> 2) What are the types of tokens one can obtain from an Kerberos
> server?
> For example, can a token be obtained that allows a receiver to vend
> additional tokens?
No. Without knowing the secret keys, you can't print up new
credentials. That's what makes the AS/TGS special -- it's got all the
keys.
> Or, that a token can be issued which limits the user
> to use with a certain application?
Technically, any credential is valid for use with exactly one service
principal name. Multiple applications may use the same service
principal (e.g., ssh and rlogin and telnet all use the "host"
service), or it may be more special-purpose (e.g., "imap"). The
Kerberos protocol and implementations do not care. So you could get
an initial ticket for "imap", instead of a TGT, and then IMAP is all
you could access. It's not clear to me if this is the sort of thing
you're thinking about.
There's an "authorization data" field which can impose restrictions on
what the user is allowed to do, but the MIT implementation doesn't
really make much use of it yet, and there isn't much in the way of
specifications for its use, aside from Microsoft's PAC data. I
suppose it might be used to say, "ssh good, rlogin bad", if you only
want to allow a subset of the available services that share a service
principal name, but it would take some work. And depending on your
setup, access control lists might be a better way.
Does this help?
--
Ken Raeburn, Senior Programmer
MIT Kerberos Consortium
________________________________________________
Kerberos mailing list Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos
