any non-krb5int way to pass a keyblock to get_init_creds?
Chris Hecker
checker at d6.com
Mon Aug 1 16:58:45 EDT 2011
> How are you winding up with a key and needing to make an initial
> ticket request with it?
Well, it's looking like I'm not going to have to do it this way now, but
I was exploring different ways of having kerberos services log into
CoSign, and one of the "recommended" ways is to pass the CoSign cgi the
password in a POST like a normal user login (over SSL, but still).
Services don't have a password, so I was thinking about doing a simple
modification to CoSign to also accept a base64'd key. It was either
that, or assign a password to all my services, which seemed worse
(obviously neither is great). But, someone on the cosign-discuss list
said I can do a thing with mod_auth_kerb with an alternate path to the
cosign.cgi that will get me the authn cookies that I can then use to
access the main resources without transferring any keys or passwords,
which clearly is a lot better. I was also looking at kx509, but that
project seems a bit moribund, and even so it seemed like more work and
heavier weight than just setting up mod_auth_kerb and hacking up an
SPNEGO token wrapper for a krb5 ticket[*].
Chris
* I guess I will make a simple function to create this wrapper using the
builtin asn library, since I don't want to deal with all the gssapi
stuff just to get this simple block of data if I've already got a krb5
ticket sitting in a buffer...or, is there a simple way to do this with
krb5's public gssapi/spnego functions?
On 2011/08/01 08:43, Greg Hudson wrote:
> On Sun, 2011-07-31 at 00:43 -0400, Chris Hecker wrote:
>> It seems there's no exposed way to call krb5_get_init_creds with a key
>> directly. If I've got a key that's not stored in a keytab (like it got
>> handed to me some other way), it looks like the best/only way to do this
>> is to create a MEMORY keytab, manually create a keytab_entry, add the
>> entry, and then pass that to get_init_creds_keytab?
>
> That's right for current interfaces.
>
> There used to be a krb5_get_in_tkt_with_skey(), which is still there as
> a deprecated interface. When the initial ticket interfaces were revised
> in 1997, I think there was a belief that a krb5 app (as opposed to an
> RFC 3961 app) shouldn't need to traffic in keyblocks, so that interface
> was dropped.
>
> How are you winding up with a key and needing to make an initial ticket
> request with it?
>
>
>
More information about the Kerberos
mailing list