From raeburn at MIT.EDU  Tue Aug  5 15:28:23 2008
From: raeburn at MIT.EDU (Ken Raeburn)
Date: Tue, 5 Aug 2008 15:28:23 -0400
Subject: old ovsec and kadm5 interfaces and protocol
Message-ID: <B912F7AE-91B1-4113-B3F2-FCBD1D46A5E5@mit.edu>

Does anyone know of software using the OV kadmin library interface  
(ovsec_kadm_init and friends) or version 1 of the kadm5 API (- 
DUSE_KADM5_API_VERSION=1) in the MIT kadmin library?  Version 2 has  
been the default for any code using the kadm5_* functions without  
defining USE_KADM5_API_VERSION specially.

We do build a Kerberos password-changing program using the old API,  
but at least as far back as 1.2.2, it wasn't actually installed by  
default, just built for some internal testing.

We don't install the header files needed to use these functions, but  
that doesn't stop some people from building against the internal  
headers in our source tree.  We're hoping to delete the support for  
the v1 API (and the corresponding RPC protocol) sometime soon, as it  
significantly complicates some bits of the code, making them harder to  
maintain.  If we can ditch v1, analysis of the code becomes easier,  
and some of it can probably be maintained with tools like rpcgen  
instead of by hand.

So if you're using the v1 APIs in the MIT kadm5 libraries, speak up,  
or your programs may start breaking in a coming release....

Ken

From hotz at jpl.nasa.gov  Wed Aug  6 13:00:30 2008
From: hotz at jpl.nasa.gov (Henry B. Hotz)
Date: Wed, 6 Aug 2008 10:00:30 -0700
Subject: kerberos password test function source code
In-Reply-To: <mailman.527.1218039324.5996.krbdev@mit.edu>
References: <mailman.527.1218039324.5996.krbdev@mit.edu>
Message-ID: <0C006618-8705-4A51-A72D-1CD74076E852@jpl.nasa.gov>

I think you're going too low level.  You should be supplying the  
"trial" password and the Kerberos principal as arguments.  (The  
principal could be a simple username if you know it's always just a  
simple user in the default realm.)

The relevant function to use is krb5_get_init_creds_password().  It's  
sufficient to tell you that somebody on the 'net says the password is  
OK.

Presumably you also want to know that "somebody" is actually your  
Kerberos server.  In that case you also need to request a service  
ticket for a service you already have a keytab for, and verify the  
ticket against that keytab.  Looks like krb5_verify_init_creds() is a  
routine common to MIT and Heimdal for that purpose.

On Aug 6, 2008, at 9:15 AM, krbdev-request at mit.edu wrote:

> Date: Tue, 29 Jul 2008 21:02:41 -0400
> From: Nathanael Warren <dzhugashvili9 at hotmail.com>
> Subject: kerberos password test function source code
> To: <krbdev at mit.edu>
> Message-ID: <BAY116-W470495822D4665F60F4339F27D0 at phx.gbl>
> Content-Type: text/plain; charset="iso-8859-1"
>
> Hey,
>
> I was wondering if anybody out there had a simple, straightforward  
> kerberos test function available. I already checked out the Brezak  
> Internet draft (draft-brezak-win2k-krb-rc4-hmac-03.txt), but it's a  
> little over my head as far as implementing it in code. I am pretty  
> new to programming, and I am attempting to build an application in C+ 
> + that will test passwords for strength. I was looking for something  
> along the lines of a bool function that is supplied a plaintext  
> password candidate in a word[] array and the Kerberos 5 pre  
> Authentication hash (like in Cain, the authenticator?), and return a  
> bool TRUE or FALSE, depending on whether or not the password checks.  
> Here is an example:
>
> bool IsPasswordTrue(char password[], authenticator)
> {
> if ((encrypt(password))==authenticator)
>      {
>           return TRUE;
>      }
> else
>      {
>          return FALSE;
>      }
> }
>
> if anybody could help, that would be great! This is the optimal  
> code, but if you have anything at all that might be helpful, I would  
> appreciate it. Thanks!

------------------------------------------------------
The opinions expressed in this message are mine,
not those of Caltech, JPL, NASA, or the US Government.
Henry.B.Hotz at jpl.nasa.gov, or hbhotz at oxy.edu




From tlyu at MIT.EDU  Mon Aug 11 11:48:57 2008
From: tlyu at MIT.EDU (Tom Yu)
Date: Mon, 11 Aug 2008 11:48:57 -0400
Subject: code quality improvement proposal
Message-ID: <ldvzlnjlfh2.fsf@cathode-dark-space.mit.edu>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Historically, various people have committed changes to the MIT
Kerberos source tree implementing bug fixes that were "quick patches"
which decreased the overall maintainability of the code.  This
practice is one of many that has made the code less maintainable over
time.  I would like to reverse this trend.

In an effort to improve the overall quality of the MIT Kerberos source
code, I propose the following policy:

* Every commit to the trunk must improve the overall quality of the
  code.

* The initial criteria consist of the subjective judgment of krbcore.

* Any krbcore member may revert changes for quality reasons.

  - I expect that krbcore members will not do so capriciously.

  - The committer and the reverter should come to an agreement about
    how the desired change should occur.  Additional people should be
    consulted if they cannot reach an agreement.

* We will formalize the criteria over time.

* Changes to release branches continue to be under Release Engineer
  control.

I think that improving code quality is a sufficiently important goal
that we should proceed with the proposal.

Unless there are strong objections, this policy becomes effective
immediately.

- -- 
Tom Yu
Development Manager
MIT Kerberos Consortium
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (SunOS)

iEYEARECAAYFAkigX2wACgkQSO8fWy4vZo4xEgCgoNDvgNO9gy5fd+FgYDR6iqIb
7mgAn3r6tbzsxagBacpN8DkXxvNPpbzo
=o/EF
-----END PGP SIGNATURE-----


From Brad.Gertner at asg.com  Mon Aug 11 17:10:55 2008
From: Brad.Gertner at asg.com (Brad Gertner)
Date: Mon, 11 Aug 2008 15:10:55 -0600
Subject: The GSS API Sample Client
Message-ID: <C98550F6F45EFC4B830A1B468151A21F01B3AA7C@usden3mail.asg.com>

I am interested in the revised versions of the GSS API Sample Client
code that work with Microsoft Windows, as mentioned in your release
notes.

 

GSSAPI Sample Client (gss.exe):

The GSS API Sample Client provided in this distribution is compatible
with the gss-server application built on Unix/Linux systems.  This
client is not compatible with the Platform
SDK/Samples/Security/SSPI/GSS/ samples which Microsoft has been shipping
as of January 2004.  Revised versions of these samples are available
upon request to krbdev at mit.edu.  Microsoft is committed to distribute
revised samples which are compatible with the MIT distributed tools in a
future SDK and via MSDN. 

 

Thank you,

Brad Gertner.

 

Brad Gertner, Ph.D.
Product Architect
brad.gertner at asg.com <mailto:brad.gertner at asg.com> 

558 Chesterfield Cir
San Marcos, California 92069 USA
Tel: 303.482.4177
Toll-Free: 1.800.944.4774
Cell: 760.613.1812
Fax: 303.482.4377

ASG | www.asg.com <http://www.asg.com> 
Beyond BSM(tm)

P  Please consider the environment before printing this email.

 


From hotz at jpl.nasa.gov  Tue Aug 12 17:59:34 2008
From: hotz at jpl.nasa.gov (Henry B. Hotz)
Date: Tue, 12 Aug 2008 14:59:34 -0700
Subject: The GSS API Sample Client
In-Reply-To: <mailman.439.1218557152.31028.krbdev@mit.edu>
References: <mailman.439.1218557152.31028.krbdev@mit.edu>
Message-ID: <0EF26CA3-A1EC-4FD9-AD4D-95583F231A87@jpl.nasa.gov>

http://web.mit.edu/jaltman/Public/KFW/ms_samples_security_sspi_gss.zip

On Aug 12, 2008, at 9:05 AM, krbdev-request at mit.edu wrote:

> Message: 1
> Date: Mon, 11 Aug 2008 15:10:55 -0600
> From: "Brad Gertner" <Brad.Gertner at asg.com>
> Subject: The GSS API Sample Client
> To: <krbdev at mit.edu>
> Message-ID:
>        <C98550F6F45EFC4B830A1B468151A21F01B3AA7C at usden3mail.asg.com>
> Content-Type: text/plain;       charset="us-ascii"
>
> I am interested in the revised versions of the GSS API Sample Client
> code that work with Microsoft Windows, as mentioned in your release
> notes.
>
>
>
> GSSAPI Sample Client (gss.exe):
>
> The GSS API Sample Client provided in this distribution is compatible
> with the gss-server application built on Unix/Linux systems.  This
> client is not compatible with the Platform
> SDK/Samples/Security/SSPI/GSS/ samples which Microsoft has been  
> shipping
> as of January 2004.  Revised versions of these samples are available
> upon request to krbdev at mit.edu.  Microsoft is committed to distribute
> revised samples which are compatible with the MIT distributed tools  
> in a
> future SDK and via MSDN.
>
>
>
> Thank you,
>
> Brad Gertner.
>
>
>
> Brad Gertner, Ph.D.
> Product Architect
> brad.gertner at asg.com <mailto:brad.gertner at asg.com>
>
> 558 Chesterfield Cir
> San Marcos, California 92069 USA
> Tel: 303.482.4177
> Toll-Free: 1.800.944.4774
> Cell: 760.613.1812
> Fax: 303.482.4377
>
> ASG | www.asg.com <http://www.asg.com>
> Beyond BSM(tm)
>
> P  Please consider the environment before printing this email.

------------------------------------------------------
The opinions expressed in this message are mine,
not those of Caltech, JPL, NASA, or the US Government.
Henry.B.Hotz at jpl.nasa.gov, or hbhotz at oxy.edu




From mike.patnode at centrify.com  Thu Aug 14 13:33:00 2008
From: mike.patnode at centrify.com (Mike Patnode)
Date: Thu, 14 Aug 2008 10:33:00 -0700
Subject: use_conf_ktypes
Message-ID: <BB7E16A14DE689469A181EC770AFBF4D01D53C5C@exch-one.centrify.com>

Can someone explain the thinking behind use_conf_ktypes?  I'm trying to
eliminate the repeated parsing of krb5.conf on every ticket request by
configuring my context appropriately, and found the code doesn't want me
to do that.   Here from init_ctx.c: krb5_get_tgs_ktypes()

 

    if (context->use_conf_ktypes)

        /* This one is set *only* by reading the config file; it's not

           set by the application.  */

        return(get_profile_etype_list(context, ktypes,
"default_tgs_enctypes",

                                      0, NULL));

    else

        return(get_profile_etype_list(context, ktypes,
"default_tgs_enctypes",

                                      context->tgs_ktype_count,

                                      context->tgs_ktypes));

 

Then in krb5_fwd_tgt_creds():

 

    /* fetch tgt directly from cache */

    context->use_conf_ktypes = 1;

    retval = krb5_cc_retrieve_cred (context, cc,
KRB5_TC_SUPPORTED_KTYPES,

                    &creds, &tgt);

    context->use_conf_ktypes = old_use_conf_ktypes;

 

 

Why in this case is it necessary to ignore the application's supported
encryption type list?


From tsitkova at MIT.EDU  Mon Aug 18 11:48:59 2008
From: tsitkova at MIT.EDU (tsitkova)
Date: Mon, 18 Aug 2008 11:48:59 -0400
Subject: gss_export/import _sec_context  on Client 
Message-ID: <C3C9FF81-A856-4B5A-B21A-9997D7A48A5F@mit.edu>

Hello!
I wonder if anyone is using gss_export_sec_context and/or  
gss_export_sec_context on the client side.

Thanks!


Zhanna Tsitkova
tsitkova at mit.edu
Kerberos  Consortium




From josephharfouch at iinet.net.au  Tue Aug 19 05:46:22 2008
From: josephharfouch at iinet.net.au (josephharfouch@iinet.net.au)
Date: Tue, 19 Aug 2008 17:46:22 +0800
Subject: Matching the iteration count for aes encryption when using a keytab
Message-ID: <10848.1219139182@iinet.net.au>

Hello, 

I notice that the s2kaparams entry in the ETYPE_INFO2 as described in RFC4120 
is a mechanism where the KDC can inform the client of a different iteration 
count rather the default 4096 for AES encryption, so that the client can 
match the generated key, similar to when a different salt is used.

How would this work if the key is already precalculated and stored in a keytab
, i.e if the kinit -k command used to obtain a ticket? I presume that a 
prior knowledge of the iteration count used to calculate server keys by the 
KDC would be the only way to match the key when creating a keytab entry, 
and the s2kparams value would be ignored when a keytab entry is used to decrypt 
the ticket, but I don't see any option in the ktadd command to adjust the 
iteration count when generating a key in the keytab. The syntax below 
allows for the specification of a different salt, but not a different 
iteration count. 

Even if I'm right and something is really missing, I don't see this as a big 
deal for the time being, but I presume in the future an iteration count of 4096 
would not be sufficient, and KDCs would be sending different iteration 
counts for principals including server principals, so I'm just letting you know 
in case it is really an issue. 


ktadd [-k[eytab] keytab] [-q] [-e
     key:salt_list] [principal | -glob princ_exp]
     [...]


Best Regards


Joseph Harfouch   

   




From ashutosh.datar at hp.com  Tue Aug 19 07:32:11 2008
From: ashutosh.datar at hp.com (Datar, Ashutosh Anil)
Date: Tue, 19 Aug 2008 11:32:11 +0000
Subject: Regarding Issues with Memory Credential Cache
Message-ID: <BF98D2A6A737054A8611EB5263F35D0D553DA59865@GVW1154EXB.americas.hpqcorp.net>

Hi,

I was testing Apache Web Server (which uses mod_auth_kerb) with Kerberos Client 1.6.2 and found some issue with the Memory Cache handling.

According to my understanding, memory cache is arranged as a linked list, each node of which represents a cache and provides a pointer to another linked list (list of credentials), each node representing a credential from that particular cache.
(In source code, these nodes are named as Krb5_mcc_list_node and Krb5_mcc_cursor respectively)

Now, as an already filed ticket (#5895: http://krbdev.mit.edu/rt/Ticket/Display.html?user=guest&pass=guest&id=5895) indicates, we need to place locks in krb5_mcc_initialize () and krb5_mcc_destroy () so that krb5_mcc_free doesn't get called unprotected, causing an application to receive SIGSEGV.

But, as mentioned in the ticket itself, this alone will not ensure the safe access, as a thread can still free a Krb5_mcc_list_node when another is still accessing it. And thus it requires some kind of reference count mechanism which will ensure freeing up Krb5_mcc_list_node happens only when refcount is zero (No one else accessing it). This is already implemented in File Cache handling.

While testing, I could still observe application receiving SIGSEGV at few other places and after analyzing it, following are my observations:


 1.  Implemented reference count mechanism only ensures the safe access to Krb5_mcc_list_nodes, but when two threads are using same cache (e.g. two threads of same application) then they are actually simultaneously accessing Krb5_mcc_cursors, traversal of which is not completely protected by locks.
 2.  Though, krb5_mcc_remove_cred ()  is not supported, a thread can still call  krb5_mcc_initialize ()  while another thread is still using those credentials in krb5_mcc_next_cred (), which doesn't operate under any kind of lock.
 3.  krb5_mcc_get_principal () also tries to access a Krb5_mcc_list_node data without acquiring any lock on it.

As for point number 2 above, following are possible approaches that I see as solution:

 1.  When a thread enters krb5_mcc_start_seq_get () to start the traversal of Krb5_mcc_cursor's list, it acquires a lock, which is relinquished in krb5_mcc_end_seq_get () so as to ensure that krb5_mcc_intialize () doesn't free the list when it's being traversed. But, this approach requires locking/unlocking across different functions and I am not very sure if it's the right way or not.
 2.  To make sure that krb5_mcc_initialize () is called only once for a particular Krb5_mcc_list_node. But there can be situations where an application explicitly wants to refresh(flush) the Cache and here we are restricting it to do so.

Can someone let me know which one is the better option, or if something else can be implemented which will remove both of the mentioned problems?

Also, about the 3rd point in the observations' list, it's required that there is a lock acquired in krb5_mcc_get_principal () before accessing a node so as to avoid accessing an already freed location.

Thanks and Regards,
Ashutosh



From se10 at cornell.edu  Tue Aug 19 17:17:10 2008
From: se10 at cornell.edu (Steve Edgar)
Date: Tue, 19 Aug 2008 17:17:10 -0400
Subject: Building KfW 3.2.2
Message-ID: <DC84EEFF-FD85-414E-8092-15CC4FF18D51@cornell.edu>

I am trying to build KfW 3.2.2, and am in search of additional info  
and/or settings.  I downloaded KfW-3-2-2-src.zip and unzipped it.  I  
followed the instructions in ...

file:///C:/kfw-3-2-2-final/src/doc/kerberos/relnotes.html#build

... and in ...

c:\kfw-3-2-2-final/src/athena/auth/sc/windows/build/bkw-automation.html

I have ...

Windows XP Pro version 5.1 Service Pack 3
Visual Studio .NET 2003
A recent release of the Platform SDK
ActivePerl 5.8.8
doxygen 1.5.1-p1
Cygwin
WiX Toolset Visual Studio Package
Nullsoft Install System
HTML Help Workshop
CVSNT
CollabNet Subversion 1.5.0

All Visual Studio and Platform SDK environment variables are set for a  
command line build, and all the required utilities are on the (very  
long) path.

Then I ...

cd c:\kfw-3-2-2-final/src/athena/auth/sc/windows/build
bkw.pl /v /config bkwconfig.xml

... and get ...

"Could not open pismere/athena/include/kerberos.ver"

... and in bkw-automation.html it says ...

"You skipped the repository step and try to build in an empty  
directory."

BKWconfig.xml as delivered is configured to skip the repository step.   
Change BKWconfig.xml to checkout sources.  Run ...

bkw.pl /v /config bkwconfig.xml

... and get ...

"Fatal -- you won't get far accessing the repository withouth  
specifying a username."

Use my e-mail address as my username in BKWconfig.xml.  Run ...

bkw.pl /v /config bkwconfig.xml

... and get ...

"cvs [checkout aborted]: the :kserver: access method is not available  
on this system."

... which is referring to the default CVSROOT entry in BKWconfig.xml.

Do I need different settings in BKWconfig.xml?  Or perhaps a different  
version of CVS or Subversion?

It is a long story, but I only need to build gssapi32.dll, to insert  
one line of code which will pop Cornell's password dialog box, which  
lives in an old Cornell DLL.  Any chance there is a short cut I could  
use to just build the gssapi32.dll source against the KfW 3.2.2 SDK?

Also, just curious... why distribute the KfW 3.2.2 source files if the  
build process requires they be downloaded from the source code control  
server?

-- Steve.


From elric at imrryr.org  Tue Aug 19 20:38:02 2008
From: elric at imrryr.org (Roland Dowdeswell)
Date: Tue, 19 Aug 2008 20:38:02 -0400
Subject: Matching the iteration count for aes encryption when using a
	keytab 
In-Reply-To: Your message of "Tue, 19 Aug 2008 17:46:22 +0800."
	<10848.1219139182@iinet.net.au> 
Message-ID: <20080820003802.02B4A372CC@arioch.imrryr.org>

On 1219139182 seconds since the Beginning of the UNIX epoch
"josephharfouch at iinet.net.au" wrote:
>

>I notice that the s2kaparams entry in the ETYPE_INFO2 as described in RFC4120 
>is a mechanism where the KDC can inform the client of a different iteration 
>count rather the default 4096 for AES encryption, so that the client can 
>match the generated key, similar to when a different salt is used.
>
>How would this work if the key is already precalculated and stored in a keytab
>, i.e if the kinit -k command used to obtain a ticket? I presume that a 

IIRC, the keytab stores the keys rather than passphrases used to
generate the keys.  The salt/iteration count is used to convert a
passphrase into a key.  So, neither should be necessary for regular
keytab files.

--
    Roland Dowdeswell                      http://www.Imrryr.ORG/~elric/

From epeisach at MIT.EDU  Tue Aug 19 21:49:51 2008
From: epeisach at MIT.EDU (Ezra Peisach)
Date: Tue, 19 Aug 2008 21:49:51 -0400
Subject: Regarding Issues with Memory Credential Cache
In-Reply-To: <BF98D2A6A737054A8611EB5263F35D0D553DA59865@GVW1154EXB.americas.hpqcorp.net>
References: <BF98D2A6A737054A8611EB5263F35D0D553DA59865@GVW1154EXB.americas.hpqcorp.net>
Message-ID: <48AB783F.4050602@mit.edu>

Datar, Ashutosh Anil wrote:
> Hi,
>
> I was testing Apache Web Server (which uses mod_auth_kerb) with Kerberos Client 1.6.2 and found some issue with the Memory Cache handling.
>
> According to my understanding, memory cache is arranged as a linked list, each node of which represents a cache and provides a pointer to another linked list (list of credentials), each node representing a credential from that particular cache.
> (In source code, these nodes are named as Krb5_mcc_list_node and Krb5_mcc_cursor respectively)
>
> Now, as an already filed ticket (#5895: http://krbdev.mit.edu/rt/Ticket/Display.html?user=guest&pass=guest&id=5895) indicates, we need to place locks in krb5_mcc_initialize () and krb5_mcc_destroy () so that krb5_mcc_free doesn't get called unprotected, causing an application to receive SIGSEGV.
>
>   
I will look at this.  I have been playing with the ccache code recently...

> But, as mentioned in the ticket itself, this alone will not ensure the safe access, as a thread can still free a Krb5_mcc_list_node when another is still accessing it. And thus it requires some kind of reference count mechanism which will ensure freeing up Krb5_mcc_list_node happens only when refcount is zero (No one else accessing it). This is already implemented in File Cache handling.
>
>   
Should be easy to implement.
> While testing, I could still observe application receiving SIGSEGV at few other places and after analyzing it, following are my observations:
>
>
>  1.  Implemented reference count mechanism only ensures the safe access to Krb5_mcc_list_nodes, but when two threads are using same cache (e.g. two threads of same application) then they are actually simultaneously accessing Krb5_mcc_cursors, traversal of which is not completely protected by locks.
>  2.  Though, krb5_mcc_remove_cred ()  is not supported, a thread can still call  krb5_mcc_initialize ()  while another thread is still using those credentials in krb5_mcc_next_cred (), which doesn't operate under any kind of lock.
>  3.  krb5_mcc_get_principal () also tries to access a Krb5_mcc_list_node data without acquiring any lock on it.
>
>   
I think point (2) is an interesting issue... First of all - I think 
initializing a cache from underneath a different thread is not really 
socialable - but consider the file cache... In this case, the 
fcc_initialize function will unlink the old cache and open a new one.  
Now - a previously open cache in say another thread - will be screwed - 
unless the the OPENCLOSE flag is not set - in which case the O/S will 
still have access to the open file - but this is not supported.  Even 
worse, if the first thread initializes the cache and writes a bunch of 
data to it before the other thread iterates to the next entry - the 
position in the file may not longer be valid.

At best - you are facing an undefined state.

So - to be consistent, I would say that if you initialize a cache while 
another thread is iterating through it - the other thread should be 
screwed - but
should fail in a reliable way - without crashing the application.

An examination of the Heimdal code shows that initialize will probably 
screw you over as.  I think you might still have access to the old 
entries - as they are not cleared.  They do implement a remove function.

> As for point number 2 above, following are possible approaches that I see as solution:
>
>  1.  When a thread enters krb5_mcc_start_seq_get () to start the traversal of Krb5_mcc_cursor's list, it acquires a lock, which is relinquished in krb5_mcc_end_seq_get () so as to ensure that krb5_mcc_intialize () doesn't free the list when it's being traversed. But, this approach requires locking/unlocking across different functions and I am not very sure if it's the right way or not.
>  2.  To make sure that krb5_mcc_initialize () is called only once for a particular Krb5_mcc_list_node. But there can be situations where an application explicitly wants to refresh(flush) the Cache and here we are restricting it to do so.
>
> Can someone let me know which one is the better option, or if something else can be implemented which will remove both of the mentioned problems?
>
>   
My solution for you would be to implement the remove function. An 
alternative would be to copy the cache from one entry to another - 
skipping the entry you want to delete - and then tell all threads to 
start using the new cache - and then destroy the old one.

> Also, about the 3rd point in the observations' list, it's required that there is a lock acquired in krb5_mcc_get_principal () before accessing a node so as to avoid accessing an already freed location.
>
>   
I will take a look at this...
> Thanks and Regards,
> Ashutosh
>
>
>   

There is another screw case to consider for which the file cache does 
not deal either... If you destroy a cache in one thread while accessing 
in another thread - bad things could happen.  Heimdal handles the 
destroy case in an interesting way (for a memory cache) - it will flag a 
cache in use as dead - and removed from the global list. When the last 
thread holding it open closes the cache, the refcount drops to zero and 
is then deleted.
Therefore - two threads can use a shared cache - one thread can destroy 
it - and the other thread is ok...

Anyways - I will look into the locking problems you mentioned - and see 
about implementing the remove function - which I believe will solve your
problems....

Ezra


From raeburn at MIT.EDU  Wed Aug 20 03:15:12 2008
From: raeburn at MIT.EDU (Ken Raeburn)
Date: Wed, 20 Aug 2008 03:15:12 -0400
Subject: Regarding Issues with Memory Credential Cache
In-Reply-To: <48AB783F.4050602@mit.edu>
References: <BF98D2A6A737054A8611EB5263F35D0D553DA59865@GVW1154EXB.americas.hpqcorp.net>
	<48AB783F.4050602@mit.edu>
Message-ID: <246CD8EF-65FB-4FEF-9D53-80EBADE38E67@mit.edu>

On Aug 19, 2008, at 21:49, Ezra Peisach wrote:
> I will look at this.  I have been playing with the ccache code  
> recently...

Thanks, Ezra.  (And thanks for the memory leak fixes you've been doing.)

>> But, as mentioned in the ticket itself, this alone will not ensure  
>> the safe access, as a thread can still free a Krb5_mcc_list_node  
>> when another is still accessing it. And thus it requires some kind  
>> of reference count mechanism which will ensure freeing up  
>> Krb5_mcc_list_node happens only when refcount is zero (No one else  
>> accessing it). This is already implemented in File Cache handling.
> Should be easy to implement.

I think we may have a general class of "shared linked list not  
adequately protected when one thread deletes an element another is  
using or iterating past" type issues in a few areas like re- 
initialization, and combining iterators with simultaneous  
modifications.  I was starting to look into the memory ccache issue a  
while back, and thinking about trying to implement a generic "ordered  
collection of thing, with iterator support, reference counting and  
locking" on top of which various collections (some needing to support  
exported iterators that can maybe -- our specifications aren't very  
specific -- be used interleaved with other operations like additions  
and deletions, some not; some needing element ordering to be  
preserved, some not; most needing some types of lookup functions)  
could be built with a few macros or thin wrapper functions.  But then  
something came up, and something else came up, etc., and it's floated  
down a ways in my queue for now.

> So - to be consistent, I would say that if you initialize a cache  
> while
> another thread is iterating through it - the other thread should be
> screwed - but
> should fail in a reliable way - without crashing the application.

I think that sounds right.

(And -- interesting point about the file caches.  We remember the  
position we were at but don't check that it's the same file.  Perhaps  
we should record device/inode/generation values and compare on  
reopening.)

Ken

From tlyu at MIT.EDU  Wed Aug 20 16:03:25 2008
From: tlyu at MIT.EDU (Tom Yu)
Date: Wed, 20 Aug 2008 16:03:25 -0400
Subject: MD5DES_BETA5_COMPAT
Message-ID: <ldvvdxvv4he.fsf@cathode-dark-space.mit.edu>

There is some backward compatibility code in the MD5DES and MD4DES
keyed hash implementation in our crypto library.  It appears to allow
validation of keyed MD5 or MD4 checksums where the sender did not
include a confounder.

The name macros controlling this compatibility code imply that they
were for the "Beta 5" release, which was more than 10 years ago.  Does
anyone still require this compatibility hack?

-- 
Tom Yu
Development Manager
MIT Kerberos Consortium

From raeburn at MIT.EDU  Wed Aug 20 16:20:52 2008
From: raeburn at MIT.EDU (Ken Raeburn)
Date: Wed, 20 Aug 2008 16:20:52 -0400
Subject: MD5DES_BETA5_COMPAT
In-Reply-To: <ldvvdxvv4he.fsf@cathode-dark-space.mit.edu>
References: <ldvvdxvv4he.fsf@cathode-dark-space.mit.edu>
Message-ID: <5987DCFE-2F9F-4912-80B9-2B5B91484C1E@mit.edu>

On Aug 20, 2008, at 16:03, Tom Yu wrote:
> There is some backward compatibility code in the MD5DES and MD4DES
> keyed hash implementation in our crypto library.  It appears to allow
> validation of keyed MD5 or MD4 checksums where the sender did not
> include a confounder.
>
> The name macros controlling this compatibility code imply that they
> were for the "Beta 5" release, which was more than 10 years ago.  Does
> anyone still require this compatibility hack?

Perhaps another good question is, does anyone still care about any  
sort of backwards compatibility with pre-1.0 releases?  I believe at  
least one vendor is, or was within the last year or so, still  
supporting 1.0.x clients for some customers.  But we may still be able  
to draw a line at 1.0, if not later....

Ken

From epeisach at MIT.EDU  Fri Aug 22 12:50:16 2008
From: epeisach at MIT.EDU (Ezra Peisach)
Date: Fri, 22 Aug 2008 12:50:16 -0400
Subject: Regarding Issues with Memory Credential Cache
In-Reply-To: <BF98D2A6A737054A8611EB5263F35D0D553DA59865@GVW1154EXB.americas.hpqcorp.net>
References: <BF98D2A6A737054A8611EB5263F35D0D553DA59865@GVW1154EXB.americas.hpqcorp.net>
Message-ID: <48AEEE48.8010209@mit.edu>

Datar, Ashutosh Anil wrote:
> Hi,
>
> I was testing Apache Web Server (which uses mod_auth_kerb) with 
> Kerberos Client 1.6.2 and found some issue with the Memory Cache handling.

Okay - I have examined the situation a little more. The problem is 
readlly with mod_auth_kerb.  In version 5.3 (released at the end of 
2006) - krb5_cc_resolve is used to create a temporary
memory cache in two places.

The second argument for the cache is "MEMORY:".  This indicates that we 
want a memory cache with name "".  The cache is initialized, used and 
destroyed - so I believe it was never intended to last.  So - another 
thread might be iterating through the same cache and another thread then 
nukes the contents of the cache with krb5_cc_initialize.

The fix is pretty easy - in mod_auth_kerb, there are two places 
krb5_cc_resolve is used with "MEMORY:" as the second argument.  Change 
the code to use krb5_cc_new_unique and that should solve your 
problem.... (the type should be "MEMORY" without the :)

I would make the change the mod_auth_kerb and if it works - send the fix 
to the author.

I will meanwhile devise a way to bullet proof the memory cache code - to 
at least ensure that initializing a cache while someone else is walking 
it - will not do anything illegal - but probably result in an emptied 
cache - which is not what mod_auth_kerb would be expecting...

Ezra


From rsilk at MIT.EDU  Mon Aug 25 10:37:58 2008
From: rsilk at MIT.EDU (RJ Silk)
Date: Mon, 25 Aug 2008 10:37:58 -0400
Subject: Building KfW 3.2.2
In-Reply-To: <DC84EEFF-FD85-414E-8092-15CC4FF18D51@cornell.edu>
References: <DC84EEFF-FD85-414E-8092-15CC4FF18D51@cornell.edu>
Message-ID: <48B2C3C6.2020601@mit.edu>

Hello,

I apologize for the confusion. The build information found in 
/src/windows/build is designed to build the entire Kerberos tree 
(including distribution packages and help files) and requires read 
permissions in the CVS repository. I don't think it was designed to be 
used with the source distribution zip.

For (re)building the Krb5 sources (including gssapi32.dll) from the 
source zip please consult the build instructions in 
/src/athena/auth/krb5/src/windows/README. Since you've already installed 
the cygwin tools, you should be able to follow the steps under the 
"All-Windows Build Method" heading. (Note "xxx/src" in the README refers 
to the path "/src/athena/auth/krb5/src" from the freshly unzipped archive).

Please let me know if you have any further issues with the build, and 
I'd be happy to take a look.

Thank you,
Robert

Steve Edgar wrote:
> I am trying to build KfW 3.2.2, and am in search of additional info  
> and/or settings.  I downloaded KfW-3-2-2-src.zip and unzipped it.  I  
> followed the instructions in ...
>
> file:///C:/kfw-3-2-2-final/src/doc/kerberos/relnotes.html#build
>
> ... and in ...
>
> c:\kfw-3-2-2-final/src/athena/auth/sc/windows/build/bkw-automation.html
>
> I have ...
>
> Windows XP Pro version 5.1 Service Pack 3
> Visual Studio .NET 2003
> A recent release of the Platform SDK
> ActivePerl 5.8.8
> doxygen 1.5.1-p1
> Cygwin
> WiX Toolset Visual Studio Package
> Nullsoft Install System
> HTML Help Workshop
> CVSNT
> CollabNet Subversion 1.5.0
>
> All Visual Studio and Platform SDK environment variables are set for a  
> command line build, and all the required utilities are on the (very  
> long) path.
>
> Then I ...
>
> cd c:\kfw-3-2-2-final/src/athena/auth/sc/windows/build
> bkw.pl /v /config bkwconfig.xml
>
> ... and get ...
>
> "Could not open pismere/athena/include/kerberos.ver"
>
> ... and in bkw-automation.html it says ...
>
> "You skipped the repository step and try to build in an empty  
> directory."
>
> BKWconfig.xml as delivered is configured to skip the repository step.   
> Change BKWconfig.xml to checkout sources.  Run ...
>
> bkw.pl /v /config bkwconfig.xml
>
> ... and get ...
>
> "Fatal -- you won't get far accessing the repository withouth  
> specifying a username."
>
> Use my e-mail address as my username in BKWconfig.xml.  Run ...
>
> bkw.pl /v /config bkwconfig.xml
>
> ... and get ...
>
> "cvs [checkout aborted]: the :kserver: access method is not available  
> on this system."
>
> ... which is referring to the default CVSROOT entry in BKWconfig.xml.
>
> Do I need different settings in BKWconfig.xml?  Or perhaps a different  
> version of CVS or Subversion?
>
> It is a long story, but I only need to build gssapi32.dll, to insert  
> one line of code which will pop Cornell's password dialog box, which  
> lives in an old Cornell DLL.  Any chance there is a short cut I could  
> use to just build the gssapi32.dll source against the KfW 3.2.2 SDK?
>
> Also, just curious... why distribute the KfW 3.2.2 source files if the  
> build process requires they be downloaded from the source code control  
> server?
>
> -- Steve.
>
> _______________________________________________
> krbdev mailing list             krbdev at mit.edu
> https://mailman.mit.edu/mailman/listinfo/krbdev
>   

From se10 at cornell.edu  Tue Aug 26 09:31:22 2008
From: se10 at cornell.edu (Steve Edgar)
Date: Tue, 26 Aug 2008 09:31:22 -0400
Subject: Building KfW 3.2.2
In-Reply-To: <48B2C3C6.2020601@mit.edu>
References: <DC84EEFF-FD85-414E-8092-15CC4FF18D51@cornell.edu>
	<48B2C3C6.2020601@mit.edu>
Message-ID: <5D633ED8-9039-4423-BEA6-6F62A0D5B38D@cornell.edu>

Thanks Robert.  I had got something going by skipping the check out  
step, and piecing together parts of the source tree needed to make the  
perl scripts work, but using the method you describe below is way  
better :).

Since I was looking only to change gssapi32.dll, and otherwise use the  
stock KfW 3.2.2 distribution, version of dev tools turned out to key.   
After some experimentation, I ended up using Visual Studio 2003, with  
header files and libs from the Visual Studio 2005's Platform SDK.

-- Steve.

On Aug 25, 2008, at 10:37 AM, RJ Silk wrote:

> Hello,
>
> I apologize for the confusion. The build information found in /src/ 
> windows/build is designed to build the entire Kerberos tree  
> (including distribution packages and help files) and requires read  
> permissions in the CVS repository. I don't think it was designed to  
> be used with the source distribution zip.
>
> For (re)building the Krb5 sources (including gssapi32.dll) from the  
> source zip please consult the build instructions in /src/athena/auth/ 
> krb5/src/windows/README. Since you've already installed the cygwin  
> tools, you should be able to follow the steps under the "All-Windows  
> Build Method" heading. (Note "xxx/src" in the README refers to the  
> path "/src/athena/auth/krb5/src" from the freshly unzipped archive).
>
> Please let me know if you have any further issues with the build,  
> and I'd be happy to take a look.
>
> Thank you,
> Robert
>
> Steve Edgar wrote:
>> I am trying to build KfW 3.2.2, and am in search of additional  
>> info  and/or settings.  I downloaded KfW-3-2-2-src.zip and unzipped  
>> it.  I  followed the instructions in ...
>>
>> file:///C:/kfw-3-2-2-final/src/doc/kerberos/relnotes.html#build
>>
>> ... and in ...
>>
>> c:\kfw-3-2-2-final/src/athena/auth/sc/windows/build/bkw- 
>> automation.html
>>
>> I have ...
>>
>> Windows XP Pro version 5.1 Service Pack 3
>> Visual Studio .NET 2003
>> A recent release of the Platform SDK
>> ActivePerl 5.8.8
>> doxygen 1.5.1-p1
>> Cygwin
>> WiX Toolset Visual Studio Package
>> Nullsoft Install System
>> HTML Help Workshop
>> CVSNT
>> CollabNet Subversion 1.5.0
>>
>> All Visual Studio and Platform SDK environment variables are set  
>> for a  command line build, and all the required utilities are on  
>> the (very  long) path.
>>
>> Then I ...
>>
>> cd c:\kfw-3-2-2-final/src/athena/auth/sc/windows/build
>> bkw.pl /v /config bkwconfig.xml
>>
>> ... and get ...
>>
>> "Could not open pismere/athena/include/kerberos.ver"
>>
>> ... and in bkw-automation.html it says ...
>>
>> "You skipped the repository step and try to build in an empty   
>> directory."
>>
>> BKWconfig.xml as delivered is configured to skip the repository  
>> step.   Change BKWconfig.xml to checkout sources.  Run ...
>>
>> bkw.pl /v /config bkwconfig.xml
>>
>> ... and get ...
>>
>> "Fatal -- you won't get far accessing the repository withouth   
>> specifying a username."
>>
>> Use my e-mail address as my username in BKWconfig.xml.  Run ...
>>
>> bkw.pl /v /config bkwconfig.xml
>>
>> ... and get ...
>>
>> "cvs [checkout aborted]: the :kserver: access method is not  
>> available  on this system."
>>
>> ... which is referring to the default CVSROOT entry in BKWconfig.xml.
>>
>> Do I need different settings in BKWconfig.xml?  Or perhaps a  
>> different  version of CVS or Subversion?
>>
>> It is a long story, but I only need to build gssapi32.dll, to  
>> insert  one line of code which will pop Cornell's password dialog  
>> box, which  lives in an old Cornell DLL.  Any chance there is a  
>> short cut I could  use to just build the gssapi32.dll source  
>> against the KfW 3.2.2 SDK?
>>
>> Also, just curious... why distribute the KfW 3.2.2 source files if  
>> the  build process requires they be downloaded from the source code  
>> control  server?
>>
>> -- Steve.
>>
>> _______________________________________________
>> krbdev mailing list             krbdev at mit.edu
>> https://mailman.mit.edu/mailman/listinfo/krbdev
>>


From christophe.thibault at planisware.com  Wed Aug 27 12:38:09 2008
From: christophe.thibault at planisware.com (Christophe Thibault)
Date: Wed, 27 Aug 2008 18:38:09 +0200
Subject: Error in gss_acquire_creds: Not enough space
Message-ID: <48B582F1.30906@planisware.com>

Hello,

I'm using mod_auth_kerb on Apache 2 to authenticate against an AD server.

mod_auth_kerb has been built with MIT Kerberos 5 1.6.3, on an AIX box.



The problem is that I get the following error message in my Apache log, 
when I try to access from IE:

[Mon Aug 25 17:13:29 2008] [debug] ./src/mod_auth_kerb.c(1491): [client 172.19.118.206] kerb_authenticate_user entered with user (NULL) and auth_type Kerberos
[Mon Aug 25 17:13:29 2008] [debug] ./src/mod_auth_kerb.c(1491): [client 172.19.118.206] kerb_authenticate_user entered with user (NULL) and auth_type Kerberos
[Mon Aug 25 17:13:29 2008] [debug] ./src/mod_auth_kerb.c(1178): [client 172.19.118.206] Acquiring creds for HTTP at ukblx235.xxxx.net
[Mon Aug 25 17:13:29 2008] [error] [client 172.19.118.206] gss_acquire_cred() failed: An invalid name was supplied (Not enough space)


It seems that all test with command-line tools (kinit, klist) were 
successfull.

I have now no idea where to find, so any help/comment/test/... is welcome.

Thanks for your help,

chris


-- 
Christophe THIBAULT - Planisware
102 Rue Etienne Dolet
92247 Malakoff Cedex
France
http://www.planisware.com

-------------- next part --------------
A non-text attachment was scrubbed...
Name: christophe_thibault.vcf
Type: text/x-vcard
Size: 323 bytes
Desc: not available
Url : http://mailman.mit.edu/pipermail/krbdev/attachments/20080827/84bb9764/christophe_thibault.vcf

From ashutosh.datar at hp.com  Fri Aug 29 08:58:31 2008
From: ashutosh.datar at hp.com (Datar, Ashutosh Anil)
Date: Fri, 29 Aug 2008 12:58:31 +0000
Subject: Regarding Issues with Memory Credential Cache
In-Reply-To: <48AEEE48.8010209@mit.edu>
References: <BF98D2A6A737054A8611EB5263F35D0D553DA59865@GVW1154EXB.americas.hpqcorp.net>
	<48AEEE48.8010209@mit.edu>
Message-ID: <BF98D2A6A737054A8611EB5263F35D0D553DBB95CC@GVW1154EXB.americas.hpqcorp.net>

Hi,

Thanks very much for your analysis and feedback on the issue.
I will also try to test with the suggested changes in mod_auth_kerb code and see how it works.

About the other point of changing memory cache code of Kerberos client,
I have already tried protecting the memory cache list traversal which will prevent initialization of cache doing something illegal while someone else is still accessing it. It worked well with mod_auth_kerb under high load and I didn't see any SIGSEGVs after that.

Thanks again for the feedback.

Regards,
Ashutosh

-----Original Message-----
From: Ezra Peisach [mailto:epeisach at MIT.EDU]
Sent: Friday, August 22, 2008 10:20 PM
To: Datar, Ashutosh Anil
Cc: krbdev at mit.edu
Subject: Re: Regarding Issues with Memory Credential Cache

Datar, Ashutosh Anil wrote:
> Hi,
>
> I was testing Apache Web Server (which uses mod_auth_kerb) with
> Kerberos Client 1.6.2 and found some issue with the Memory Cache handling.

Okay - I have examined the situation a little more. The problem is
readlly with mod_auth_kerb.  In version 5.3 (released at the end of
2006) - krb5_cc_resolve is used to create a temporary
memory cache in two places.

The second argument for the cache is "MEMORY:".  This indicates that we
want a memory cache with name "".  The cache is initialized, used and
destroyed - so I believe it was never intended to last.  So - another
thread might be iterating through the same cache and another thread then
nukes the contents of the cache with krb5_cc_initialize.

The fix is pretty easy - in mod_auth_kerb, there are two places
krb5_cc_resolve is used with "MEMORY:" as the second argument.  Change
the code to use krb5_cc_new_unique and that should solve your
problem.... (the type should be "MEMORY" without the :)

I would make the change the mod_auth_kerb and if it works - send the fix
to the author.

I will meanwhile devise a way to bullet proof the memory cache code - to
at least ensure that initializing a cache while someone else is walking
it - will not do anything illegal - but probably result in an emptied
cache - which is not what mod_auth_kerb would be expecting...

Ezra