Re: gss_accept_sec_context server principal
> "Cesar" == Cesar Garcia <[EMAIL PROTECTED]> writes: Cesar> Hi, I'm am trying to change the behavior of a functioning Cesar> GSS-enabled application server such that the server Cesar> principal and corresponding keytab entry used by Cesar> gss_accept_sec_context is determined dynamically based on Cesar> the server principal named in the client's ticket Cesar> (implicitly specified by the input token to Cesar> gss_accept_sec_context). GSS_C_NO_CREDENTIAL will do this in 1.3. The patches would be mildly difficult for me to extract right now though. Kerberos mailing list [EMAIL PROTECTED] https://mailman.mit.edu/mailman/listinfo/kerberos
Re: High level thoughts on justifying the use of Kerberos
On Sun, Mar 16, 2003 at 05:52:12PM -0800, Mike wrote: > I'm getting ready to propose the use of Kerberos in our division. > I've done some reading up on the subject and in general I like what I > see. However, I have this nagging thought in my head that my > management and some of the network weenies will have reservations. > Good! Kerberos is a pretty fair way to go if you are going to use a trusted third party model for your authentication. Keep in mind kerberos is an authentication method, and not an "authorization" method. That is, depending on your needs you may have to layout a plan for handling authorization for your systems. (ie. Just because someone has a krb5 ticket, meaning they have succesfully authenticated, doesn't mean that person should be allowed on machine X.) > My question is to formalize a list of the benefits and risks of > implementing Kerberos. Specifically, are there things that I should > be worried about? I know this is very open ended and somewhat vague > but that's my starting point on the issue. I want to try to head off > any FUD attacks and also want to understand the implications of what > I'm proposing. > Hmm. Heres some of my thoughts on a list for you: Benefits: Centralized authentication mechanism Support for Windows, MAC, UNIXes of various flavors... Encryption Risks: Its centralized.. if the KDC is exploited all bets are off. Thats a short list, Im sure I could come up with more as could others.. but Im a little short on time this evening. ;) Good luck, I would expect your management to welcome kerberos, even the network folks shouldnt really be bothered. I cant imagine why they would care one way or another.. its just a couple of ports. ;) Kerberos mailing list [EMAIL PROTECTED] https://mailman.mit.edu/mailman/listinfo/kerberos
High level thoughts on justifying the use of Kerberos
I'm getting ready to propose the use of Kerberos in our division. I've done some reading up on the subject and in general I like what I see. However, I have this nagging thought in my head that my management and some of the network weenies will have reservations. My question is to formalize a list of the benefits and risks of implementing Kerberos. Specifically, are there things that I should be worried about? I know this is very open ended and somewhat vague but that's my starting point on the issue. I want to try to head off any FUD attacks and also want to understand the implications of what I'm proposing. Thanks in advance. Kerberos mailing list [EMAIL PROTECTED] https://mailman.mit.edu/mailman/listinfo/kerberos
Re: JESUS IS LORD
> > What is up with all the spam on this list? Kerbdev, too... > > We update the header patterns for mailman to check, and the spammers > keep using new subjects we're not catching. I've added a few more, > this weekend, on the Kerberos list; I'll update krbdev soon. > > Mailman's header-matching techniques are better than nothing, but > they still leave a lot to be desired. (And the Kerberos team > doesn't control the mail server, so we can't drop in spamassassin or > ifile or anything like that.) > > We'll keep trying Why not introduce bmf (http://sourceforge.net/projects/bmf/) into the mail delivery process? I've just started using it and it's night and day. Bogus messages should be moderated since it's an adaptive filter and has to be told what's good and bad, but I trained my filter with 12K messages and ran it over some good mail for good measure and I can't even begin to explain how happy I am with the lack of SPAM that I'm getting. I'm actually going around and de-obfuscating my email addy now because my inbox is clear of the crap that I used to be getting. It takes a few days of training and explicitly setting what's good and bad, but I'm a believer now. I'm actually debating if I can train it to filter complaints from other people who are bitching about SPAM, as SPAM now. ::grin:: -sc PS I'm committing the port of this to FreeBSD in a few days when the freeze is lifted: htt://people.FreeBSD.org/~seanc/bmf.shar -- Sean Chittenden Kerberos mailing list [EMAIL PROTECTED] https://mailman.mit.edu/mailman/listinfo/kerberos
Re: JESUS IS LORD
Sean Chittenden <[EMAIL PROTECTED]> writes: > Why not introduce bmf (http://sourceforge.net/projects/bmf/) into the > mail delivery process? See previous message re not controlling the mail server. :-( Ken Kerberos mailing list [EMAIL PROTECTED] https://mailman.mit.edu/mailman/listinfo/kerberos
gss_accept_sec_context server principal
Hi, I'm am trying to change the behavior of a functioning GSS-enabled application server such that the server principal and corresponding keytab entry used by gss_accept_sec_context is determined dynamically based on the server principal named in the client's ticket (implicitly specified by the input token to gss_accept_sec_context). There are various reasons for wanting to do this. Migrating to DNS is one - we would like to isolate applications from naming changes on the client hosts (or the server hosts for that matter) so that application servers can accept tickets for either: /@MS.COM /[EMAIL PROTECTED] thereby, allowing various client/hosts to migrate to DNS independently. is generally the name of the application. is the short name (our current hostname resolution renders short names). This short name could either be an actual host name or a one of several VCS service name. In other words, there could be many permutations, and I would like avoid any brute force approaches where I try every possible server principal name. [of course, I would populate the application server's keytab file with all of the necessary keytab entries so that it can assume any of the above identities - in fact this works already for kshd/klogind, which of course are not written with GSSAPI] My first attempt was to specify GSS_C_NO_CREDENTIAL for the verifier credential handle. This appeared to reveal a bug in gss_accept_sec_context(): (I'll send a separate email to [EMAIL PROTECTED] about this). == start bug description == krb5_gss_accept_sec_context acquires a default cred via krb5_gss_acquire_cred, if the supplied verifier_cred handle is GSS_C_NO_CREDENTIAL - which is places in the variable "cred_handle" It then proceeds to try to validate verifier_cred_handle, which in my case is GSS_C_NO_CREDENTIAL, rather than the new obtained credential (cred_handle). So this fails unnecessarily. So I fix this so that it validates cred_handle (which it obtains) rather than verifier_cred_handle (GSS_C_NO_CREDENTIAL). == end bug description == Nonetheless, in obtaining a credential handle, krb5_gss_acquire_cred will determine the server principal name. As invoked by krb5_gss_accept_sec_context, it will obtain a handle to the credential based on logic for GSS_C_NO_NAME and GSS_C_ACCEPT (cred_usage supplied by krb5_gss_accept_sec_context). In doing so, it invokes krb5_sname_to_principal, which determine the default principal name based on hostname and sname arguments (both NULL). This results in a server principal name constructed from an sname of "host" and a hostname based on gethostname which is then resolved via gethostbyname/gethostbyaddr. krb5_gss_acquire_cred then attempts to extract the keytab entry for this principal. Of course, this is not what I want. Calling gss_acquire_cred from my application using GSS_C_NO_NAME has the same affect. Has anyone attempted to write a GSS-enabled application server that can assume more than one different identities, based on the server principal name specified in the client's ticket. Is there another approach that will allow me to do this? The only other thought I have is to try to extract the server principal name for the token supplied by the client. This, however, seems like I am breaking rules by not treating tokens as opaque objects. I haven't investigated this approach yet, I was hoping there was a more natural approach than this. Any suggestions are highly appreciated. Thanks, Cesar Kerberos mailing list [EMAIL PROTECTED] https://mailman.mit.edu/mailman/listinfo/kerberos
