> That's definitively not how kerberos works. In fact, the password is > not sent to the KDC to obtain credentials.
Yeah, sorry, I meant the krb5 API that cosign talks to, I know how kerberos works at the protocol level and that credentials aren't passed over the wire, etc. I just meant it gets tickets to authenticate. > Seems like this is actually your problem, not renewable kerberos > tickets. I think this is an oversimplification, but hopefully my other mail explains the use case more clearly. > I would think this case would be handled in an authorization step, > rather than during authentication. Not sure exactly what you mean here. Kerberos doesn't do authz, yet it still has allow_tix and whatnot, so the line is a little blurry already, and the feature I want is on the authn side of the line (as far as krb5 is concerned). I don't need fancy authz stuff like acls, just the ability to ban somebody by setting -allow_tix and have that be respected by everybody who's using krb5 to authenticate my users. Chris On 2012/11/27 11:56, Wesley Craig wrote: > On 27 Nov 2012, at 14:08, Chris Hecker <chec...@d6.com> wrote: >> In >> other words, it takes the user's credentials, passes them to the KDC, >> and if a TGT comes back, the user is authenticated, right? How else >> could it work? > > That's definitively not how kerberos works. In fact, the password is not > sent to the KDC to obtain credentials. Instead, credentials are requested > (typically an encrypted request is sent), and encrypted credentials are > returned. If you can decrypt the credentials, then you may use them. > Further, cosign immediately attempts to use the credentials by requesting a > service ticket. This tests whether the KDC itself has been spoofed. > >> I understand what you're saying about how the other backends not >> supporting renewable authentication would make this a kerberos-specific >> feature, but I thought using kerberos for the authentication backend was >> pretty common with cosign. > > If you aren't use kerberos beyond initially validating the user password, > then renewing kerberos tickets buys you nothing. > >>> My recommendation is to choose slightly different numbers for the >>> timeout so that the sort of multi-work-session overlap you describe >>> does not occur. >> >> Yeah, I thought about this as I was typing my reply but forgot to >> include it in the mail...maybe I'm making it worse by slamming both to >> 24 hours, like you say. At least, if the soft timeout expires, they'll >> have to get a fresh ticket and reset the clock. I'll do this first, >> since it's relative easy, thanks. > > Seems like this is actually your problem, not renewable kerberos tickets. > >> If the user is checking back in >> often enough to not trigger the soft timeout, they'll eventually hit the >> hard timeout and potentially get screwed (bad experience at best, lose >> data on a POST that straddles the hard timeout at worst). > > True, but setting the idle timeone = hard timeout is exactly how this case > gets exercised. > >> The high level use case here is I want short lifetimes so I can revoke >> credentials effectively/quickly, but I want good user experience for >> valid users, which means infrequent login prompts. The risk for me is >> not somebody sitting down and a workstation and using somebody else's >> login, the risk is banning a user and them continuing to have access, so >> I want short lifetimes and renews to fail if they're banned. It seems >> like this use case would not be too hard for cosign to support. > > I would think this case would be handled in an authorization step, rather > than during authentication. > > :wes > ------------------------------------------------------------------------------ Keep yourself connected to Go Parallel: DESIGN Expert tips on starting your parallel project right. http://goparallel.sourceforge.net _______________________________________________ Cosign-discuss mailing list Cosign-discuss@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/cosign-discuss
