Conceptual Questions.

[Tadoori (EXT), Vilas]

Ken,

Thanks for your explanation and I agree with your thoughts.

I would go this directiion and if I am struck I will get back to you.

Cheers,
Vilas

-----Original Message-----
From: Ken Raeburn [mailto:raeburn at MIT.EDU] 
Sent: Wednesday, April 23, 2008 9:49 PM
To: Tadoori (EXT), Vilas
Cc: kerberos at mit.edu
Subject: Re: Conceptual Questions.

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