any non-krb5int way to pass a keyblock to get_init_creds?

[Chris Hecker]

> 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?
>
>
>