krb5_rd_cred() ?

Tue Nov 30 11:58:41 EST 2004

I think that sounds good, but none of those steps require a
krb5_rd_cred() call.  So unless you've got other tricks up your sleeve
you can leave out any calls to krb5_rd_cred().  All your credentials
should be given to you directly from krb5_get_init_creds_password() or
equivalent call.

Derrick

-----Original Message-----
From: Jason Gerfen [mailto:jason.gerfen at scl.utah.edu] 
Sent: Dienstag, 30. November 2004 11:54
To: Derrick Schommer
Cc: krbdev at mit.edu
Subject: Re: krb5_rd_cred() ?

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 

--------------------------------------------------------

DISCLAIMER:   The information contained in this e-mail is confidential and is intended solely for the review of the named addressee, and in conjunction with specific Acopia Networks business.  Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you are unable to treat this information accordingly, or are not the intended recipient, please notify us immediately by returning the e-mail to the originator.  