Bug 737123 - NewPkg: kstart for renewing kerberos tickets for services
Summary: NewPkg: kstart for renewing kerberos tickets for services
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: distribution
Version: 6.2
Hardware: Unspecified
OS: Unspecified
unspecified
medium
Target Milestone: rc
: ---
Assignee: Dmitri Pal
QA Contact: Brock Organ
URL:
Whiteboard:
Depends On:
Blocks: 674578 737124
TreeView+ depends on / blocked
 
Reported: 2011-09-09 16:52 UTC by Perry Myers
Modified: 2011-09-30 21:02 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
: 737124 (view as bug list)
Environment:
Last Closed: 2011-09-30 21:02:51 UTC


Attachments (Terms of Use)

Description Perry Myers 2011-09-09 16:52:18 UTC
Description of problem:
Matahari will use kerberos for auth from broker to broker as well as agent to broker, and to do this we need a way to programatically renew tickets otherwise kerberos usage is not useful

kstart provides a way to do this, but the package is not in RHEL

Comment 2 Nalin Dahyabhai 2011-09-15 19:03:57 UTC
Dumb question: why isn't the broker learning to fetch credentials on its own?  That's the route that rpc.gssd and sssd have taken for the cases where they behave as Kerberos clients.

Comment 3 Perry Myers 2011-09-15 20:19:38 UTC
@nalin: The core issue as I understand it is that qpid (both client and broker) utilize SASL which completely abstracts away the kerberos details.  If we made qpid aware that it was using kerberos and had to have programatic kinit done we'd be breaking that abstraction model.

So how can we do re-kinit inside of qpid w/o violating the SASL layering model?

(the above paraphrased from what tross has told me)

Comment 4 Nalin Dahyabhai 2011-09-15 21:02:03 UTC
(In reply to comment #3)
> @nalin: The core issue as I understand it is that qpid (both client and broker)
> utilize SASL which completely abstracts away the kerberos details.  If we made
> qpid aware that it was using kerberos and had to have programmatic kinit done
> we'd be breaking that abstraction model.

If you're attempting to be a Kerberos (or GSSAPI) client and you're not being run by a user who has already obtained the credentials you're going to need, you pretty much have to.

> So how can we do re-kinit inside of qpid w/o violating the SASL layering model?

Today, you can't.  In the future, if/when GSSAPI starts fetching credentials when you don't already have some, it may become redundant, but that's not going to happen soon.

Comment 5 Perry Myers 2011-09-20 03:31:20 UTC
> Today, you can't.  In the future, if/when GSSAPI starts fetching credentials
> when you don't already have some, it may become redundant, but that's not going
> to happen soon.

Ok. so the above justifies why we need kstart as a part of RHEL then :)

Comment 6 Nalin Dahyabhai 2011-09-20 19:08:27 UTC
On the contrary, it points to this being something a daemon should be prepared to do for itself rather than requiring a separate package to be installed and configured to act as a workaround.

Comment 7 Perry Myers 2011-09-20 19:13:16 UTC
But that goes back to my original question... how do we do this without violating the SASL layering?  i.e. all qpidd knows about is SASL, it shouldn't need to know anything kerberos specific, as that completely violates the abstraction layer.

The right solution is (as you say) to get GSSAPI to incorporate ticket renewals, but until that happens it looks like kstart is a reasonable workaround that does involve embedding kerberos specific logic into daemons

Comment 8 Nalin Dahyabhai 2011-09-20 19:21:41 UTC
(In reply to comment #7)
> But that goes back to my original question... how do we do this without
> violating the SASL layering?  i.e. all qpidd knows about is SASL, it shouldn't
> need to know anything kerberos specific, as that completely violates the
> abstraction layer.

Yeah, that's unfortunate.

> The right solution is (as you say) to get GSSAPI to incorporate ticket
> renewals, but until that happens it looks like kstart is a reasonable
> workaround that does involve embedding kerberos specific logic into daemons

Other packages add support directly.  Why does qpidd need to drag another dependency onto the system instead of doing the same?  We're not talking about large patches here.

Comment 9 Ted Ross 2011-09-20 19:29:53 UTC
Nalin,

Can you point me to another package that has this support so I can see how it was hooked in?  Is there a callback or a script invocation when the ticket expires?  Do we need to infer expiration by failure of the encryption?

Comment 10 Perry Myers 2011-09-20 19:34:18 UTC
Just one aside...

Ticket renewals need to be done both by qpidd (the broker) and also the qpid client code, which is a library (not a daemon intrinsically, though it would often be run from a daemon or service)

So tross, we just need to make sure that we put this new logic in both the broker and the qpid clients, so that QMF agents can basically inherit the functionality.  ack?

Comment 11 Perry Myers 2011-09-20 19:35:13 UTC
Further aside, we'll also need this to work on win32 platforms as well, at least for the qpid client code (we don't expect the brokers to work at all on win32)

Comment 12 Dmitri Pal 2011-09-20 20:39:58 UTC
The best would be for the GSSAPI library to acquire tickets automatically on behalf of the service as Nalin pointed out.
I think the requirement to have an external entity responsible for ticket renewal is reasonable for QPID so IMO something should be done. The question how the problem will/should be solved, i.e. by enhancing GSSAPI, packaging k5start or forking it or contributing a small service to qpid source that would be started when kerberos is configured is yet to be decided. 
Identity team owns the ticket and will figure it out.

Comment 13 Nalin Dahyabhai 2011-09-20 20:56:45 UTC
(In reply to comment #9)
> Nalin,
> 
> Can you point me to another package that has this support so I can see how it
> was hooked in?  Is there a callback or a script invocation when the ticket
> expires?  Do we need to infer expiration by failure of the encryption?

nfs-utils does it in gssd_get_single_krb5_cred() in krb5_util.c, potentially using an in-memory ccache (if you don't have multiple processes, that's the least complicated way to go); it's called by gssd_refresh_krb5_machine_credential(), which goes to some lengths to figure out the right principal name to use.

sssd does it in ldap_child_get_tgt_sync() in ldap_child.c, taking note of the expiration date on the creds it obtains (times.endtime, give or take the KDC's clock offset) to schedule the next attempt; it forks a child to do the heavy lifting, so it uses a file-based ccache.

certmonger does it in cm_submit_x_make_ccache() in submit-x.c, using an in-memory ccache; the helper process isn't expected to be run again until after the creds expire, so the ccache is allowed to disappear when the helper exits.

The server should return GSS_S_CREDENTIALS_EXPIRED if the GSSAPI server rejected the authentication request due to the client's ticket having expired.

Comment 14 Dmitri Pal 2011-09-30 21:02:51 UTC
We decided to do it differently. Closing the distribution bug.


Note You need to log in before you can comment on or make changes to this bug.