krb5_rd_cred() ?

[Jason Gerfen]

I really appreciate all of your help, just so I understand the steps I 
need to take next:

Initialize the error codes for the kerberos libs.
being reading in my configuration options and setting them
begin authentication with username & password as well as using my stored 
config options to do it properly
do verification on ticket upon successful authentication
store ticket information until user logs out

If I have missed a step please let me know.



Derrick Schommer wrote:

>Aah, sorry, if you don't have an auth context at the point where you
>want to call rd_cred() then you're a few steps behind what is actually
>needed.
>
>And as Ken said in his latest response, the KRB5KRB_AP_ERR_SKEW doesn't
>need to be checked for anything.  When you authenticate the credentials
>a common error that you will get back is KRB5KRB_AP_ERR_SKEW.  I get
>this typically when my client isn't using NTP or some other clock
>synchronization.
>
>But to continue on with the current question about auth contexts...
>
>The auth-context is very much like a standard krb5_context, except that
>it holds mostly authentication information such as key sizes, key types,
>checksums, available key enumerations and all that technical jargon.
>
>You can initialize one of those with:
>
>krb5_auth_context authCtx;
>krb5_auth_con_init( &context, &authCtx );
>
>I populate my auth-context with user keys and such.  (see
>krb5_auth_con_setuseruserkey()), and I also set some flags for use with
>authentication type routines.  There is a thing called
>krb5_auth_con_setflags() that allows you to set neat options on your
>authentication (like storing sequence numbers, time stamps, subkeys,
>etc).
>
>You need this stuff setup so you can extract user credentials from
>certain Kerberos requests.  A good example is a request for a
>forwardable TGT (I call krb5_fwd_tgt_creds() which is not really
>documented).  
>
>The response will include a set of credentials that I can use to send
>forwardable TGT's to remote hosts (not a huge krb5 security guy so I
>might be explaining that part a little wrong or improper, but the plot
>is thickening...).  In order to extract the response from the Kerberos
>"data" properly (using all the Kerberos API's so I don't have to do
>validation, caching, ASN.1 decoding, etc.) I call krb5_rd_cred() which
>will read the credentials out of the "data" block I sent it.
>
>Here is a simple example with more function calling context:
>
>krb5_data    data;          // Currently unpopulated, but we'll remedy
>that.
>krb5_creds **ppInputCreds;  // Used in rd_cred()
>
>krb5_fwd_tgt_creds( context, authContext, KRB5_TGS_NAME, cred->client,
>cred->server, credCache, 1 /* forwardable ticket */, &data );
>
>This will make the TGT request (watch ethereal and you'll see), and the
>response is a big block o' data that I can't really do much with.  That
>data is stored in "&data" for me to work with thanks to the krb5 API.
>But since I don't really understand the ASN.1 encoding, the data
>structures, and such (and nor do I care) I can send that "data" to other
>'read' API calls in order to do the extraction for me.
>
>Now I can do:
>
>krb5_rd_cred( context, authContext, &data /* input data  */,
>&ppInputCreds /* output */, NULL );
>
>That will extract credentials data from my big 'data' variable that were
>stored within it (in asn.1 encoding).  Those credentials will be stored
>in ppInputCreds (sorry for the Microsoftish Hungarian notation "pp").
>That is an 'array' of credentials (it might be one as it is in my case).
>
>My entire goal was to get those credentials out of my "data" block, so I
>then free it up that silly block of data now:
>
>krb5_free_contents( context, &data);
>
>Since I have the credentials now in ppInputCreds I can do other things
>with them, like krb5_mk_1cred():
>
>krb5_data *pKrbCred;   // A KRB5_CRED structure "as seen on tv"
>(APPLICATION 22 message)
>krb5_mk_1cred( context, authContext, *ppInputCreds, &pKrbCred, NULL );
>
>This gets me my "rfc complient" Application 22 message which I can send
>on to a remote host with a few more function calls.  Does that make any
>sense?
>
>So in my case I am using the rd_cred() to read credentials so I can use
>them to give to another host (or store locally, or whatever your
>pleasure). 
>
>Hopefully that more clearly explains what my "data" variable does, and a
>little about auth contexts.  I am not a professional, but I do know you
>need an auth-context in order to get this to work.  And if its not
>initialized correctly you can get encryption mismatches and random
>errors ;-)
>
>Thanks,
>
>Derrick
>PS: Kerberos team, if my explanation is wrong to the point of making his
>issue harder to understand then please correct me.
>
>-----Original Message-----
>From: Jason Gerfen [mailto:jason.gerfen at scl.utah.edu] 
>Sent: Dienstag, 30. November 2004 10:56
>To: Derrick Schommer
>Cc: krbdev at mit.edu
>Subject: Re: krb5_rd_cred() ?
>
>Yeah well that allows me to call the function.  I think I need to 
>rephrase the question, I am not sure where I am to get the data to pass 
>in as arguments.  More specificly the authcontext, data & ppinputcreds 
>arguments.  I am assuming that the ppinput creds is going to be my creds
>
>structure so that is pretty clear.  I am still lost on where to obtain 
>my authcontext & data arguments.  Any help with this those two items is 
>appreciated.
>
>Derrick Schommer wrote:
>
>  
>
>>Yes, that call uses the "ever popular" triple pointer syndrome.
>>
>>Try this:
>>
>>krb5_creds **ppInputCreds;
>>krb5_data    data;
>>krb5_rd_cred( context, authContext, &data, &ppInputCreds, NULL );
>>
>>And the cleanup call that will free up your triple pointer nightmare:
>>
>>krb5_free_tgt_creds( context, ppInputCreds);
>>
>>
>>Not sure if that "free_tgt_creds()" is the call you want, but it cleans
>>the triple pointer mess.  I used rd_cred in order to get the tgt from
>>the creds structure so it was what I needed (and since it cleaned
>>    
>>
>triple
>  
>
>>pointers the key and lock seemed to fit together).
>>
>>Hope that helps..
>>
>>Derrick
>>-----Original Message-----
>>From: Jason Gerfen [mailto:jason.gerfen at scl.utah.edu] 
>>Sent: Dienstag, 30. November 2004 10:03
>>To: krbdev at mit.edu
>>Subject: krb5_rd_cred() ?
>>
>>I have been looking for the correct function to call when doing a 
>>KRB5KRB_AP_ERR_SKEW check.  As of yet I believe the krb5_rd_cred() 
>>function is what I am looking for.  However I have found several 
>>security warnings with the use of this function. Also I have no idea 
>>what arguments to pass this call for it to work correctly.  According
>>    
>>
>to
>  
>
>>some documentation I have it as the following:
>>
>>krb5_rd_cred( krb5_context context,
>>                       krb5_auth_context auth_context,    // What is 
>>this, where would I gather this from?
>>                       krb5_data *precreddata,                 // Not 
>>sure where I would get this data from either...
>>                       krb5_creds ***pppcreds,                 // the 
>>same here
>>                       krb5_replay_data *outdata );          // and
>>again.
>>
>>The documentation I have found is not clear on where I would get the 
>>data to pass to this function as arguments.  Any help would be greatly 
>>appreciated.
>>
>> 
>>
>>    
>>
>
>
>  
>


-- 
Jason Gerfen
Student Computing
Marriott Library
801.585.9810
jason.gerfen at scl.utah.edu

"And remember... If the ladies
 don't find you handsome, they
 should at least find you handy..."
             ~The Red Green show