Conceptual Questions.

[Ken Raeburn]

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