From tlyu at MIT.EDU  Sun Nov  1 10:12:29 2009
From: tlyu at MIT.EDU (Tom Yu)
Date: Sun, 01 Nov 2009 10:12:29 -0500
Subject: svn rev #23092: trunk/src/include/
In-Reply-To: <200910292300.n9TN0DFU032767@drugstore.mit.edu>
	(ghudson@MIT.EDU's message of "Thu, 29 Oct 2009 19:00:13 -0400")
References: <200910292300.n9TN0DFU032767@drugstore.mit.edu>
Message-ID: <ldvbpjm46ua.fsf@cathode-dark-space.mit.edu>

"ghudson at MIT.EDU" <ghudson at MIT.EDU> writes:

> http://src.mit.edu/fisheye/changelog/krb5/?cs=23092
> Commit By: ghudson
> Log Message:
> Add a couple of krb5_data convenience constructor functions, to
> facilitate properly initializing krb5_data objects.  Adjust formatting
> of the existing krb5_data convenience functions and remove the #if 0
> block.

The new make_data() inline function causes a compilation failure in
test_cxx_k5int.cpp, as apparently, in C++, pointers to void require
explicit casts when assigning to/from other pointer types.  We could
add an unconditional explicit cast, or possibly do something
conditionalized on __cplusplus.

From ghudson at MIT.EDU  Sun Nov  1 10:54:09 2009
From: ghudson at MIT.EDU (Greg Hudson)
Date: Sun, 01 Nov 2009 10:54:09 -0500
Subject: svn rev #23092: trunk/src/include/
In-Reply-To: <ldvbpjm46ua.fsf@cathode-dark-space.mit.edu>
References: <200910292300.n9TN0DFU032767@drugstore.mit.edu>
	<ldvbpjm46ua.fsf@cathode-dark-space.mit.edu>
Message-ID: <1257090849.5933.353.camel@ray>

On Sun, 2009-11-01 at 10:12 -0500, Tom Yu wrote:
> The new make_data() inline function causes a compilation failure in
> test_cxx_k5int.cpp

I'll fix.  (I realized that as I was committing, but didn't fix it
immediately as I wasn't sure it would cause a real problem.)



From ghudson at MIT.EDU  Sun Nov  1 17:55:22 2009
From: ghudson at MIT.EDU (ghudson@MIT.EDU)
Date: Sun, 1 Nov 2009 17:55:22 -0500 (EST)
Subject: const, the errors framework, and -Wcast-qual
Message-ID: <200911012255.nA1MtMkb009212@outgoing.mit.edu>

My C experience leads me to believe that const pointers should be used
for (1) pointers to non-heap-allocated memory (C string literals,
stack memory, etc.) which you don't want changed, or (2) aliases to
heap-allocated memory owned by some other, non-const pointer, which
you don't want changed through the alias.  In particular, it's my
understanding that const pointers should *not* be used for pointers
which will be used to free memory; destroying is a form of
modification, so if a pointer owns a piece of heap-allocated memory,
it has to be non-const even if that memory is intended to be immutable
until freed.

The errors framework doesn't agree with this principal.  struct
errinfo contained a const pointer to memory it owns, although I just
changed that.  krb5int_get_error and krb5_get_error_message return
const pointers even though those pointers are used to free memory.
The latter function is part of our API, although I don't know if it
would be a problem to change it to return char *, since that shouldn't
break any calling code.

I don't want to go on a crusade if I'm out of step with the community
on this.  I can find stuff like
http://bytes.com/topic/c/answers/217935-passing-const-void-free (which
is more of an argument than a refernce) and
https://barnowl.mit.edu:444/wiki/const (which can't possibly be
authoritative since it was written by someone yonuger than I am), but
no Voice of Authority.  So, here is a change to tell me that I am
educated stupid about this.

On a related and equally nitpicky note, I would like to remove
-Wcast-qual from our gcc warning set.  Because we make heavy use of
krb5_data in our code base, we have a lot of cases where we
deliberately de-constify a pointer in order to fit into a krb5_data
value for use by some function which won't modify the memory (like
input to krb5_c_encrypt).  I don't think it does us a big service to
identify places where people are deliberately circumventing const for
a reason such as this, when we usually can't fix it.

From raeburn at MIT.EDU  Sun Nov  1 21:44:38 2009
From: raeburn at MIT.EDU (Ken Raeburn)
Date: Sun, 1 Nov 2009 21:44:38 -0500
Subject: const, the errors framework, and -Wcast-qual
In-Reply-To: <200911012255.nA1MtMkb009212@outgoing.mit.edu>
References: <200911012255.nA1MtMkb009212@outgoing.mit.edu>
Message-ID: <3304C9E3-826F-46E3-B383-CDCC21379D86@mit.edu>

On Nov 1, 2009, at 17:55, ghudson at MIT.EDU wrote:
> The errors framework doesn't agree with this principal.  struct
> errinfo contained a const pointer to memory it owns, although I just
> changed that.  krb5int_get_error and krb5_get_error_message return
> const pointers even though those pointers are used to free memory.

The intent was that "application" code shouldn't be allowed to change  
the string, but the library code should be allowed to free it.  It's  
not easy to express that with both parts of the code in C unless you  
cast away const or you keep around a non-const version of the pointer.

We did wind up changing the design once or twice in the process.  This  
might've been something that worked better in the earlier design.

I'd have no objection to changing it, since we're now always returning  
writable copies of the error string, and usually independent copies.   
(We were considering letting get_error work multiple times, which can  
get complicated if allocation fails so some of the copies have to  
share the scratch buffer; in that case, you don't want the application  
to have been written to modify the returned string.  But we never made  
that part of the official interface.)

> On a related and equally nitpicky note, I would like to remove
> -Wcast-qual from our gcc warning set.  Because we make heavy use of
> krb5_data in our code base, we have a lot of cases where we
> deliberately de-constify a pointer in order to fit into a krb5_data
> value for use by some function which won't modify the memory (like
> input to krb5_c_encrypt).  I don't think it does us a big service to
> identify places where people are deliberately circumventing const for
> a reason such as this, when we usually can't fix it.

It's a shame we can't define a krb5_const_data with automatic pointer  
conversions and guaranteed compatibility...

Ken

From ghudson at MIT.EDU  Mon Nov  2 15:29:00 2009
From: ghudson at MIT.EDU (ghudson@MIT.EDU)
Date: Mon, 2 Nov 2009 15:29:00 -0500 (EST)
Subject: Application unbundling, part 2
Message-ID: <200911022029.nA2KT0U6009035@outgoing.mit.edu>

Back in July, I did most of the groundwork of unbundling the
applications into a separate repository.  There is still a little work
left to do to make the separation clean and ensure that the build
system is portable, but it's basically there.

The other half of the job is removing the applications from the krb5
tree in preparation for the 1.8 release.  I delayed this step
intentionally for easier preparation of 1.7.x patch releases, but
we're close enough to the 1.8 branch date that I will probably do it
soon.  So, expect to see in the not too distant future:

  * Removal of appl/bsd, appl/gssftp, appl/libpty, appl/telnet.
  * Removal of the dejagnu tests for applications.
  * Editing of the install and admin docs to remove references to the
    applications.

There will be a lot of opportunity for build system simplification
after this work is done.  In particular, this will get us down to a
single configure script, which means there theoretically won't be any
need for a separate aclocal.m4.  I don't guarantee that I will put in
the time to simplify things down the bare minimum, but I'll do some.

From hartmans at MIT.EDU  Mon Nov  2 18:50:49 2009
From: hartmans at MIT.EDU (Sam Hartman)
Date: Mon, 02 Nov 2009 18:50:49 -0500
Subject: GSS-API and libkrb5 behavior for Anonymous tickets
Message-ID: <tslpr80mqp2.fsf@mit.edu>



I'm starting the writeup for http://k5wiki.kerberos.org/wiki/Projects/Anonymous_pkinit .

I have a couple of questions about API behavior.

Note that as I'm proposing to implement this project, getting
anonymous tickets will not always work. There are two main causes of
failure.  First, your client may not be configured to verify the
certificate that the KDC presents.  Secondly, the KDC may not have
anonymous tickets enabled.

I have two questions about API behavior.

The first is what should the GSS-API behavior of the anonymous context
establishment option be.  

* If I set the anonymous option and pass in the default credential handle, what happens?  Options include:

1) If I have anonymous credentials in my default cache, I use them and
get the anonymous bit set in the established context.  Otherwise, I
don't get anonymous set in my context and I use the existing
credentials.  We call this the pathetic option.
[I recommend against this option.]

2) If my default credentials are anonymous they are used and the
anonymous bit is set in the context.  Otherwise, if I'm able to obtain
anonymous credentials, I do so into a memory ccache.  If I fail to
obtain anonymous credentials, then I use my existing default
credentials and don't set the anonymous bit in the context.  This
option is probably maximally conforming to the intent of the GSS-API
spec.

3) Option 2 as above, except that if I fail to obtain anonymous
credentials, I return an error.  This allows us to debug being unable
to obtain anonymous credentials, but probably breaks the strict
interpretation of how GSS-API should work.

* If I pass the anonymous name into gss_acquire_credentials, what
  happens?

1) If my default credentials are anonymous, then it works.  Otherwise, if I'm using KIM I may try to obtain anonymous credentials, but on Unix I fail.

2) If my default credentials are anonymous I use them.  Otherwise, I set up a new memory ccache and try to obtain anonymous credentials.  If I fail, I return an error.

3) Option 2 as above, except that if I fail to obtain anonymous
credentials, then  I use my default credentials.

Then I have some questions about libkrb5.

Several things need to happen to request anonymous credentials from an AS:

* You need the anonymous principal name as the client
* You need the anonymous KDC option set
* You must use pkinit with DH

First krb5 question: How much work should krb5_get_init_creds do to
make things consistent.  For example, should setting the client
principal name to anonymous set the anonymous option?  Should setting
the anonymous option set the client principal name?  Should either of
the above force pkinit?

Second question: I want to introduce an API that takes a realm and a
ccache and tries to obtain anonymous credentials for that realm.  Does
this sound good?

From hartmans at MIT.EDU  Tue Nov  3 11:22:24 2009
From: hartmans at MIT.EDU (Sam Hartman)
Date: Tue, 03 Nov 2009 11:22:24 -0500
Subject: const, the errors framework, and -Wcast-qual
In-Reply-To: <3304C9E3-826F-46E3-B383-CDCC21379D86@mit.edu> (Ken Raeburn's
	message of "Sun\, 1 Nov 2009 21\:44\:38 -0500")
References: <200911012255.nA1MtMkb009212@outgoing.mit.edu>
	<3304C9E3-826F-46E3-B383-CDCC21379D86@mit.edu>
Message-ID: <tslbpjjwpbz.fsf@mit.edu>

I agree that for non-refcounted objects that freeing a const pointer
is bad.

In the case of objects with refcounts where you may want to ask some
people not to mutate the object, I think freeing through a const
pointer when the last reference goes away is better than vere using
const pointers for such aliases.  That situation does not come up in our code base.

I also think that const pointers are justified when they sometimes
point to shared storage (like error strings) that it would be highly
undesirable to change even if that meant freeing through a const
pointer.

What I think I'm saying is that Anders/your rule of don't free through
const is probably too strong as a rule,but is a good guidline.  I
agree with you that applying that guideline in the cases you're
thinking of would improve the code.

--Sam

From Nicolas.Williams at sun.com  Tue Nov  3 11:39:28 2009
From: Nicolas.Williams at sun.com (Nicolas Williams)
Date: Tue, 3 Nov 2009 10:39:28 -0600
Subject: GSS-API and libkrb5 behavior for Anonymous tickets
In-Reply-To: <tslpr80mqp2.fsf@mit.edu>
References: <tslpr80mqp2.fsf@mit.edu>
Message-ID: <20091103163928.GZ1105@Sun.COM>


If you use the anonymous req_flag and a non-default credential handle,
and the credential handle is for anonymous desired_name, then there's no
"pathetic" fallback on non-anonymous authentication.

But if you use the anonymous req_flag and the default credential handle,
then technically the mechanism is free to not give you anonymity.

Given that there's a way to get anonymity-or-failure, I don't mind what
you call the "pathetic option".

> * If I pass the anonymous name into gss_acquire_credentials, what
>   happens?

You should get credentials.

> 1) If my default credentials are anonymous, then it works.  Otherwise,
> if I'm using KIM I may try to obtain anonymous credentials, but on
> Unix I fail.

Why do you fail?

> 2) If my default credentials are anonymous I use them.  Otherwise, I
> set up a new memory ccache and try to obtain anonymous credentials.
> If I fail, I return an error.

Yes.

> 3) Option 2 as above, except that if I fail to obtain anonymous
> credentials, then  I use my default credentials.

No!

> Then I have some questions about libkrb5.
> 
> Several things need to happen to request anonymous credentials from an AS:
> 
> * You need the anonymous principal name as the client
> * You need the anonymous KDC option set
> * You must use pkinit with DH
> 
> First krb5 question: How much work should krb5_get_init_creds do to
> make things consistent.  For example, should setting the client
> principal name to anonymous set the anonymous option?  Should setting
> the anonymous option set the client principal name?  Should either of
> the above force pkinit?

Yes, yes, and yes only if a pre-auth method wasn't requested by the app.

> Second question: I want to introduce an API that takes a realm and a
> ccache and tries to obtain anonymous credentials for that realm.  Does
> this sound good?

Yes.

Nico
-- 

From hartmans at MIT.EDU  Tue Nov  3 11:53:11 2009
From: hartmans at MIT.EDU (Sam Hartman)
Date: Tue, 03 Nov 2009 11:53:11 -0500
Subject: prefer Python for new scripts?
In-Reply-To: <ldvpr857dzx.fsf@cathode-dark-space.mit.edu> (Tom Yu's message of
	"Thu\, 29 Oct 2009 23\:32\:50 -0400")
References: <ldvpr857dzx.fsf@cathode-dark-space.mit.edu>
Message-ID: <tsl7hu7wnwo.fsf@mit.edu>

>>>>> "Tom" == Tom Yu <tlyu at MIT.EDU> writes:

    Tom> I propose that we move toward preferring Python for new
    Tom> scripts in the source tree.  Scripts in our tree are written
    Tom> in many languages, including Python, Perl, Tcl/Expect, Bourne
    Tom> shell, and others.

I definitely think that we should encourage people to write maintainable code.

However I also think that we should encourage people to write tests
etc.  I'd much rather see people actually write test scripts in
whatever language they are familiar with than not write scripts.

I think that if people focus on writing modular code, that my personal
recommendation is that we probably don't need a global recommendation
like this.

I definitely think that using Python is fine.  I also think that
moving away from the existing dejagnu tests would improve
maintainability.

--Sam

From ghudson at MIT.EDU  Tue Nov  3 11:55:00 2009
From: ghudson at MIT.EDU (Greg Hudson)
Date: Tue, 03 Nov 2009 11:55:00 -0500
Subject: GSS-API and libkrb5 behavior for Anonymous tickets
In-Reply-To: <tslpr80mqp2.fsf@mit.edu>
References: <tslpr80mqp2.fsf@mit.edu>
Message-ID: <1257267300.18519.9.camel@equal-rites.mit.edu>

Does Heimdal have anonymous pkinit support yet?  We should try to be
consistent with its behavior if so.

My preference for gss_init_sec_context behavior is option 2 (use
anonymous credentials if present, otherwise use existing credentials and
do not set anon_state).  Testing of failure to get anonymous credentials
can be done through non-GSSAPI interfaces.

I am not yet sure what my preference is for gss_acquire_credentials
behavior.  Option two (get anonymous credentials either from the default
cache or in a new memory cache) sounds good on the surface.

For libkrb5, I think there should be a clearly-defined interface for
getting anonymous creds, but if that interface is not used, the library
should not make any additional effort to make things consistent.  I
don't yet have an opinion on what the anonymous API should look like.

Finally: it's my understanding (though I haven't read the anonymous
pkinit spec) that it is valid to do anonymous pkinit to a realm you
can't verify the certificate of, and that this may be valuable in
obtaining a FAST armor ticket--with the proviso that your armor is then
vulnerable to a man-in-the-middle attack.  It sounds like your
implementation is not going to allow that case at first, but the
interface should keep that case in mind as a future possibility.



From Nicolas.Williams at sun.com  Tue Nov  3 12:05:29 2009
From: Nicolas.Williams at sun.com (Nicolas Williams)
Date: Tue, 3 Nov 2009 11:05:29 -0600
Subject: GSS-API and libkrb5 behavior for Anonymous tickets
In-Reply-To: <1257267300.18519.9.camel@equal-rites.mit.edu>
References: <tslpr80mqp2.fsf@mit.edu>
	<1257267300.18519.9.camel@equal-rites.mit.edu>
Message-ID: <20091103170528.GA1105@Sun.COM>

On Tue, Nov 03, 2009 at 11:55:00AM -0500, Greg Hudson wrote:
> Finally: it's my understanding (though I haven't read the anonymous
> pkinit spec) that it is valid to do anonymous pkinit to a realm you
> can't verify the certificate of, and that this may be valuable in
> obtaining a FAST armor ticket--with the proviso that your armor is then
> vulnerable to a man-in-the-middle attack.  It sounds like your
> implementation is not going to allow that case at first, but the
> interface should keep that case in mind as a future possibility.

The GSS-API certainly allows the mechanism to have an anonymous name
type for acceptor naming...  This could be allowed -- it can't happen
accidentally, though it may not be very useful at all, so if Sam doesn't
want to implement it, I understand.

From hartmans at MIT.EDU  Tue Nov  3 12:37:47 2009
From: hartmans at MIT.EDU (Sam Hartman)
Date: Tue, 03 Nov 2009 12:37:47 -0500
Subject: GSS-API and libkrb5 behavior for Anonymous tickets
In-Reply-To: <1257267300.18519.9.camel@equal-rites.mit.edu> (Greg Hudson's
	message of "Tue\, 03 Nov 2009 11\:55\:00 -0500")
References: <tslpr80mqp2.fsf@mit.edu>
	<1257267300.18519.9.camel@equal-rites.mit.edu>
Message-ID: <tsl3a4vwluc.fsf@mit.edu>

>>>>> "Greg" == Greg Hudson <ghudson at MIT.EDU> writes:


    Greg> Finally: it's my understanding (though I haven't read the
    Greg> anonymous pkinit spec) that it is valid to do anonymous
    Greg> pkinit to a realm you can't verify the certificate of, and
    Greg> that this may be valuable in obtaining a FAST armor
    Greg> ticket--with the proviso that your armor is then vulnerable
    Greg> to a man-in-the-middle attack.  It sounds like your
    Greg> implementation is not going to allow that case at first, but
    Greg> the interface should keep that case in mind as a future
    Greg> possibility.

I agree the libkrb5 interface should keep that in mind.  I'm not sure
this matches the GSS-API model well enough to support there.

In particular, take a look at the requirements in
draft-ietf-krb-wg-anon-10 for the anonymous KDC case.  The text seems
to place a fairly strong requirement that you verify the KDC before
using the ticket.  So, I'm not sure it would be permitted to use it in
a normal ap exchange.  If we ignore that, then it would perhaps be
permissible to use such a ticket in gss-api with the mutual
authentication flag cleared, although you would get very different
security guarantees than you typically do with Kerberos especially if
you use per-message protection.  I'm not sure if that's OK or not.

From Nicolas.Williams at sun.com  Tue Nov  3 12:41:55 2009
From: Nicolas.Williams at sun.com (Nicolas Williams)
Date: Tue, 3 Nov 2009 11:41:55 -0600
Subject: GSS-API and libkrb5 behavior for Anonymous tickets
In-Reply-To: <tslpr80mqp2.fsf@mit.edu>
References: <tslpr80mqp2.fsf@mit.edu>
Message-ID: <20091103174155.GB1105@Sun.COM>

In my interpretation, the principles of the GSS-API w.r.t. anonymity are
as follows:

 - If you use a non-default credential handle when calling
   gss_init_sec_context(), then the mechanism is constrained to
   authenticating only that handle's desired_name as the initiator
   principal, UNLESS the anon req_flag is set (more on that below).

    - If you use a credential handle for a desired_name with anonymous
      or anonymous-like name type, then you can only get anonymity (or
      pseudonymity; see below) when you call gss_init_sec_context() with
      that credential handle.

      The GSS-API doesn't have a notion of credential store or of
      "initial credentials", so it's possible that one could get
      pseudonymity instead of anonymity unless the caller sets the
      anonymous req_flag (they have to then check that it's set in the
      ret_flags).  That is, the implementation might fetch an anonymous
      TGT and then fetch service tickets using that TGT, which might
      allow all the various services to track the initiators' actions
      back to that one anon TGT.  gss_acquire_cred() could store
      credentials for anonymous desired_names in the current ccache, but
      I'd rather that it always return fresh credentials when
      desired_name is an anonymous name.

 - To use a default credential handle is the same as to use a credential
   handle whose desired_name matches the default principal of the
   current credential store (ccache).  See above.

 - req_flags are all optional; a mechanism is free to grant more or
   fewer than requested, and the caller of gss_init_sec_context() must
   check ret_flags.  However, ret_flags must be set appropriately as
   soon as possible!  RFC2743 says:

   "
   Callers wishing to perform context establishment only if anonymity
   support is provided should transfer a returned token from
   GSS_Init_sec_context() to the peer only if it is accompanied by a
   TRUE anon_state indicator.
   "

   This leaves the mechanism designer/implementor a lot of freedom.  Too
   much freedom, I think.  But not so much freedom that a careful
   application would ever authenticate a non-anon initiator
   accidentally.

   (Aside: it would be very odd to set the anonymous ret_flag when the
   caller did not request it and the initiator credential handle was not
   an anonymous one.  This should just not happen.  Note that mechanisms
   that can only do anon initiator name authentication can only have
   anon cred handles.  If you use SPNEGO, a default credential handle,
   and such a mechanism, then you could see the anon ret_flag set even
   though the caller did not set the anon req_flag.)

   Thus to call gss_init_sec_context() with the default credential when
   there's a non-anonymous crendential available, and the anonymous
   req_flag means that the mechanism is free to authenticate the
   initiator non-anonymously (and not set the anonymous ret_flag).

   Just because the mechanism can do that doesn't mean it should.  I'd
   rather treat the anon req_flag as critical in the mechanism
   implementations, even though from the application's p.o.v. it's
   optional.

We can derive these rules for the krb5 mech from the above:

1) If the app calls gss_import_name() with GSS_C_NT_ANONYMOUS to get an
   anon name, then calls gss_acquire_cred(), then for the krb5 mech that
   implements anonymous PKINIT this should work.

   We may need to define a krb5-specific anon name-type whose syntax
   allows the specification of a realm name.  But use of that should be
   optional.

2) If the app calls gss_acquire_cred() with desired_name == some
   anonymous or anonymous-like name, then the krb5 mech should acquire
   anon tickets, or defer this to the point where gss_init_sec_context()
   is called.

3) If the app calls gss_init_sec_context() with an anonymous credential
   handle then:

   a) the krb5 mech should authenticate that credential's anonymous
   desired_name and NEVER authenticate the caller's default credential's
   desired_name, if there are any non-anon default creds;

   b) the anon ret_flag should be set regardless of whether the anon
   req_flag was set.

4) If the app calls gss_init_sec_context() with a default credential, or
   with a non-anonymous credential handle *and* sets the anon req_flag,
   then technically the krb5 mech should attempt anonymous
   authentication and may fail without authenticating the non-anon
   initiator name if it could not do anonymous authentication.  Ideally
   the mechanism should attempt anon auth and must fail without
   authenticating the non-anon initiator.  (If anon auth succeeds, then
   the anon ret_flag must be set, of course.)

Nico
-- 

From Nicolas.Williams at sun.com  Tue Nov  3 12:47:27 2009
From: Nicolas.Williams at sun.com (Nicolas Williams)
Date: Tue, 3 Nov 2009 11:47:27 -0600
Subject: GSS-API and libkrb5 behavior for Anonymous tickets
In-Reply-To: <tsl3a4vwluc.fsf@mit.edu>
References: <tslpr80mqp2.fsf@mit.edu>
	<1257267300.18519.9.camel@equal-rites.mit.edu>
	<tsl3a4vwluc.fsf@mit.edu>
Message-ID: <20091103174726.GC1105@Sun.COM>

On Tue, Nov 03, 2009 at 12:37:47PM -0500, Sam Hartman wrote:
> >>>>> "Greg" == Greg Hudson <ghudson at MIT.EDU> writes:
>     Greg> Finally: it's my understanding (though I haven't read the
>     Greg> anonymous pkinit spec) that it is valid to do anonymous
>     Greg> pkinit to a realm you can't verify the certificate of, and
>     Greg> that this may be valuable in obtaining a FAST armor
>     Greg> ticket--with the proviso that your armor is then vulnerable
>     Greg> to a man-in-the-middle attack.  It sounds like your
>     Greg> implementation is not going to allow that case at first, but
>     Greg> the interface should keep that case in mind as a future
>     Greg> possibility.
> 
> I agree the libkrb5 interface should keep that in mind.  I'm not sure
> this matches the GSS-API model well enough to support there.
> 
> In particular, take a look at the requirements in
> draft-ietf-krb-wg-anon-10 for the anonymous KDC case.  The text seems
> to place a fairly strong requirement that you verify the KDC before
> using the ticket.  So, I'm not sure it would be permitted to use it in
> a normal ap exchange.  If we ignore that, then it would perhaps be
> permissible to use such a ticket in gss-api with the mutual
> authentication flag cleared, although you would get very different
> security guarantees than you typically do with Kerberos especially if
> you use per-message protection.  I'm not sure if that's OK or not.

The GSS-API very explicitly contemplates, and allows, for security
contexts with anonymous initiator and acceptor names.

Clearly such security contexts are, practiclaly by definition, subject
to MITM attacks.  But the API allows them.  One supposes that by using
extended naming APIs one could extract a realm's KDC's certificate and
then use that for SSH-style leap-of-faith authentication.  But mostly I
think this is useless.

I'm happy to have the mechanism support this, or not.  The only good
reason to not support it is that it would be wasting your time on a
useless feature (I don't see the draft-ietf-krb-wg-anon-10 requirement
as applicable to the GSS-API mechanism -- it shouldn't be, in any case).
And I see no good reasons to support it other than completeness.

(Maybe some day we'll have a reasonable use case fo SSH-style leap-of-
faith as described above.  Someone can implement this then.)

Nico
-- 

From epeisach at MIT.EDU  Tue Nov  3 13:34:40 2009
From: epeisach at MIT.EDU (Ezra Peisach)
Date: Tue, 03 Nov 2009 13:34:40 -0500
Subject: prefer Python for new scripts?
In-Reply-To: <tsl7hu7wnwo.fsf@mit.edu>
References: <ldvpr857dzx.fsf@cathode-dark-space.mit.edu>
	<tsl7hu7wnwo.fsf@mit.edu>
Message-ID: <4AF077C0.4030709@mit.edu>

On 11/03/2009 11:53 AM, Sam Hartman wrote:
>
> I definitely think that using Python is fine.  I also think that
> moving away from the existing dejagnu tests would improve
> maintainability.
>
> --Sam
> _______________________________________________
>    

One of the challenges with dejagnu is getting it to run with the test 
suite... Sometimes the fault is dejagnu, sometime expect. Under Fedora 
9/10/11 expect has issues with the newer tcl and dynamic loading of the 
clock module... I have to use a static compiled version of expect with 
an older tcl version to avoid the problem...
So - if someone could write the equivalent in python that is standalone 
w/o esoteric software being installed  - I am all for it...

Ezra

From hartmans at MIT.EDU  Tue Nov  3 14:11:43 2009
From: hartmans at MIT.EDU (Sam Hartman)
Date: Tue, 03 Nov 2009 14:11:43 -0500
Subject: GSS-API and libkrb5 behavior for Anonymous tickets
In-Reply-To: <20091103174726.GC1105@Sun.COM> (Nicolas Williams's message of
	"Tue\, 3 Nov 2009 11\:47\:27 -0600")
References: <tslpr80mqp2.fsf@mit.edu>
	<1257267300.18519.9.camel@equal-rites.mit.edu>
	<tsl3a4vwluc.fsf@mit.edu> <20091103174726.GC1105@Sun.COM>
Message-ID: <tslocnjpgnk.fsf@mit.edu>

>>>>> "Nicolas" == Nicolas Williams <Nicolas.Williams at sun.com> writes:

    >> I agree the libkrb5 interface should keep that in mind.  I'm
    >> not sure this matches the GSS-API model well enough to support
    >> there.
    >> 
    >> In particular, take a look at the requirements in
    >> draft-ietf-krb-wg-anon-10 for the anonymous KDC case.  The text
    >> seems to place a fairly strong requirement that you verify the
    >> KDC before using the ticket.  So, I'm not sure it would be
    >> permitted to use it in a normal ap exchange.  If we ignore
    >> that, then it would perhaps be permissible to use such a ticket
    >> in gss-api with the mutual authentication flag cleared,
    >> although you would get very different security guarantees than
    >> you typically do with Kerberos especially if you use
    >> per-message protection.  I'm not sure if that's OK or not.

    Nicolas> The GSS-API very explicitly contemplates, and allows, for
    Nicolas> security contexts with anonymous initiator and acceptor
    Nicolas> names.


Really?
I was not aware that security contexts with anonymous acceptor names were permitted.
Do you have a reference handy?

From Nicolas.Williams at sun.com  Tue Nov  3 14:13:55 2009
From: Nicolas.Williams at sun.com (Nicolas Williams)
Date: Tue, 3 Nov 2009 13:13:55 -0600
Subject: GSS-API and libkrb5 behavior for Anonymous tickets
In-Reply-To: <tslocnjpgnk.fsf@mit.edu>
References: <tslpr80mqp2.fsf@mit.edu>
	<1257267300.18519.9.camel@equal-rites.mit.edu>
	<tsl3a4vwluc.fsf@mit.edu> <20091103174726.GC1105@Sun.COM>
	<tslocnjpgnk.fsf@mit.edu>
Message-ID: <20091103191354.GE1105@Sun.COM>

On Tue, Nov 03, 2009 at 02:11:43PM -0500, Sam Hartman wrote:
>     Nicolas> The GSS-API very explicitly contemplates, and allows, for
>     Nicolas> security contexts with anonymous initiator and acceptor
>     Nicolas> names.
> 
> Really?
> I was not aware that security contexts with anonymous acceptor names were permitted.
> Do you have a reference handy?

I mis-read RFC2743, section 1.2.5, page 25.  On second re-reading
RFC2743 is explicit only about initiator names as anonymous names.  But
even so, why would anonymous acceptor names not be permitted?

Nico
-- 

From jhutz at cmu.edu  Wed Nov  4 14:19:05 2009
From: jhutz at cmu.edu (Jeffrey Hutzelman)
Date: Wed, 04 Nov 2009 14:19:05 -0500
Subject: GSS-API and libkrb5 behavior for Anonymous tickets
In-Reply-To: <27186_1257270840_nA3HrxFB020404_20091103174155.GB1105@Sun.COM>
References: <tslpr80mqp2.fsf@mit.edu>
	<27186_1257270840_nA3HrxFB020404_20091103174155.GB1105@Sun.COM>
Message-ID: <B8FEBA5D093FA1D9C96EF992@atlantis.pc.cs.cmu.edu>

--On Tuesday, November 03, 2009 11:41:55 AM -0600 Nicolas Williams 
<Nicolas.Williams at sun.com> wrote:

>    Just because the mechanism can do that doesn't mean it should.  I'd
>    rather treat the anon req_flag as critical in the mechanism
>    implementations, even though from the application's p.o.v. it's
>    optional.

Me too.

Normally, we tell application implementors to check the return state and 
not use a context that doesn't meet the application's needs; this allows 
applications lots of flexibility in asking for the moon and using what they 
can get.  However, anon_req is qualitatively different here, in that if you 
request an anonymous context, complete context establishment, and end up 
with a non-anonymous context, you've given away the farm even if you don't 
use the context.  Now, we provide applications a way to prevent this by 
indicating anon_state early enough that they can decline to send a token 
along that would reveal the client's identity.  But, I'm inclined to think 
it's better (safer) for mechanisms simply not to establish a context at all 
if anonymity is requested and cannot be provided.

-- Jeff

From hartmans at MIT.EDU  Wed Nov  4 16:07:22 2009
From: hartmans at MIT.EDU (Sam Hartman)
Date: Wed, 04 Nov 2009 16:07:22 -0500
Subject: FAST Negotiation API confirmation
Message-ID: <tslvdhqj8xh.fsf@mit.edu>



http://k5wiki.kerberos.org/Projects/FAST_negotiation is mostly ready
for review (although people may ask for more detail during the
review).  I should send out the announcement this week.


I wanted to discuss one thing.  Currently, if a client provides an
armor ticket to the library, then FAST will be required.  That is, a
request will fail if FAST is not available.
However a comment in the header makes it clear that this is not the interface contract: we reserve the right to move from "must fast" to "should fast."

I propose to introduce a new API to require FAST.

I then propose the following logic:

* If an armor ticket is not provided we will not use FAST. [1] \ 
* If an armor ticket is provided  and FAST negotiation indicates that FAST is available then we will use it.
* If FAST negotiation didn't happen  but the KDC offers FAST, we'll use it if we have an armor ticket.

As a consequence of this, a 1.8 client against a 1.7 KDC may provide
an opportunity for an active attacker to force FAST to be unused.

Handling the part where we use FAST if it is offered even if we didn't
negotiate it may make preauth2.c a bit more ugly.  That's kind of
unfortunate, as that code is kind of complex already.  I'll see what I
can do to leave things better than I found them.  However, without
this support, you would have to explicitly require FAST to get FAST
against 1.7.

An alternative is to keep the 1.7 API behavior and add a new mechanism
for requesting FAST if negotiated.  I don't like that option because
it complicates application code for the common case.

[1] Unless of course I end up adding support for anonymous armor
tickets in an automated manner within the library.

From hartmans at MIT.EDU  Wed Nov  4 16:13:25 2009
From: hartmans at MIT.EDU (Sam Hartman)
Date: Wed, 04 Nov 2009 16:13:25 -0500
Subject: GSS-API and libkrb5 behavior for Anonymous tickets
In-Reply-To: <B8FEBA5D093FA1D9C96EF992@atlantis.pc.cs.cmu.edu> (Jeffrey
	Hutzelman's message of "Wed\, 04 Nov 2009 14\:19\:05 -0500")
References: <tslpr80mqp2.fsf@mit.edu>
	<27186_1257270840_nA3HrxFB020404_20091103174155.GB1105@Sun.COM>
	<B8FEBA5D093FA1D9C96EF992@atlantis.pc.cs.cmu.edu>
Message-ID: <tslr5sej8ne.fsf@mit.edu>

>>>>> "Jeffrey" == Jeffrey Hutzelman <jhutz at cmu.edu> writes:

    Jeffrey> --On Tuesday, November 03, 2009 11:41:55 AM -0600 Nicolas
    Jeffrey> Williams
    Jeffrey> <Nicolas.Williams at sun.com> wrote:

>    Just because the mechanism can do that doesn't mean it should.  I'd
    >> rather treat the anon req_flag as critical in the mechanism
    >> implementations, even though from the application's p.o.v. it's
    >> optional.

    Jeffrey> Me too.

    Jeffrey> Normally, we tell application implementors to check the
    Jeffrey> return state and not use a context that doesn't meet the
    Jeffrey> application's needs; this allows applications lots of
    Jeffrey> flexibility in asking for the moon and using what they
    Jeffrey> can get.  However, anon_req is qualitatively different
    Jeffrey> here, in that if you request an anonymous context,
    Jeffrey> complete context establishment, and end up with a
    Jeffrey> non-anonymous context, you've given away the farm even if
    Jeffrey> you don't use the context.  Now, we provide applications
    Jeffrey> a way to prevent this by indicating anon_state early
    Jeffrey> enough that they can decline to send a token along that
    Jeffrey> would reveal the client's identity.  But, I'm inclined to
    Jeffrey> think it's better (safer) for mechanisms simply not to
    Jeffrey> establish a context at all if anonymity is requested and
    Jeffrey> cannot be provided.

If you're going to do the work to standardize this behavior, I wouldn't mind much, although I probably would mildly disagree.

However, I disagree fairly strongly unless this is going to be
accompanied by an update to 2743.  My argument is that it breaks
conforming GSS-API applications.  If I'd prefer anonymous but would be
willing to accept an authenticated context, then I would end up
failing with your mechanism.  If I'm writing a portable application I
have to check the output flag anyway, even if some mechanisms do offer
this behavior.

So, with your approach, you complicate the life of every portable application.
That seems poor.

From Nicolas.Williams at sun.com  Wed Nov  4 16:20:44 2009
From: Nicolas.Williams at sun.com (Nicolas Williams)
Date: Wed, 4 Nov 2009 15:20:44 -0600
Subject: GSS-API and libkrb5 behavior for Anonymous tickets
In-Reply-To: <tslr5sej8ne.fsf@mit.edu>
References: <tslpr80mqp2.fsf@mit.edu>
	<27186_1257270840_nA3HrxFB020404_20091103174155.GB1105@Sun.COM>
	<B8FEBA5D093FA1D9C96EF992@atlantis.pc.cs.cmu.edu>
	<tslr5sej8ne.fsf@mit.edu>
Message-ID: <20091104212043.GF1105@Sun.COM>

On Wed, Nov 04, 2009 at 04:13:25PM -0500, Sam Hartman wrote:
> If you're going to do the work to standardize this behavior, I
> wouldn't mind much, although I probably would mildly disagree.
> 
> However, I disagree fairly strongly unless this is going to be
> accompanied by an update to 2743.  My argument is that it breaks
> conforming GSS-API applications.  If I'd prefer anonymous but would be
> willing to accept an authenticated context, then I would end up
> failing with your mechanism.  If I'm writing a portable application I
> have to check the output flag anyway, even if some mechanisms do offer
> this behavior.

Interesting.  I'm not sure what the value of that is.  I suppose one
might be signing on to a comment board where one might act differently
according to whether one is anonymous, for example.

> So, with your approach, you complicate the life of every portable
> application.  That seems poor.

I don't think mechanisms are required to act as you say though.  But
yes, if there's any value to the optional anonymity, then I'd have to
agree.

I'd certainly expect apps where anonymity matters to: a) uses
GSS_C_NT_ANONYMOUS names for the initiator's credential's desired_name,
b) use the anon req_flag, c) check for the presence of the anon ret_flag
after each call to gss_init_sec_context().

Nico
-- 

From ghudson at MIT.EDU  Wed Nov  4 16:43:23 2009
From: ghudson at MIT.EDU (Greg Hudson)
Date: Wed, 04 Nov 2009 16:43:23 -0500
Subject: GSS-API and libkrb5 behavior for Anonymous tickets
In-Reply-To: <tslr5sej8ne.fsf@mit.edu>
References: <tslpr80mqp2.fsf@mit.edu>
	<27186_1257270840_nA3HrxFB020404_20091103174155.GB1105@Sun.COM>
	<B8FEBA5D093FA1D9C96EF992@atlantis.pc.cs.cmu.edu>
	<tslr5sej8ne.fsf@mit.edu>
Message-ID: <1257371003.5933.414.camel@ray>

On Wed, 2009-11-04 at 16:13 -0500, Sam Hartman wrote:
> However, I disagree fairly strongly unless this is going to be
> accompanied by an update to 2743.  My argument is that it breaks
> conforming GSS-API applications.  If I'd prefer anonymous but would be
> willing to accept an authenticated context, then I would end up
> failing with your mechanism.  If I'm writing a portable application I
> have to check the output flag anyway, even if some mechanisms do offer
> this behavior.

I agree with Sam.  I don't see any point in providing safety that
applications can't rely on.  It seems like it would only encourage apps
to improperly rely on gss-krb5's safety and then be unsafe if used with
a different mechanism.



From ghudson at MIT.EDU  Wed Nov  4 16:49:10 2009
From: ghudson at MIT.EDU (Greg Hudson)
Date: Wed, 04 Nov 2009 16:49:10 -0500
Subject: const, the errors framework, and -Wcast-qual
In-Reply-To: <200911012255.nA1MtMkb009212@outgoing.mit.edu>
References: <200911012255.nA1MtMkb009212@outgoing.mit.edu>
Message-ID: <1257371350.5933.416.camel@ray>

To close out this thread:

* I removed -Wcast-qual from the standard gcc warnings set.

* I'm not going to unconstify the errors framework further, because I
realized that it would be pointless to change krb5_get_error_message
without also changing krb5_free_error_message, and changing the latter
to take a char * would be incompatible with existing code.



From ghudson at MIT.EDU  Thu Nov  5 10:21:52 2009
From: ghudson at MIT.EDU (Greg Hudson)
Date: Thu, 05 Nov 2009 10:21:52 -0500
Subject: FAST Negotiation API confirmation
In-Reply-To: <tslvdhqj8xh.fsf@mit.edu>
References: <tslvdhqj8xh.fsf@mit.edu>
Message-ID: <1257434512.5933.420.camel@ray>

I think this is fine.

I was assuming that obtaining anonymous pkinit armor would be handled by
kinit, but I guess there are other options.



From hartmans at MIT.EDU  Thu Nov  5 16:25:35 2009
From: hartmans at MIT.EDU (Sam Hartman)
Date: Thu, 05 Nov 2009 16:25:35 -0500
Subject: FAST Negotiation API confirmation
In-Reply-To: <1257434512.5933.420.camel@ray> (Greg Hudson's message of "Thu\,
	05 Nov 2009 10\:21\:52 -0500")
References: <tslvdhqj8xh.fsf@mit.edu> <1257434512.5933.420.camel@ray>
Message-ID: <tsld43wy88g.fsf@mit.edu>

>>>>> "Greg" == Greg Hudson <ghudson at MIT.EDU> writes:

    Greg> I think this is fine.  I was assuming that obtaining
    Greg> anonymous pkinit armor would be handled by kinit, but I
    Greg> guess there are other options.

What I'm doing will definitely support that.  I think you could
provide a significantly better user experience by doing so behind the
scenes and storing the armor ticket in a memory ccache.

From dan.searle at censornet.com  Fri Nov  6 11:22:23 2009
From: dan.searle at censornet.com (Dan Searle)
Date: Fri, 06 Nov 2009 16:22:23 +0000
Subject: Memory leaks in Kerberos 5 1.6.4-beta1 and 1.7
Message-ID: <4AF44D3F.8050907@censornet.com>

Hi,

I came across two memory leaks in the Kerberos 5 libs after using the 
squid_kerb_auth helper in squid which performs single sign with 
KRB5RCACHETYPE=none. I.e. with the replay protection cache switched off.

The reason I switched off the cache was because of performance problems 
with it switched on, after a few thousand authentications in a short 
time period, the cache became a bottleneck with individual 
authentications taking in the order of a few seconds rather than tenths 
or hundredths of a second. This bottleneck seems to be because the 
Kerberos libs perform a linear search of old tickets in the cache to 
prevent replay attacks, and with a large rate of authentication sessions 
the linear search is too inefficient.

Running the squid_kerb_auth helper through valgrind with 
--leak-check=full --leak-resolution=high options, and with the 
environment variable KRB5RCACHETYPE=none here are the results:


after 1 successful authentication, then quit:
==10794== 68 bytes in 1 blocks are definitely lost in loss record 66 of 79
==10794==    at 0x4022AB8: malloc (vg_replace_malloc.c:207)
==10794==    by 0x40C19D0: krb5_rc_resolve_full (rc_base.c:152)
==10794==    by 0x40BEDF8: krb5_get_server_rcache (srv_rcache.c:107)
==10794==    by 0x403FE9A: krb5_gss_acquire_cred (acquire_cred.c:192)
==10794==    by 0x404B29D: k5glue_acquire_cred (krb5_gss_glue.c:460)
==10794==    by 0x40348C5: gss_add_cred (g_acquire_cred.c:382)
==10794==    by 0x4034D15: gss_acquire_cred (g_acquire_cred.c:188)
==10794==    by 0x8049C31: main (squid_kerb_auth.c:489)


after 2 successful authentications, then quit:
==10710== 68 bytes in 1 blocks are definitely lost in loss record 66 of 80
==10710==    at 0x4022AB8: malloc (vg_replace_malloc.c:207)
==10710==    by 0x40C19D0: krb5_rc_resolve_full (rc_base.c:152)
==10710==    by 0x40BEDF8: krb5_get_server_rcache (srv_rcache.c:107)
==10710==    by 0x40B8EDD: krb5_rd_req (rd_req.c:89)
==10710==    by 0x403D910: krb5_gss_accept_sec_context 
(accept_sec_context.c:408)
==10710==    by 0x404B192: k5glue_accept_sec_context (krb5_gss_glue.c:434)
==10710==    by 0x4034178: gss_accept_sec_context 
(g_accept_sec_context.c:196)
==10710==    by 0x40510A7: spnego_gss_accept_sec_context 
(spnego_mech.c:1113)
==10710==    by 0x4034178: gss_accept_sec_context 
(g_accept_sec_context.c:196)
==10710==    by 0x8049CC8: main (squid_kerb_auth.c:495)
==10710==
==10710==
==10710== 136 bytes in 2 blocks are definitely lost in loss record 70 of 80
==10710==    at 0x4022AB8: malloc (vg_replace_malloc.c:207)
==10710==    by 0x40C19D0: krb5_rc_resolve_full (rc_base.c:152)
==10710==    by 0x40BEDF8: krb5_get_server_rcache (srv_rcache.c:107)
==10710==    by 0x403FE9A: krb5_gss_acquire_cred (acquire_cred.c:192)
==10710==    by 0x404B29D: k5glue_acquire_cred (krb5_gss_glue.c:460)
==10710==    by 0x40348C5: gss_add_cred (g_acquire_cred.c:382)
==10710==    by 0x4034D15: gss_acquire_cred (g_acquire_cred.c:188)
==10710==    by 0x8049C31: main (squid_kerb_auth.c:489)


after 5 successful authentications, then quit:
==10849== 272 bytes in 4 blocks are definitely lost in loss record 73 of 80
==10849==    at 0x4022AB8: malloc (vg_replace_malloc.c:207)
==10849==    by 0x40C19D0: krb5_rc_resolve_full (rc_base.c:152)
==10849==    by 0x40BEDF8: krb5_get_server_rcache (srv_rcache.c:107)
==10849==    by 0x40B8EDD: krb5_rd_req (rd_req.c:89)
==10849==    by 0x403D910: krb5_gss_accept_sec_context 
(accept_sec_context.c:408)
==10849==    by 0x404B192: k5glue_accept_sec_context (krb5_gss_glue.c:434)
==10849==    by 0x4034178: gss_accept_sec_context 
(g_accept_sec_context.c:196)
==10849==    by 0x40510A7: spnego_gss_accept_sec_context 
(spnego_mech.c:1113)
==10849==    by 0x4034178: gss_accept_sec_context 
(g_accept_sec_context.c:196)
==10849==    by 0x8049CC8: main (squid_kerb_auth.c:495)
==10849==
==10849==
==10849== 340 bytes in 5 blocks are definitely lost in loss record 74 of 80
==10849==    at 0x4022AB8: malloc (vg_replace_malloc.c:207)
==10849==    by 0x40C19D0: krb5_rc_resolve_full (rc_base.c:152)
==10849==    by 0x40BEDF8: krb5_get_server_rcache (srv_rcache.c:107)
==10849==    by 0x403FE9A: krb5_gss_acquire_cred (acquire_cred.c:192)
==10849==    by 0x404B29D: k5glue_acquire_cred (krb5_gss_glue.c:460)
==10849==    by 0x40348C5: gss_add_cred (g_acquire_cred.c:382)
==10849==    by 0x4034D15: gss_acquire_cred (g_acquire_cred.c:188)
==10849==    by 0x8049C31: main (squid_kerb_auth.c:489)

Please note that these leaks do not occur with the KRB5RCACHETYPE 
environment variable unset, i.e. with the ticket cache enabled.

Regards, Dan...

-- 
Dan Searle

CensorNet Ltd - professional & affordable Web & E-mail filtering
email: dan.searle at censornet.com web: www.censornet.com
tel: 0845 230 9590 / fax: 0845 230 9591 / support: 0845 230 9592
snail: Vallon House, Vantage Court Office Park, Winterbourne,
       Bristol, BS16 1GW, UK.

CensorNet Ltd is a registered company in England & Wales No. 05518629
VAT registration number 901-2048-78
Any views expressed in this email communication are those of the
individual sender, except where the sender specifically states them to
be the views of a member of Censornet Ltd.  Censornet Ltd. does not
represent, warrant or guarantee that the integrity of this
communication has been maintained nor that the communication is free
of errors or interference. 


------------------------------------------------------------------------------------
Scanned for viruses, spam and offensive content by CensorNet MailSafe

Try CensorNet free for 14 days. Provide Internet access on your terms.
Visit www.censornet.com for more information.


From raeburn at MIT.EDU  Fri Nov  6 12:36:55 2009
From: raeburn at MIT.EDU (Ken Raeburn)
Date: Fri, 6 Nov 2009 12:36:55 -0500
Subject: Memory leaks in Kerberos 5 1.6.4-beta1 and 1.7
In-Reply-To: <4AF44D3F.8050907@censornet.com>
References: <4AF44D3F.8050907@censornet.com>
Message-ID: <2FB6EC3B-1C70-46B4-A672-DD5AC50DA763@mit.edu>

On Nov 6, 2009, at 11:22, Dan Searle wrote:
> I came across two memory leaks in the Kerberos 5 libs after using the
> squid_kerb_auth helper in squid which performs single sign with
> KRB5RCACHETYPE=none. I.e. with the replay protection cache switched  
> off.

These should be fixed in 1.7.1.  You can see the ticket (with a link  
to a patch you can try out) at http://krbdev.mit.edu/rt/Ticket/Display.html?id=6514 
  .  (Both problems listed in your email seem to be regarding the same  
allocation site where we weren't freeing the storage, just with  
different callers further up the stack.)  If that doesn't fix the  
problem for you, please let us know.

Ken


-- 
Ken Raeburn / raeburn at mit.edu / no longer at MIT Kerberos Consortium


From dan.searle at censornet.com  Fri Nov  6 13:02:16 2009
From: dan.searle at censornet.com (Dan Searle)
Date: Fri, 06 Nov 2009 18:02:16 +0000
Subject: Memory leaks in Kerberos 5 1.6.4-beta1 and 1.7
In-Reply-To: <2FB6EC3B-1C70-46B4-A672-DD5AC50DA763@mit.edu>
References: <4AF44D3F.8050907@censornet.com>
	<2FB6EC3B-1C70-46B4-A672-DD5AC50DA763@mit.edu>
Message-ID: <4AF464A8.5090403@censornet.com>

Hi,

I tried the patch (applied to the 1.7 public release as I don't have 
access to the 1.7.1 branch), however now I get a different leak:

==16212== 50 bytes in 2 blocks are definitely lost in loss record 66 of 81
==16212==    at 0x4022AB8: malloc (vg_replace_malloc.c:207)
==16212==    by 0x4195FCF: strdup (in /lib/tls/i686/cmov/libc-2.7.so)
==16212==    by 0x41DF9D9: (within /lib/tls/i686/cmov/libc-2.7.so)
==16212==    by 0x41E1AD8: getaddrinfo (in /lib/tls/i686/cmov/libc-2.7.so)
==16212==    by 0x4279F38: krb5int_getaddrinfo (fake-addrinfo.c:315)
==16212==    by 0x40BE474: krb5_sname_to_principal (sn2princ.c:112)
==16212==    by 0x4042318: krb5_gss_import_name (import_name.c:99)
==16212==    by 0x403703B: gssint_import_internal_name (g_glue.c:306)
==16212==    by 0x403502F: gss_add_cred (g_acquire_cred.c:383)
==16212==    by 0x403535B: gss_acquire_cred (g_acquire_cred.c:198)
==16212==    by 0x8049C31: main (squid_kerb_auth.c:489)

Regards, Dan...

Ken Raeburn wrote:
> On Nov 6, 2009, at 11:22, Dan Searle wrote:
>   
>> I came across two memory leaks in the Kerberos 5 libs after using the
>> squid_kerb_auth helper in squid which performs single sign with
>> KRB5RCACHETYPE=none. I.e. with the replay protection cache switched  
>> off.
>>     
>
> These should be fixed in 1.7.1.  You can see the ticket (with a link  
> to a patch you can try out) at http://krbdev.mit.edu/rt/Ticket/Display.html?id=6514 
>   .  (Both problems listed in your email seem to be regarding the same  
> allocation site where we weren't freeing the storage, just with  
> different callers further up the stack.)  If that doesn't fix the  
> problem for you, please let us know.
>
> Ken
>
>
>   
> ------------------------------------------------------------------------
>
>
> No virus found in this incoming message.
> Checked by AVG - www.avg.com 
> Version: 9.0.698 / Virus Database: 270.14.52/2484 - Release Date: 11/06/09 07:38:00
>
>   


-- 
Dan Searle

CensorNet Ltd - professional & affordable Web & E-mail filtering
email: dan.searle at censornet.com web: www.censornet.com
tel: 0845 230 9590 / fax: 0845 230 9591 / support: 0845 230 9592
snail: Vallon House, Vantage Court Office Park, Winterbourne,
       Bristol, BS16 1GW, UK.

CensorNet Ltd is a registered company in England & Wales No. 05518629
VAT registration number 901-2048-78
Any views expressed in this email communication are those of the
individual sender, except where the sender specifically states them to
be the views of a member of Censornet Ltd.  Censornet Ltd. does not
represent, warrant or guarantee that the integrity of this
communication has been maintained nor that the communication is free
of errors or interference. 


------------------------------------------------------------------------------------
Scanned for viruses, spam and offensive content by CensorNet MailSafe

Try CensorNet free for 14 days. Provide Internet access on your terms.
Visit www.censornet.com for more information.


From raeburn at MIT.EDU  Fri Nov  6 18:41:44 2009
From: raeburn at MIT.EDU (Ken Raeburn)
Date: Fri, 6 Nov 2009 18:41:44 -0500
Subject: Memory leaks in Kerberos 5 1.6.4-beta1 and 1.7
In-Reply-To: <4AF464A8.5090403@censornet.com>
References: <4AF44D3F.8050907@censornet.com>
	<2FB6EC3B-1C70-46B4-A672-DD5AC50DA763@mit.edu>
	<4AF464A8.5090403@censornet.com>
Message-ID: <168B73DA-0F65-4E9E-A805-D1D28F2C52BD@mit.edu>

On Nov 6, 2009, at 13:02, Dan Searle wrote:
> Hi,
>
> I tried the patch (applied to the 1.7 public release as I don't have  
> access to the 1.7.1 branch),

If you don't have access to the anonymous subversion server, there's a  
nightly snapshot made available for ftp (but updated only when there  
are actually changes); info is at http://web.mit.edu/kerberos/krb5-current.html 
  .  The "krb5-1.7-current" snapshot is from the 1.7.x branch, last  
updated 9/29 when several bugfixes were incorporated.


> however now I get a different leak:
>
> ==16212== 50 bytes in 2 blocks are definitely lost in loss record 66  
> of 81
> ==16212==    at 0x4022AB8: malloc (vg_replace_malloc.c:207)
> ==16212==    by 0x4195FCF: strdup (in /lib/tls/i686/cmov/libc-2.7.so)
> ==16212==    by 0x41DF9D9: (within /lib/tls/i686/cmov/libc-2.7.so)
> ==16212==    by 0x41E1AD8: getaddrinfo (in /lib/tls/i686/cmov/ 
> libc-2.7.so)
> ==16212==    by 0x4279F38: krb5int_getaddrinfo (fake-addrinfo.c:315)
> ==16212==    by 0x40BE474: krb5_sname_to_principal (sn2princ.c:112)
> ==16212==    by 0x4042318: krb5_gss_import_name (import_name.c:99)
> ==16212==    by 0x403703B: gssint_import_internal_name (g_glue.c:306)
> ==16212==    by 0x403502F: gss_add_cred (g_acquire_cred.c:383)
> ==16212==    by 0x403535B: gss_acquire_cred (g_acquire_cred.c:198)
> ==16212==    by 0x8049C31: main (squid_kerb_auth.c:489)
>
> Regards, Dan...

That's storage allocated by the C library's getaddrinfo routine.  As  
near as I can tell, the fake-addrinfo.c code doesn't mess with the  
returned structures before freeing them; we just copy the data out  
into storage we're managing.  So it might be a libc bug.  You could  
try a little test:

In tests/resolve in your build tree, "make addrinfo-test fake-addrinfo- 
test".  That builds two programs by the obvious names; one will test  
the libc getaddrinfo routine, and the other tests our wrapper around  
it.  Try running both under valgrind, giving the local host name as an  
argument.  If valgrind reports a leak in addrinfo-test, it's very  
likely to be a libc bug; if it only reports a problem in fake-addrinfo- 
test, then it's MIT's bug.

Ken


-- 
Ken Raeburn / raeburn at mit.edu / no longer at MIT Kerberos Consortium


From dan.searle at censornet.com  Mon Nov  9 05:09:26 2009
From: dan.searle at censornet.com (Dan Searle)
Date: Mon, 09 Nov 2009 10:09:26 +0000
Subject: Memory leaks in Kerberos 5 1.6.4-beta1 and 1.7
In-Reply-To: <168B73DA-0F65-4E9E-A805-D1D28F2C52BD@mit.edu>
References: <4AF44D3F.8050907@censornet.com>	<2FB6EC3B-1C70-46B4-A672-DD5AC50DA763@mit.edu>	<4AF464A8.5090403@censornet.com>
	<168B73DA-0F65-4E9E-A805-D1D28F2C52BD@mit.edu>
Message-ID: <4AF7EA56.3030100@censornet.com>

Hi,

I downloaded the krb5-1.7-current snapshot, extracted, cd 
krb5-1.7-current/src, ./configure, cd tests/resolve, make, then ran both 
addrinfo-test and fake-addrinfo-test through valgrind with 
--leack-check=full and --leak-resolution=high.

addrinfo-test:
No leaks.

fake-addrinfo-test:
==23357== 25 bytes in 1 blocks are definitely lost in loss record 1 of 1
==23357==    at 0x4022AB8: malloc (vg_replace_malloc.c:207)
==23357==    by 0x40B9FCF: strdup (in /lib/tls/i686/cmov/libc-2.7.so)
==23357==    by 0x41039D9: (within /lib/tls/i686/cmov/libc-2.7.so)
==23357==    by 0x4105AD8: getaddrinfo (in /lib/tls/i686/cmov/libc-2.7.so)
==23357==    by 0x4030F38: krb5int_getaddrinfo (fake-addrinfo.c:315)
==23357==    by 0x8048AB5: main (addrinfo-test.c:263)
==23357==
==23357== LEAK SUMMARY:
==23357==    definitely lost: 25 bytes in 1 blocks.
==23357==      possibly lost: 0 bytes in 0 blocks.
==23357==    still reachable: 0 bytes in 0 blocks.
==23357==         suppressed: 0 bytes in 0 blocks.

The version of libc6 is the latest available package in Ubuntu Hardy, 
i.e. 2.7-10ubuntu5. Is this a libc bug or an MIT bug?

Regards, Dan...

Ken Raeburn wrote:
> On Nov 6, 2009, at 13:02, Dan Searle wrote:
>   
>> Hi,
>>
>> I tried the patch (applied to the 1.7 public release as I don't have  
>> access to the 1.7.1 branch),
>>     
>
> If you don't have access to the anonymous subversion server, there's a  
> nightly snapshot made available for ftp (but updated only when there  
> are actually changes); info is at http://web.mit.edu/kerberos/krb5-current.html 
>   .  The "krb5-1.7-current" snapshot is from the 1.7.x branch, last  
> updated 9/29 when several bugfixes were incorporated.
>
>
>   
>> however now I get a different leak:
>>
>> ==16212== 50 bytes in 2 blocks are definitely lost in loss record 66  
>> of 81
>> ==16212==    at 0x4022AB8: malloc (vg_replace_malloc.c:207)
>> ==16212==    by 0x4195FCF: strdup (in /lib/tls/i686/cmov/libc-2.7.so)
>> ==16212==    by 0x41DF9D9: (within /lib/tls/i686/cmov/libc-2.7.so)
>> ==16212==    by 0x41E1AD8: getaddrinfo (in /lib/tls/i686/cmov/ 
>> libc-2.7.so)
>> ==16212==    by 0x4279F38: krb5int_getaddrinfo (fake-addrinfo.c:315)
>> ==16212==    by 0x40BE474: krb5_sname_to_principal (sn2princ.c:112)
>> ==16212==    by 0x4042318: krb5_gss_import_name (import_name.c:99)
>> ==16212==    by 0x403703B: gssint_import_internal_name (g_glue.c:306)
>> ==16212==    by 0x403502F: gss_add_cred (g_acquire_cred.c:383)
>> ==16212==    by 0x403535B: gss_acquire_cred (g_acquire_cred.c:198)
>> ==16212==    by 0x8049C31: main (squid_kerb_auth.c:489)
>>
>> Regards, Dan...
>>     
>
> That's storage allocated by the C library's getaddrinfo routine.  As  
> near as I can tell, the fake-addrinfo.c code doesn't mess with the  
> returned structures before freeing them; we just copy the data out  
> into storage we're managing.  So it might be a libc bug.  You could  
> try a little test:
>
> In tests/resolve in your build tree, "make addrinfo-test fake-addrinfo- 
> test".  That builds two programs by the obvious names; one will test  
> the libc getaddrinfo routine, and the other tests our wrapper around  
> it.  Try running both under valgrind, giving the local host name as an  
> argument.  If valgrind reports a leak in addrinfo-test, it's very  
> likely to be a libc bug; if it only reports a problem in fake-addrinfo- 
> test, then it's MIT's bug.
>
> Ken
>
>
>   
> ------------------------------------------------------------------------
>
>
> No virus found in this incoming message.
> Checked by AVG - www.avg.com 
> Version: 9.0.698 / Virus Database: 270.14.52/2484 - Release Date: 11/06/09 07:38:00
>
>   


-- 
Dan Searle

CensorNet Ltd - professional & affordable Web & E-mail filtering
email: dan.searle at censornet.com web: www.censornet.com
tel: 0845 230 9590 / fax: 0845 230 9591 / support: 0845 230 9592
snail: Vallon House, Vantage Court Office Park, Winterbourne,
       Bristol, BS16 1GW, UK.

CensorNet Ltd is a registered company in England & Wales No. 05518629
VAT registration number 901-2048-78
Any views expressed in this email communication are those of the
individual sender, except where the sender specifically states them to
be the views of a member of Censornet Ltd.  Censornet Ltd. does not
represent, warrant or guarantee that the integrity of this
communication has been maintained nor that the communication is free
of errors or interference. 


------------------------------------------------------------------------------------
Scanned for viruses, spam and offensive content by CensorNet MailSafe

Try CensorNet free for 14 days. Provide Internet access on your terms.
Visit www.censornet.com for more information.


From raeburn at MIT.EDU  Mon Nov  9 12:19:47 2009
From: raeburn at MIT.EDU (Ken Raeburn)
Date: Mon, 9 Nov 2009 12:19:47 -0500
Subject: Memory leaks in Kerberos 5 1.6.4-beta1 and 1.7
In-Reply-To: <4AF7EA56.3030100@censornet.com>
References: <4AF44D3F.8050907@censornet.com>	<2FB6EC3B-1C70-46B4-A672-DD5AC50DA763@mit.edu>	<4AF464A8.5090403@censornet.com>
	<168B73DA-0F65-4E9E-A805-D1D28F2C52BD@mit.edu>
	<4AF7EA56.3030100@censornet.com>
Message-ID: <A1500B49-6CB3-4BDC-AF2B-92D83CC271C5@MIT.EDU>

On Nov 9, 2009, at 05:09, Dan Searle wrote:
> The version of libc6 is the latest available package in Ubuntu  
> Hardy, i.e. 2.7-10ubuntu5. Is this a libc bug or an MIT bug?

There's a workaround in the 1.7 release code for an old getaddrinfo  
bug in glibc; the workaround introduces a memory leak.  Greg put a fix  
in back in August to disable the workaround if the glibc version is  
2.4 or later, since the bug was fixed in 2.3.4.  See http://krbdev.mit.edu/rt/Ticket/Display.html?id=6534 
  and some of the comments in src/util/support/fake-addrinfo.c for  
details.  I don't think it's been added to the 1.7 branch yet, so it  
wouldn't have been in the snapshot you got.

You can get a link to the patch from the RT page, or you can try a  
snapshot from the main development trunk ("krb5-current"), if you like.

Ken

From ghudson at MIT.EDU  Tue Nov 10 11:53:18 2009
From: ghudson at MIT.EDU (Greg Hudson)
Date: Tue, 10 Nov 2009 11:53:18 -0500
Subject: Code modularity
In-Reply-To: <DD569BB0-E2D5-4244-ACE0-9DC070C43D9D@mit.edu>
References: <DD569BB0-E2D5-4244-ACE0-9DC070C43D9D@mit.edu>
Message-ID: <1257871998.30028.19.camel@equal-rites.mit.edu>

On Wed, 2009-10-28 at 11:33 -0400, Zhanna Tsitkova wrote:
> This is the initial write-up for the Code Modularity proj.

This didn't get any comments, which may mean that people didn't
understand it.  I'll try to rephrase the proposal in a different style.

Zhanna is proposing the following general plan for organizing functions
within a library:

1. We group APIs together if they are likely to be used together.  An
example might be init and free functions for the same data type, such as
krb5_c_init_state and krb5_c_free_state.

2. For every function in the library, we look at the set of API groups
which require that function in their dependency graph.

3. We put functions together in a file if they have the same set of API
groups requiring them.  Otherwise, we put them in separate files.

The payoff of this plan, as I understand it, is that every subset of API
groups will correspond to a subset of the source files within the
library.  For example, doing GSSAPI NFS in the kernel typically requires
the APIs to import a security context and wrap/unwrap messages with it,
but not the APIs to establish a context.  Currently, slicing up the
GSSAPI and krb5 modules to support that subset requires some pretty
major #ifdef surgery, but after this code modularity work, the surgery
would be limited to the build system--in theory, anyway.

One possible concern is that functions might need to move around
frequently because of external factors.  For example, if we add a new
API which uses some existing internal helper functions, a set of helpers
which previously lived together might need to be split apart (because
some of them are used by the new API and others aren't).  Such frequent
code movement could make it more difficult to look at the history of a
function's implementation.



From Nicolas.Williams at sun.com  Tue Nov 10 12:05:33 2009
From: Nicolas.Williams at sun.com (Nicolas Williams)
Date: Tue, 10 Nov 2009 11:05:33 -0600
Subject: Code modularity
In-Reply-To: <1257871998.30028.19.camel@equal-rites.mit.edu>
References: <DD569BB0-E2D5-4244-ACE0-9DC070C43D9D@mit.edu>
	<1257871998.30028.19.camel@equal-rites.mit.edu>
Message-ID: <20091110170532.GU1105@Sun.COM>

On Tue, Nov 10, 2009 at 11:53:18AM -0500, Greg Hudson wrote:
> On Wed, 2009-10-28 at 11:33 -0400, Zhanna Tsitkova wrote:
> > This is the initial write-up for the Code Modularity proj.
> 
> This didn't get any comments, which may mean that people didn't
> understand it.  I'll try to rephrase the proposal in a different style.

I hadn't seen it.  The proposal is perfectly comprehensible.

One concern: code changes, so will there be a commitment to
re-modularizing as changes are made?  Will re-modularization be a
checklist item for commiting code?  See below.

> The payoff of this plan, as I understand it, is that every subset of API
> groups will correspond to a subset of the source files within the
> library.  For example, doing GSSAPI NFS in the kernel typically requires
> the APIs to import a security context and wrap/unwrap messages with it,
> but not the APIs to establish a context.  Currently, slicing up the
> GSSAPI and krb5 modules to support that subset requires some pretty
> major #ifdef surgery, but after this code modularity work, the surgery
> would be limited to the build system--in theory, anyway.

To be fair, folks did this at Sun _long_ ago, and it wasn't that big a
deal, by the looks of it, because there was a fair bit of modularity in
MIT krb5 to begin with.  Also, I don't think #ifdefs will go away
entirely because some of them are needed in function bodies and don't
cover the entire function bodies.

If the kernel/user-land GSS split is your goal, then you might just have
an easier time making changes to match the ones in Solaris.

> One possible concern is that functions might need to move around
> frequently because of external factors.  For example, if we add a new
> API which uses some existing internal helper functions, a set of helpers
> which previously lived together might need to be split apart (because
> some of them are used by the new API and others aren't).  Such frequent
> code movement could make it more difficult to look at the history of a
> function's implementation.

Indeed.  Which then argues for a strict
one-non-static-function-per-file, or even one-function-per-file.

IMO occasional re-modularization is a good thing, but constantly doing
it is a pain, both because of history issues, and because it creates
more merge pain for vendors that have not yet gotten to the point where
they can do code drops.

Nico
-- 

From ghudson at MIT.EDU  Tue Nov 10 14:08:18 2009
From: ghudson at MIT.EDU (ghudson@MIT.EDU)
Date: Tue, 10 Nov 2009 14:08:18 -0500 (EST)
Subject: Namespaces and inter-library private symbols
Message-ID: <200911101908.nAAJ8IOj001536@outgoing.mit.edu>

I'd like to get a consensus on how we should handle library functions
which are not part of the public API but are used by other parts of
the tree.  Currently, we inconsistently do one of three things:

1. Use the accessor.  (Examples: ASN.1 encoders as used by the pkinit
module; HMAC as used by gss-krb5.)

2. Name the function krb5_foo, export it, but prototype it in k5-int.h
instead of krb5.h.  (Examples: krb5_get_cred_from_kdc as used by ksu;
krb5_free_realm_tree as used by kdc.)

3. Name the function krb5int_foo, export it, prototype it in k5-int.h,
and use it directly from the other part of the tree.  (Examples:
krb5int_cc_default as used by gss-krb5; krb5int_init_context_kdc as
used by kdc and libkadm5.)

I would like to better understand why we have the accessor and when it
should be used, if ever.  I consider it an overly heavyweight solution
to the problem.  Tom tells me that the initial justification had
something to do with Windows, but he didn't have details.

I think we have a partial consensus that (2) is bad, because those
symbols can show up as available in an autoconf test even if they
aren't part of the API in that version of Kerberos.  We've continued
to add new examples of (2) in recent work, however--examples are
krb5_c_weak_enctype (recently renamed to krb5int_c_weak enctype) and
krb5_get_credentials_for_proxy.

I would like to see us move towards using (3) uniformly.  If I receive
no feedback, I will document this as the preferred practice in
http://k5wiki.kerberos.org/wiki/Coding_style/Practices#Namespaces and
start converting cases to that form as I run into them.

A fourth option is to invent a new namespace for inter-library private
symbols, so that we can easily differentiate between "internal to this
library" and "internal to the krb5 tree."  That might result in a lot
of symbol renaming over time, though.

From Nicolas.Williams at sun.com  Tue Nov 10 15:14:57 2009
From: Nicolas.Williams at sun.com (Nicolas Williams)
Date: Tue, 10 Nov 2009 14:14:57 -0600
Subject: Namespaces and inter-library private symbols
In-Reply-To: <200911101908.nAAJ8IOj001536@outgoing.mit.edu>
References: <200911101908.nAAJ8IOj001536@outgoing.mit.edu>
Message-ID: <20091110201457.GA1105@Sun.COM>

On Tue, Nov 10, 2009 at 02:08:18PM -0500, ghudson at mit.edu wrote:
> I'd like to get a consensus on how we should handle library functions
> which are not part of the public API but are used by other parts of
> the tree.  Currently, we inconsistently do one of three things:
> 
> 1. Use the accessor.  (Examples: ASN.1 encoders as used by the pkinit
> module; HMAC as used by gss-krb5.)

I don't mind this, but it'd be nice to have a set of macros to hide the
indirection.

> 2. Name the function krb5_foo, export it, but prototype it in k5-int.h
> instead of krb5.h.  (Examples: krb5_get_cred_from_kdc as used by ksu;
> krb5_free_realm_tree as used by kdc.)

I don't mind this either.

> 3. Name the function krb5int_foo, export it, prototype it in k5-int.h,
> and use it directly from the other part of the tree.  (Examples:
> krb5int_cc_default as used by gss-krb5; krb5int_init_context_kdc as
> used by kdc and libkadm5.)

Nor this.  But I prefer (2), slightly.

> I would like to better understand why we have the accessor and when it
> should be used, if ever.  I consider it an overly heavyweight solution
> to the problem.  Tom tells me that the initial justification had
> something to do with Windows, but he didn't have details.

*shrug*.  It's not heavyweight, but, rather, a way of building your own
light-weight run-time linker.  It's... OK, not great, but there's
precedent (e.g., PKCS#11 is meant to be used in a similar way).

What you call the "accessor" approach may be particularly useful when
you might risk interposition at run-time and you want to ensure that you
don't (you dlopen() the exact object you want, dlsym() each function
from it, or a single function that outputs a pointer to a struct
containing the necessary function pointers).

> I think we have a partial consensus that (2) is bad, because those
> symbols can show up as available in an autoconf test even if they
> aren't part of the API in that version of Kerberos.  We've continued
> to add new examples of (2) in recent work, however--examples are
> krb5_c_weak_enctype (recently renamed to krb5int_c_weak enctype) and
> krb5_get_credentials_for_proxy.

I don't think (2) is bad.  Here's why: you must export symbols as far as
the _linker_ goes, no matter which of (1), (2), or (3) you pick, and in
_all_ cases you depend on a private header to obtain access to the
necessary C function prototype declarations -- (2) fits the bill with
minimal impact on the existing source.

The prefix that indicates "internal" is somewhat useful -- you know
instantly by looking at a function if it's internal -- but, what is
"internal"?  Internal to a single library?  To all of MIT krb5?  To
third-party code that has an "interface contract" with MIT krb5?  How
many prefixes do you actually need?

> I would like to see us move towards using (3) uniformly.  If I receive
> no feedback, I will document this as the preferred practice in
> http://k5wiki.kerberos.org/wiki/Coding_style/Practices#Namespaces and
> start converting cases to that form as I run into them.

Certainly having a single style adopted uniformly would be good.

> A fourth option is to invent a new namespace for inter-library private
> symbols, so that we can easily differentiate between "internal to this
> library" and "internal to the krb5 tree."  That might result in a lot
> of symbol renaming over time, though.

You can't invent a new namespace, only a new naming convention.  I
recommend against it.  I recommend that you concentrate efforts on
actual, useful features and bug fixes over mass symbol rename
excercises.

Nico
-- 

From tlyu at MIT.EDU  Tue Nov 10 15:53:24 2009
From: tlyu at MIT.EDU (Tom Yu)
Date: Tue, 10 Nov 2009 15:53:24 -0500
Subject: Namespaces and inter-library private symbols
In-Reply-To: <200911101908.nAAJ8IOj001536@outgoing.mit.edu> (ghudson@MIT.EDU's
	message of "Tue, 10 Nov 2009 14:08:18 -0500")
References: <200911101908.nAAJ8IOj001536@outgoing.mit.edu>
Message-ID: <ldvtyx29k57.fsf@cathode-dark-space.mit.edu>

"ghudson at MIT.EDU" <ghudson at MIT.EDU> writes:

> I'd like to get a consensus on how we should handle library functions
> which are not part of the public API but are used by other parts of
> the tree.  Currently, we inconsistently do one of three things:
>
> 1. Use the accessor.  (Examples: ASN.1 encoders as used by the pkinit
> module; HMAC as used by gss-krb5.)
>
> 2. Name the function krb5_foo, export it, but prototype it in k5-int.h
> instead of krb5.h.  (Examples: krb5_get_cred_from_kdc as used by ksu;
> krb5_free_realm_tree as used by kdc.)

Some of these may have been prototyped in krb5.h at some point in the
past, and then moved to k5-int.h.  If that is true, we should avoid
renaming them, in order to preserve ABI compatibility.

From Nicolas.Williams at sun.com  Tue Nov 10 16:48:55 2009
From: Nicolas.Williams at sun.com (Nicolas Williams)
Date: Tue, 10 Nov 2009 15:48:55 -0600
Subject: Namespaces and inter-library private symbols
In-Reply-To: <200911101908.nAAJ8IOj001536@outgoing.mit.edu>
References: <200911101908.nAAJ8IOj001536@outgoing.mit.edu>
Message-ID: <20091110214855.GI1105@Sun.COM>

On Tue, Nov 10, 2009 at 02:08:18PM -0500, ghudson at mit.edu wrote:
> I would like to better understand why we have the accessor and when it
> should be used, if ever.  I consider it an overly heavyweight solution
> to the problem.  Tom tells me that the initial justification had
> something to do with Windows, but he didn't have details.

Ah, I bet the accessor is for pre-auth plugins / plugins in general, to
help avoid DLL hell.  I think this is best kept separate.

So we're really just talking about naming conventions for non-public
interfaces.  My preference is to not have a separate naming convention
for pubic vs. private symbols.

Vendors should just not ship k5-int.h and that's that.  Developers
should have enough warning from the fact that they cannot find C
prototype declarations for functions that they think might be useful to
them but which ware internal.

Nico
-- 

From dan.searle at censornet.com  Wed Nov 11 08:57:01 2009
From: dan.searle at censornet.com (Dan Searle)
Date: Wed, 11 Nov 2009 13:57:01 +0000
Subject: More memory leaks (1.6.4-beta1 release)
Message-ID: <4AFAC2AD.5090505@censornet.com>

Hi,

I've been debugging the squid_kerb_auth helper some more and have found 
yet more memory leaks. I missed these last round because I didn't take 
into account (ignored) the still reachable blocks (malloced blocks which 
still have valid pointers).

I've ignores the instances (loss records) with just 1 block or what seem 
to be a "fixed" number of still reachable blocks, i.e. I've only 
included here the loss records which seem to scale with the number of 
iterations the authentication helper goes through, and so are a threat 
to a running process...

==5314== 372 bytes in 31 blocks are still reachable in loss record 76 of 82
==5314==    at 0x4022AB8: malloc (vg_replace_malloc.c:207)
==5314==    by 0x4032BE5: gssint_g_set_entry_add (util_set.c:61)
==5314==    by 0x4033B1B: g_save (util_validate.c:114)
==5314==    by 0x404097A: krb5_gss_acquire_cred (acquire_cred.c:645)
==5314==    by 0x403D23F: krb5_gss_accept_sec_context 
(accept_sec_context.c:302)
==5314==    by 0x404B192: k5glue_accept_sec_context (krb5_gss_glue.c:434)
==5314==    by 0x4034178: gss_accept_sec_context 
(g_accept_sec_context.c:196)
==5314==    by 0x40510A7: spnego_gss_accept_sec_context (spnego_mech.c:1113)
==5314==    by 0x4034178: gss_accept_sec_context 
(g_accept_sec_context.c:196)
==5314==    by 0x8049C91: main (squid_kerb_auth.c:515)

==5314== 372 bytes in 31 blocks are still reachable in loss record 77 of 82
==5314==    at 0x4022AB8: malloc (vg_replace_malloc.c:207)
==5314==    by 0x40A006A: krb5_ktfile_resolve (kt_file.c:207)
==5314==    by 0x409D900: krb5_kt_resolve (ktbase.c:129)
==5314==    by 0x409DB38: krb5_kt_default (ktdefault.c:41)
==5314==    by 0x4041EC1: krb5_gss_acquire_cred (acquire_cred.c:171)
==5314==    by 0x403D23F: krb5_gss_accept_sec_context 
(accept_sec_context.c:302)
==5314==    by 0x404B192: k5glue_accept_sec_context (krb5_gss_glue.c:434)
==5314==    by 0x4034178: gss_accept_sec_context 
(g_accept_sec_context.c:196)
==5314==    by 0x40510A7: spnego_gss_accept_sec_context (spnego_mech.c:1113)
==5314==    by 0x4034178: gss_accept_sec_context 
(g_accept_sec_context.c:196)
==5314==    by 0x8049C91: main (squid_kerb_auth.c:515)

==5314== 527 bytes in 31 blocks are still reachable in loss record 78 of 82
==5314==    at 0x4021BDE: calloc (vg_replace_malloc.c:397)
==5314==    by 0x40A013A: krb5_ktfile_resolve (kt_file.c:223)
==5314==    by 0x409D900: krb5_kt_resolve (ktbase.c:129)
==5314==    by 0x409DB38: krb5_kt_default (ktdefault.c:41)
==5314==    by 0x4041EC1: krb5_gss_acquire_cred (acquire_cred.c:171)
==5314==    by 0x403D23F: krb5_gss_accept_sec_context 
(accept_sec_context.c:302)
==5314==    by 0x404B192: k5glue_accept_sec_context (krb5_gss_glue.c:434)
==5314==    by 0x4034178: gss_accept_sec_context 
(g_accept_sec_context.c:196)
==5314==    by 0x40510A7: spnego_gss_accept_sec_context (spnego_mech.c:1113)
==5314==    by 0x4034178: gss_accept_sec_context 
(g_accept_sec_context.c:196)
==5314==    by 0x8049C91: main (squid_kerb_auth.c:515)

==5314== 2,852 bytes in 31 blocks are still reachable in loss record 81 
of 82
==5314==    at 0x4022AB8: malloc (vg_replace_malloc.c:207)
==5314==    by 0x403F3C4: krb5_gss_acquire_cred (acquire_cred.c:497)
==5314==    by 0x403D23F: krb5_gss_accept_sec_context 
(accept_sec_context.c:302)
==5314==    by 0x404B192: k5glue_accept_sec_context (krb5_gss_glue.c:434)
==5314==    by 0x4034178: gss_accept_sec_context 
(g_accept_sec_context.c:196)
==5314==    by 0x40510A7: spnego_gss_accept_sec_context (spnego_mech.c:1113)
==5314==    by 0x4034178: gss_accept_sec_context 
(g_accept_sec_context.c:196)
==5314==    by 0x8049C91: main (squid_kerb_auth.c:515)

==5314== 256,308 bytes in 31 blocks are still reachable in loss record 
82 of 82
==5314==    at 0x4022AB8: malloc (vg_replace_malloc.c:207)
==5314==    by 0x40A008A: krb5_ktfile_resolve (kt_file.c:211)
==5314==    by 0x409D900: krb5_kt_resolve (ktbase.c:129)
==5314==    by 0x409DB38: krb5_kt_default (ktdefault.c:41)
==5314==    by 0x4041EC1: krb5_gss_acquire_cred (acquire_cred.c:171)
==5314==    by 0x403D23F: krb5_gss_accept_sec_context 
(accept_sec_context.c:302)
==5314==    by 0x404B192: k5glue_accept_sec_context (krb5_gss_glue.c:434)
==5314==    by 0x4034178: gss_accept_sec_context 
(g_accept_sec_context.c:196)
==5314==    by 0x40510A7: spnego_gss_accept_sec_context (spnego_mech.c:1113)
==5314==    by 0x4034178: gss_accept_sec_context 
(g_accept_sec_context.c:196)
==5314==    by 0x8049C91: main (squid_kerb_auth.c:515)

I've also debugged the squid_kerb_auth helper code and made sure it 
matches calls to gss_accept_sec_context() with calls to 
gss_delete_sec_context() which it does. So these still reachable leaks 
do appear to be bugs in the MIT Kerberos libs.

Can anyone shed any light on these? as they are making MIT Kerberos 
unusable. Regards, Dan...

-- 
Dan Searle

CensorNet Ltd - professional & affordable Web & E-mail filtering
email: dan.searle at censornet.com web: www.censornet.com
tel: 0845 230 9590 / fax: 0845 230 9591 / support: 0845 230 9592
snail: Vallon House, Vantage Court Office Park, Winterbourne,
       Bristol, BS16 1GW, UK.

CensorNet Ltd is a registered company in England & Wales No. 05518629
VAT registration number 901-2048-78
Any views expressed in this email communication are those of the
individual sender, except where the sender specifically states them to
be the views of a member of Censornet Ltd.  Censornet Ltd. does not
represent, warrant or guarantee that the integrity of this
communication has been maintained nor that the communication is free
of errors or interference. 


------------------------------------------------------------------------------------
Scanned for viruses, spam and offensive content by CensorNet MailSafe

Try CensorNet free for 14 days. Provide Internet access on your terms.
Visit www.censornet.com for more information.


From mdw at umich.edu  Wed Nov 11 12:00:17 2009
From: mdw at umich.edu (Marcus Watts)
Date: Wed, 11 Nov 2009 12:00:17 -0500
Subject: More memory leaks (1.6.4-beta1 release) 
In-Reply-To: <4AFAC2AD.5090505@censornet.com> 
References: <4AFAC2AD.5090505@censornet.com>
Message-ID: <E1N8GYL-0005yn-Kd@bruson.ifs.umich.edu>

> Date:    Wed, 11 Nov 2009 13:57:01 GMT
> To:      krbdev at mit.edu
> From:    Dan Searle <dan.searle at censornet.com>
> Subject: More memory leaks (1.6.4-beta1 release)
> 
> Hi,
> 
> I've been debugging the squid_kerb_auth helper some more and have found 
> yet more memory leaks. I missed these last round because I didn't take 
> into account (ignored) the still reachable blocks (malloced blocks which 
> still have valid pointers).
> 
> I've ignores the instances (loss records) with just 1 block or what seem 
> to be a "fixed" number of still reachable blocks, i.e. I've only 
> included here the loss records which seem to scale with the number of 
> iterations the authentication helper goes through, and so are a threat 
> to a running process...
> 
> ==5314== 372 bytes in 31 blocks are still reachable in loss record 76 of 82
> ==5314==    at 0x4022AB8: malloc (vg_replace_malloc.c:207)
> ==5314==    by 0x4032BE5: gssint_g_set_entry_add (util_set.c:61)
> ==5314==    by 0x4033B1B: g_save (util_validate.c:114)
> ==5314==    by 0x404097A: krb5_gss_acquire_cred (acquire_cred.c:645)
> ==5314==    by 0x403D23F: krb5_gss_accept_sec_context 
> (accept_sec_context.c:302)
> ==5314==    by 0x404B192: k5glue_accept_sec_context (krb5_gss_glue.c:434)
> ==5314==    by 0x4034178: gss_accept_sec_context 
> (g_accept_sec_context.c:196)
> ==5314==    by 0x40510A7: spnego_gss_accept_sec_context (spnego_mech.c:1113)
> ==5314==    by 0x4034178: gss_accept_sec_context 
> (g_accept_sec_context.c:196)
> ==5314==    by 0x8049C91: main (squid_kerb_auth.c:515)
> 
> ==5314== 372 bytes in 31 blocks are still reachable in loss record 77 of 82
> ==5314==    at 0x4022AB8: malloc (vg_replace_malloc.c:207)
> ==5314==    by 0x40A006A: krb5_ktfile_resolve (kt_file.c:207)
> ==5314==    by 0x409D900: krb5_kt_resolve (ktbase.c:129)
> ==5314==    by 0x409DB38: krb5_kt_default (ktdefault.c:41)
> ==5314==    by 0x4041EC1: krb5_gss_acquire_cred (acquire_cred.c:171)
> ==5314==    by 0x403D23F: krb5_gss_accept_sec_context 
> (accept_sec_context.c:302)
> ==5314==    by 0x404B192: k5glue_accept_sec_context (krb5_gss_glue.c:434)
> ==5314==    by 0x4034178: gss_accept_sec_context 
> (g_accept_sec_context.c:196)
> ==5314==    by 0x40510A7: spnego_gss_accept_sec_context (spnego_mech.c:1113)
> ==5314==    by 0x4034178: gss_accept_sec_context 
> (g_accept_sec_context.c:196)
> ==5314==    by 0x8049C91: main (squid_kerb_auth.c:515)
> 
> ==5314== 527 bytes in 31 blocks are still reachable in loss record 78 of 82
> ==5314==    at 0x4021BDE: calloc (vg_replace_malloc.c:397)
> ==5314==    by 0x40A013A: krb5_ktfile_resolve (kt_file.c:223)
> ==5314==    by 0x409D900: krb5_kt_resolve (ktbase.c:129)
> ==5314==    by 0x409DB38: krb5_kt_default (ktdefault.c:41)
> ==5314==    by 0x4041EC1: krb5_gss_acquire_cred (acquire_cred.c:171)
> ==5314==    by 0x403D23F: krb5_gss_accept_sec_context 
> (accept_sec_context.c:302)
> ==5314==    by 0x404B192: k5glue_accept_sec_context (krb5_gss_glue.c:434)
> ==5314==    by 0x4034178: gss_accept_sec_context 
> (g_accept_sec_context.c:196)
> ==5314==    by 0x40510A7: spnego_gss_accept_sec_context (spnego_mech.c:1113)
> ==5314==    by 0x4034178: gss_accept_sec_context 
> (g_accept_sec_context.c:196)
> ==5314==    by 0x8049C91: main (squid_kerb_auth.c:515)
> 
> ==5314== 2,852 bytes in 31 blocks are still reachable in loss record 81 
> of 82
> ==5314==    at 0x4022AB8: malloc (vg_replace_malloc.c:207)
> ==5314==    by 0x403F3C4: krb5_gss_acquire_cred (acquire_cred.c:497)
> ==5314==    by 0x403D23F: krb5_gss_accept_sec_context 
> (accept_sec_context.c:302)
> ==5314==    by 0x404B192: k5glue_accept_sec_context (krb5_gss_glue.c:434)
> ==5314==    by 0x4034178: gss_accept_sec_context 
> (g_accept_sec_context.c:196)
> ==5314==    by 0x40510A7: spnego_gss_accept_sec_context (spnego_mech.c:1113)
> ==5314==    by 0x4034178: gss_accept_sec_context 
> (g_accept_sec_context.c:196)
> ==5314==    by 0x8049C91: main (squid_kerb_auth.c:515)
> 
> ==5314== 256,308 bytes in 31 blocks are still reachable in loss record 
> 82 of 82
> ==5314==    at 0x4022AB8: malloc (vg_replace_malloc.c:207)
> ==5314==    by 0x40A008A: krb5_ktfile_resolve (kt_file.c:211)
> ==5314==    by 0x409D900: krb5_kt_resolve (ktbase.c:129)
> ==5314==    by 0x409DB38: krb5_kt_default (ktdefault.c:41)
> ==5314==    by 0x4041EC1: krb5_gss_acquire_cred (acquire_cred.c:171)
> ==5314==    by 0x403D23F: krb5_gss_accept_sec_context 
> (accept_sec_context.c:302)
> ==5314==    by 0x404B192: k5glue_accept_sec_context (krb5_gss_glue.c:434)
> ==5314==    by 0x4034178: gss_accept_sec_context 
> (g_accept_sec_context.c:196)
> ==5314==    by 0x40510A7: spnego_gss_accept_sec_context (spnego_mech.c:1113)
> ==5314==    by 0x4034178: gss_accept_sec_context 
> (g_accept_sec_context.c:196)
> ==5314==    by 0x8049C91: main (squid_kerb_auth.c:515)
> 
> I've also debugged the squid_kerb_auth helper code and made sure it 
> matches calls to gss_accept_sec_context() with calls to 
> gss_delete_sec_context() which it does. So these still reachable leaks 
> do appear to be bugs in the MIT Kerberos libs.
> 
> Can anyone shed any light on these? as they are making MIT Kerberos 
> unusable. Regards, Dan...
> 
> -- 
> Dan Searle
> 
> CensorNet Ltd - professional & affordable Web & E-mail filtering
> email: dan.searle at censornet.com web: www.censornet.com
> tel: 0845 230 9590 / fax: 0845 230 9591 / support: 0845 230 9592
> snail: Vallon House, Vantage Court Office Park, Winterbourne,
>        Bristol, BS16 1GW, UK.
> 
> CensorNet Ltd is a registered company in England & Wales No. 05518629
> VAT registration number 901-2048-78
> Any views expressed in this email communication are those of the
> individual sender, except where the sender specifically states them to
> be the views of a member of Censornet Ltd.  Censornet Ltd. does not
> represent, warrant or guarantee that the integrity of this
> communication has been maintained nor that the communication is free
> of errors or interference. 
> 
> 
> -------------------------------------------------------------------------------
> -----
> Scanned for viruses, spam and offensive content by CensorNet MailSafe
> 
> Try CensorNet free for 14 days. Provide Internet access on your terms.
> Visit www.censornet.com for more information.
> 
> _______________________________________________
> krbdev mailing list             krbdev at mit.edu
> https://mailman.mit.edu/mailman/listinfo/krbdev

Presumably your iteration count in this sample was 31.
3 of your 5 loss records are associated with calls to
krb5_ktfile_resolve.  Calls to krb5_ktfile_resolve/krb5_kt_default
should be balanced with calls to krb5_ktfile_close.
The relevant logic is in krb5/src/lib/gssapi/krb5/acquire_cred.c
so that's presumably where the missing krb5_ktfile_close call ought
to be.

Both your remaining loss records are directly from gssapi.
specifically krb5_gss_acquire_cred.  It looks like calls to that
should be paired up with calls to krb5_gss_release_cred.
That could happen at the end of krb5_gss_accept_sec_context
if verifier_cred_handle is passed as 0, otherwise, it looks like
the application (squid?) should be responsible.  Presumably the
squid code should actually be calling gss_release_cred.
It's possible there's a bug here in the MIT code, but it would be
useful to first establish the credential isn't in fact being
passed out to squid.

					-Marcus Watts

From huaraz at moeller.plus.com  Wed Nov 11 16:04:22 2009
From: huaraz at moeller.plus.com (Markus Moeller)
Date: Wed, 11 Nov 2009 21:04:22 -0000
Subject: More memory leaks (1.6.4-beta1 release)
In-Reply-To: <E1N8GYL-0005yn-Kd@bruson.ifs.umich.edu>
References: <4AFAC2AD.5090505@censornet.com>
	<E1N8GYL-0005yn-Kd@bruson.ifs.umich.edu>
Message-ID: <hdf8sr$5ua$1@ger.gmane.org>


"Marcus Watts" <mdw at umich.edu> wrote in message 
news:E1N8GYL-0005yn-Kd at bruson.ifs.umich.edu...
>> Date:    Wed, 11 Nov 2009 13:57:01 GMT
>> To:      krbdev at mit.edu
>> From:    Dan Searle <dan.searle at censornet.com>
>> Subject: More memory leaks (1.6.4-beta1 release)
>>
>> Hi,
>>
>> I've been debugging the squid_kerb_auth helper some more and have found
>> yet more memory leaks. I missed these last round because I didn't take
>> into account (ignored) the still reachable blocks (malloced blocks which
>> still have valid pointers).
>>
>> I've ignores the instances (loss records) with just 1 block or what seem
>> to be a "fixed" number of still reachable blocks, i.e. I've only
>> included here the loss records which seem to scale with the number of
>> iterations the authentication helper goes through, and so are a threat
>> to a running process...
>>
>> ==5314== 372 bytes in 31 blocks are still reachable in loss record 76 of 
>> 82
>> ==5314==    at 0x4022AB8: malloc (vg_replace_malloc.c:207)
>> ==5314==    by 0x4032BE5: gssint_g_set_entry_add (util_set.c:61)
>> ==5314==    by 0x4033B1B: g_save (util_validate.c:114)
>> ==5314==    by 0x404097A: krb5_gss_acquire_cred (acquire_cred.c:645)
>> ==5314==    by 0x403D23F: krb5_gss_accept_sec_context
>> (accept_sec_context.c:302)
>> ==5314==    by 0x404B192: k5glue_accept_sec_context (krb5_gss_glue.c:434)
>> ==5314==    by 0x4034178: gss_accept_sec_context
>> (g_accept_sec_context.c:196)
>> ==5314==    by 0x40510A7: spnego_gss_accept_sec_context 
>> (spnego_mech.c:1113)
>> ==5314==    by 0x4034178: gss_accept_sec_context
>> (g_accept_sec_context.c:196)
>> ==5314==    by 0x8049C91: main (squid_kerb_auth.c:515)
>>
>> ==5314== 372 bytes in 31 blocks are still reachable in loss record 77 of 
>> 82
>> ==5314==    at 0x4022AB8: malloc (vg_replace_malloc.c:207)
>> ==5314==    by 0x40A006A: krb5_ktfile_resolve (kt_file.c:207)
>> ==5314==    by 0x409D900: krb5_kt_resolve (ktbase.c:129)
>> ==5314==    by 0x409DB38: krb5_kt_default (ktdefault.c:41)
>> ==5314==    by 0x4041EC1: krb5_gss_acquire_cred (acquire_cred.c:171)
>> ==5314==    by 0x403D23F: krb5_gss_accept_sec_context
>> (accept_sec_context.c:302)
>> ==5314==    by 0x404B192: k5glue_accept_sec_context (krb5_gss_glue.c:434)
>> ==5314==    by 0x4034178: gss_accept_sec_context
>> (g_accept_sec_context.c:196)
>> ==5314==    by 0x40510A7: spnego_gss_accept_sec_context 
>> (spnego_mech.c:1113)
>> ==5314==    by 0x4034178: gss_accept_sec_context
>> (g_accept_sec_context.c:196)
>> ==5314==    by 0x8049C91: main (squid_kerb_auth.c:515)
>>
>> ==5314== 527 bytes in 31 blocks are still reachable in loss record 78 of 
>> 82
>> ==5314==    at 0x4021BDE: calloc (vg_replace_malloc.c:397)
>> ==5314==    by 0x40A013A: krb5_ktfile_resolve (kt_file.c:223)
>> ==5314==    by 0x409D900: krb5_kt_resolve (ktbase.c:129)
>> ==5314==    by 0x409DB38: krb5_kt_default (ktdefault.c:41)
>> ==5314==    by 0x4041EC1: krb5_gss_acquire_cred (acquire_cred.c:171)
>> ==5314==    by 0x403D23F: krb5_gss_accept_sec_context
>> (accept_sec_context.c:302)
>> ==5314==    by 0x404B192: k5glue_accept_sec_context (krb5_gss_glue.c:434)
>> ==5314==    by 0x4034178: gss_accept_sec_context
>> (g_accept_sec_context.c:196)
>> ==5314==    by 0x40510A7: spnego_gss_accept_sec_context 
>> (spnego_mech.c:1113)
>> ==5314==    by 0x4034178: gss_accept_sec_context
>> (g_accept_sec_context.c:196)
>> ==5314==    by 0x8049C91: main (squid_kerb_auth.c:515)
>>
>> ==5314== 2,852 bytes in 31 blocks are still reachable in loss record 81
>> of 82
>> ==5314==    at 0x4022AB8: malloc (vg_replace_malloc.c:207)
>> ==5314==    by 0x403F3C4: krb5_gss_acquire_cred (acquire_cred.c:497)
>> ==5314==    by 0x403D23F: krb5_gss_accept_sec_context
>> (accept_sec_context.c:302)
>> ==5314==    by 0x404B192: k5glue_accept_sec_context (krb5_gss_glue.c:434)
>> ==5314==    by 0x4034178: gss_accept_sec_context
>> (g_accept_sec_context.c:196)
>> ==5314==    by 0x40510A7: spnego_gss_accept_sec_context 
>> (spnego_mech.c:1113)
>> ==5314==    by 0x4034178: gss_accept_sec_context
>> (g_accept_sec_context.c:196)
>> ==5314==    by 0x8049C91: main (squid_kerb_auth.c:515)
>>
>> ==5314== 256,308 bytes in 31 blocks are still reachable in loss record
>> 82 of 82
>> ==5314==    at 0x4022AB8: malloc (vg_replace_malloc.c:207)
>> ==5314==    by 0x40A008A: krb5_ktfile_resolve (kt_file.c:211)
>> ==5314==    by 0x409D900: krb5_kt_resolve (ktbase.c:129)
>> ==5314==    by 0x409DB38: krb5_kt_default (ktdefault.c:41)
>> ==5314==    by 0x4041EC1: krb5_gss_acquire_cred (acquire_cred.c:171)
>> ==5314==    by 0x403D23F: krb5_gss_accept_sec_context
>> (accept_sec_context.c:302)
>> ==5314==    by 0x404B192: k5glue_accept_sec_context (krb5_gss_glue.c:434)
>> ==5314==    by 0x4034178: gss_accept_sec_context
>> (g_accept_sec_context.c:196)
>> ==5314==    by 0x40510A7: spnego_gss_accept_sec_context 
>> (spnego_mech.c:1113)
>> ==5314==    by 0x4034178: gss_accept_sec_context
>> (g_accept_sec_context.c:196)
>> ==5314==    by 0x8049C91: main (squid_kerb_auth.c:515)
>>
>> I've also debugged the squid_kerb_auth helper code and made sure it
>> matches calls to gss_accept_sec_context() with calls to
>> gss_delete_sec_context() which it does. So these still reachable leaks
>> do appear to be bugs in the MIT Kerberos libs.
>>
>> Can anyone shed any light on these? as they are making MIT Kerberos
>> unusable. Regards, Dan...
>>
>> -- 
>> Dan Searle
>>
>> CensorNet Ltd - professional & affordable Web & E-mail filtering
>> email: dan.searle at censornet.com web: www.censornet.com
>> tel: 0845 230 9590 / fax: 0845 230 9591 / support: 0845 230 9592
>> snail: Vallon House, Vantage Court Office Park, Winterbourne,
>>        Bristol, BS16 1GW, UK.
>>
>> CensorNet Ltd is a registered company in England & Wales No. 05518629
>> VAT registration number 901-2048-78
>> Any views expressed in this email communication are those of the
>> individual sender, except where the sender specifically states them to
>> be the views of a member of Censornet Ltd.  Censornet Ltd. does not
>> represent, warrant or guarantee that the integrity of this
>> communication has been maintained nor that the communication is free
>> of errors or interference.
>>
>>
>> -------------------------------------------------------------------------------
>> -----
>> Scanned for viruses, spam and offensive content by CensorNet MailSafe
>>
>> Try CensorNet free for 14 days. Provide Internet access on your terms.
>> Visit www.censornet.com for more information.
>>
>> _______________________________________________
>> krbdev mailing list             krbdev at mit.edu
>> https://mailman.mit.edu/mailman/listinfo/krbdev
>
> Presumably your iteration count in this sample was 31.
> 3 of your 5 loss records are associated with calls to
> krb5_ktfile_resolve.  Calls to krb5_ktfile_resolve/krb5_kt_default
> should be balanced with calls to krb5_ktfile_close.
> The relevant logic is in krb5/src/lib/gssapi/krb5/acquire_cred.c
> so that's presumably where the missing krb5_ktfile_close call ought
> to be.
>
> Both your remaining loss records are directly from gssapi.
> specifically krb5_gss_acquire_cred.  It looks like calls to that
> should be paired up with calls to krb5_gss_release_cred.
> That could happen at the end of krb5_gss_accept_sec_context
> if verifier_cred_handle is passed as 0, otherwise, it looks like
> the application (squid?) should be responsible.

This is a standalone application. All interaction with squid is via stdin 
(base64 encoded token) and stdout.

> Presumably the
> squid code should actually be calling gss_release_cred.
> It's possible there's a bug here in the MIT code, but it would be
> useful to first establish the credential isn't in fact being
> passed out to squid.
>

I tested in the past several MIT/Heimdal versions on different Linux 
distributions. Some distribution have fixed MIT memory leaks others haven't. 
I think my squid_kerb_auth code is correct in freeing allocated memory (at 
least i have seen one or two Linux distributions e.g. centos which don't 
show leaks)

> -Marcus Watts
> _______________________________________________
> krbdev mailing list             krbdev at mit.edu
> https://mailman.mit.edu/mailman/listinfo/krbdev
>
Regards
Markus 



From jaltman at secure-endpoints.com  Wed Nov 11 22:11:55 2009
From: jaltman at secure-endpoints.com (Jeffrey Altman)
Date: Wed, 11 Nov 2009 22:11:55 -0500
Subject: Namespaces and inter-library private symbols
In-Reply-To: <200911101908.nAAJ8IOj001536@outgoing.mit.edu>
References: <200911101908.nAAJ8IOj001536@outgoing.mit.edu>
Message-ID: <4AFB7CFB.8040104@secure-endpoints.com>

ghudson at mit.edu wrote:

> I would like to better understand why we have the accessors and when it
> should be used, if ever.  I consider it an overly heavyweight solution
> to the problem.  Tom tells me that the initial justification had
> something to do with Windows, but he didn't have details.

I don't remember the introduction of the accessors as having anything to
do with Windows in particular.  The problem was the pollution of the
export name space from shared libraries and the desire to be able to
change the names and parameters of truly internal private functions that
must be used by gssapi without being forced to change the signature of
the of the library.

Symbols that are exported by libraries are inevitably used even when
they are declared private.  The only way to ensure that third parties do
not place dependencies on a function is to not export it.

Jeffrey Altman
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3368 bytes
Desc: S/MIME Cryptographic Signature
Url : http://mailman.mit.edu/pipermail/krbdev/attachments/20091111/774f758d/smime.bin

From hartmans at MIT.EDU  Thu Nov 12 03:38:01 2009
From: hartmans at MIT.EDU (Sam Hartman)
Date: Thu, 12 Nov 2009 03:38:01 -0500
Subject: Namespaces and inter-library private symbols
In-Reply-To: <ldvtyx29k57.fsf@cathode-dark-space.mit.edu> (Tom Yu's message of
	"Tue\, 10 Nov 2009 15\:53\:24 -0500")
References: <200911101908.nAAJ8IOj001536@outgoing.mit.edu>
	<ldvtyx29k57.fsf@cathode-dark-space.mit.edu>
Message-ID: <tslskck9lzq.fsf@mit.edu>

>>>>> "Tom" == Tom Yu <tlyu at MIT.EDU> writes:

    Tom> Some of these may have been prototyped in krb5.h at some
    Tom> point in the past, and then moved to k5-int.h.  If that is
    Tom> true, we should avoid renaming them, in order to preserve ABI
    Tom> compatibility.


I strongly disagree.
We defined a stable public ABI with 1.2.5.
Any symbol not part of that ABI should be renamed if it is changed and probably should be renamed anyway.

See my feedback from Samba; they would prefer that if things are removed from krb5.h they be renamed.
(Note all these symbols are presumably under KRB5_PRIVATE)

From dan.searle at censornet.com  Thu Nov 12 04:50:00 2009
From: dan.searle at censornet.com (Dan Searle)
Date: Thu, 12 Nov 2009 09:50:00 +0000
Subject: More memory leaks (1.6.4-beta1 release)
In-Reply-To: <hdf8sr$5ua$1@ger.gmane.org>
References: <4AFAC2AD.5090505@censornet.com>	<E1N8GYL-0005yn-Kd@bruson.ifs.umich.edu>
	<hdf8sr$5ua$1@ger.gmane.org>
Message-ID: <4AFBDA48.2000402@censornet.com>

Hi,

Since you say CentOS has a version of MIT Kerberos 5 which shows no 
leaks, can you provide me with a link to their source code or be more 
specific about which version of CentOS you were testing? I really need a 
solution to this problem very quickly. I've tried to find CentOS's RPM's 
for MIT's Kerberos but have so far failed.
Dan...

Markus Moeller wrote:
> "Marcus Watts" <mdw at umich.edu> wrote in message 
> news:E1N8GYL-0005yn-Kd at bruson.ifs.umich.edu...
>   
>>> Date:    Wed, 11 Nov 2009 13:57:01 GMT
>>> To:      krbdev at mit.edu
>>> From:    Dan Searle <dan.searle at censornet.com>
>>> Subject: More memory leaks (1.6.4-beta1 release)
>>>
>>> Hi,
>>>
>>> I've been debugging the squid_kerb_auth helper some more and have found
>>> yet more memory leaks. I missed these last round because I didn't take
>>> into account (ignored) the still reachable blocks (malloced blocks which
>>> still have valid pointers).
>>>
>>> I've ignores the instances (loss records) with just 1 block or what seem
>>> to be a "fixed" number of still reachable blocks, i.e. I've only
>>> included here the loss records which seem to scale with the number of
>>> iterations the authentication helper goes through, and so are a threat
>>> to a running process...
>>>
>>> ==5314== 372 bytes in 31 blocks are still reachable in loss record 76 of 
>>> 82
>>> ==5314==    at 0x4022AB8: malloc (vg_replace_malloc.c:207)
>>> ==5314==    by 0x4032BE5: gssint_g_set_entry_add (util_set.c:61)
>>> ==5314==    by 0x4033B1B: g_save (util_validate.c:114)
>>> ==5314==    by 0x404097A: krb5_gss_acquire_cred (acquire_cred.c:645)
>>> ==5314==    by 0x403D23F: krb5_gss_accept_sec_context
>>> (accept_sec_context.c:302)
>>> ==5314==    by 0x404B192: k5glue_accept_sec_context (krb5_gss_glue.c:434)
>>> ==5314==    by 0x4034178: gss_accept_sec_context
>>> (g_accept_sec_context.c:196)
>>> ==5314==    by 0x40510A7: spnego_gss_accept_sec_context 
>>> (spnego_mech.c:1113)
>>> ==5314==    by 0x4034178: gss_accept_sec_context
>>> (g_accept_sec_context.c:196)
>>> ==5314==    by 0x8049C91: main (squid_kerb_auth.c:515)
>>>
>>> ==5314== 372 bytes in 31 blocks are still reachable in loss record 77 of 
>>> 82
>>> ==5314==    at 0x4022AB8: malloc (vg_replace_malloc.c:207)
>>> ==5314==    by 0x40A006A: krb5_ktfile_resolve (kt_file.c:207)
>>> ==5314==    by 0x409D900: krb5_kt_resolve (ktbase.c:129)
>>> ==5314==    by 0x409DB38: krb5_kt_default (ktdefault.c:41)
>>> ==5314==    by 0x4041EC1: krb5_gss_acquire_cred (acquire_cred.c:171)
>>> ==5314==    by 0x403D23F: krb5_gss_accept_sec_context
>>> (accept_sec_context.c:302)
>>> ==5314==    by 0x404B192: k5glue_accept_sec_context (krb5_gss_glue.c:434)
>>> ==5314==    by 0x4034178: gss_accept_sec_context
>>> (g_accept_sec_context.c:196)
>>> ==5314==    by 0x40510A7: spnego_gss_accept_sec_context 
>>> (spnego_mech.c:1113)
>>> ==5314==    by 0x4034178: gss_accept_sec_context
>>> (g_accept_sec_context.c:196)
>>> ==5314==    by 0x8049C91: main (squid_kerb_auth.c:515)
>>>
>>> ==5314== 527 bytes in 31 blocks are still reachable in loss record 78 of 
>>> 82
>>> ==5314==    at 0x4021BDE: calloc (vg_replace_malloc.c:397)
>>> ==5314==    by 0x40A013A: krb5_ktfile_resolve (kt_file.c:223)
>>> ==5314==    by 0x409D900: krb5_kt_resolve (ktbase.c:129)
>>> ==5314==    by 0x409DB38: krb5_kt_default (ktdefault.c:41)
>>> ==5314==    by 0x4041EC1: krb5_gss_acquire_cred (acquire_cred.c:171)
>>> ==5314==    by 0x403D23F: krb5_gss_accept_sec_context
>>> (accept_sec_context.c:302)
>>> ==5314==    by 0x404B192: k5glue_accept_sec_context (krb5_gss_glue.c:434)
>>> ==5314==    by 0x4034178: gss_accept_sec_context
>>> (g_accept_sec_context.c:196)
>>> ==5314==    by 0x40510A7: spnego_gss_accept_sec_context 
>>> (spnego_mech.c:1113)
>>> ==5314==    by 0x4034178: gss_accept_sec_context
>>> (g_accept_sec_context.c:196)
>>> ==5314==    by 0x8049C91: main (squid_kerb_auth.c:515)
>>>
>>> ==5314== 2,852 bytes in 31 blocks are still reachable in loss record 81
>>> of 82
>>> ==5314==    at 0x4022AB8: malloc (vg_replace_malloc.c:207)
>>> ==5314==    by 0x403F3C4: krb5_gss_acquire_cred (acquire_cred.c:497)
>>> ==5314==    by 0x403D23F: krb5_gss_accept_sec_context
>>> (accept_sec_context.c:302)
>>> ==5314==    by 0x404B192: k5glue_accept_sec_context (krb5_gss_glue.c:434)
>>> ==5314==    by 0x4034178: gss_accept_sec_context
>>> (g_accept_sec_context.c:196)
>>> ==5314==    by 0x40510A7: spnego_gss_accept_sec_context 
>>> (spnego_mech.c:1113)
>>> ==5314==    by 0x4034178: gss_accept_sec_context
>>> (g_accept_sec_context.c:196)
>>> ==5314==    by 0x8049C91: main (squid_kerb_auth.c:515)
>>>
>>> ==5314== 256,308 bytes in 31 blocks are still reachable in loss record
>>> 82 of 82
>>> ==5314==    at 0x4022AB8: malloc (vg_replace_malloc.c:207)
>>> ==5314==    by 0x40A008A: krb5_ktfile_resolve (kt_file.c:211)
>>> ==5314==    by 0x409D900: krb5_kt_resolve (ktbase.c:129)
>>> ==5314==    by 0x409DB38: krb5_kt_default (ktdefault.c:41)
>>> ==5314==    by 0x4041EC1: krb5_gss_acquire_cred (acquire_cred.c:171)
>>> ==5314==    by 0x403D23F: krb5_gss_accept_sec_context
>>> (accept_sec_context.c:302)
>>> ==5314==    by 0x404B192: k5glue_accept_sec_context (krb5_gss_glue.c:434)
>>> ==5314==    by 0x4034178: gss_accept_sec_context
>>> (g_accept_sec_context.c:196)
>>> ==5314==    by 0x40510A7: spnego_gss_accept_sec_context 
>>> (spnego_mech.c:1113)
>>> ==5314==    by 0x4034178: gss_accept_sec_context
>>> (g_accept_sec_context.c:196)
>>> ==5314==    by 0x8049C91: main (squid_kerb_auth.c:515)
>>>
>>> I've also debugged the squid_kerb_auth helper code and made sure it
>>> matches calls to gss_accept_sec_context() with calls to
>>> gss_delete_sec_context() which it does. So these still reachable leaks
>>> do appear to be bugs in the MIT Kerberos libs.
>>>
>>> Can anyone shed any light on these? as they are making MIT Kerberos
>>> unusable. Regards, Dan...
>>>
>>> -- 
>>> Dan Searle
>>>
>>> CensorNet Ltd - professional & affordable Web & E-mail filtering
>>> email: dan.searle at censornet.com web: www.censornet.com
>>> tel: 0845 230 9590 / fax: 0845 230 9591 / support: 0845 230 9592
>>> snail: Vallon House, Vantage Court Office Park, Winterbourne,
>>>        Bristol, BS16 1GW, UK.
>>>
>>> CensorNet Ltd is a registered company in England & Wales No. 05518629
>>> VAT registration number 901-2048-78
>>> Any views expressed in this email communication are those of the
>>> individual sender, except where the sender specifically states them to
>>> be the views of a member of Censornet Ltd.  Censornet Ltd. does not
>>> represent, warrant or guarantee that the integrity of this
>>> communication has been maintained nor that the communication is free
>>> of errors or interference.
>>>
>>>
>>> -------------------------------------------------------------------------------
>>> -----
>>> Scanned for viruses, spam and offensive content by CensorNet MailSafe
>>>
>>> Try CensorNet free for 14 days. Provide Internet access on your terms.
>>> Visit www.censornet.com for more information.
>>>
>>> _______________________________________________
>>> krbdev mailing list             krbdev at mit.edu
>>> https://mailman.mit.edu/mailman/listinfo/krbdev
>>>       
>> Presumably your iteration count in this sample was 31.
>> 3 of your 5 loss records are associated with calls to
>> krb5_ktfile_resolve.  Calls to krb5_ktfile_resolve/krb5_kt_default
>> should be balanced with calls to krb5_ktfile_close.
>> The relevant logic is in krb5/src/lib/gssapi/krb5/acquire_cred.c
>> so that's presumably where the missing krb5_ktfile_close call ought
>> to be.
>>
>> Both your remaining loss records are directly from gssapi.
>> specifically krb5_gss_acquire_cred.  It looks like calls to that
>> should be paired up with calls to krb5_gss_release_cred.
>> That could happen at the end of krb5_gss_accept_sec_context
>> if verifier_cred_handle is passed as 0, otherwise, it looks like
>> the application (squid?) should be responsible.
>>     
>
> This is a standalone application. All interaction with squid is via stdin 
> (base64 encoded token) and stdout.
>
>   
>> Presumably the
>> squid code should actually be calling gss_release_cred.
>> It's possible there's a bug here in the MIT code, but it would be
>> useful to first establish the credential isn't in fact being
>> passed out to squid.
>>
>>     
>
> I tested in the past several MIT/Heimdal versions on different Linux 
> distributions. Some distribution have fixed MIT memory leaks others haven't. 
> I think my squid_kerb_auth code is correct in freeing allocated memory (at 
> least i have seen one or two Linux distributions e.g. centos which don't 
> show leaks)
>
>   
>> -Marcus Watts
>> _______________________________________________
>> krbdev mailing list             krbdev at mit.edu
>> https://mailman.mit.edu/mailman/listinfo/krbdev
>>
>>     
> Regards
> Markus 
>
>
> _______________________________________________
> krbdev mailing list             krbdev at mit.edu
> https://mailman.mit.edu/mailman/listinfo/krbdev
>
> ------------------------------------------------------------------------------------
> Scanned for viruses, spam and offensive content by CensorNet MailSafe
>
> Try CensorNet free for 14 days. Provide Internet access on your terms.
> Visit www.censornet.com for more information.
>   
> ------------------------------------------------------------------------
>
>
> No virus found in this incoming message.
> Checked by AVG - www.avg.com 
> Version: 9.0.704 / Virus Database: 270.14.60/2496 - Release Date: 11/11/09 07:40:00
>
>   


-- 
Dan Searle

CensorNet Ltd - professional & affordable Web & E-mail filtering
email: dan.searle at censornet.com web: www.censornet.com
tel: 0845 230 9590 / fax: 0845 230 9591 / support: 0845 230 9592
snail: Vallon House, Vantage Court Office Park, Winterbourne,
       Bristol, BS16 1GW, UK.

CensorNet Ltd is a registered company in England & Wales No. 05518629
VAT registration number 901-2048-78
Any views expressed in this email communication are those of the
individual sender, except where the sender specifically states them to
be the views of a member of Censornet Ltd.  Censornet Ltd. does not
represent, warrant or guarantee that the integrity of this
communication has been maintained nor that the communication is free
of errors or interference. 


------------------------------------------------------------------------------------
Scanned for viruses, spam and offensive content by CensorNet MailSafe

Try CensorNet free for 14 days. Provide Internet access on your terms.
Visit www.censornet.com for more information.


From dan.searle at censornet.com  Thu Nov 12 10:18:57 2009
From: dan.searle at censornet.com (Dan Searle)
Date: Thu, 12 Nov 2009 15:18:57 +0000
Subject: More memory leaks (1.6.4-beta1 release)
In-Reply-To: <hdf8sr$5ua$1@ger.gmane.org>
References: <4AFAC2AD.5090505@censornet.com>	<E1N8GYL-0005yn-Kd@bruson.ifs.umich.edu>
	<hdf8sr$5ua$1@ger.gmane.org>
Message-ID: <4AFC2761.9070102@censornet.com>

Hi guys,

I've managed to come up with a patch to the krb5-1.6.4-beta1 release 
that fixes the critical still reachable memory leaks, please see the 
attached file. I would appreciate comments as my "fixes" may have other 
side effects I'm unaware of.

Regards, Dan...

Markus Moeller wrote:
> "Marcus Watts" <mdw at umich.edu> wrote in message 
> news:E1N8GYL-0005yn-Kd at bruson.ifs.umich.edu...
>   
>>> Date:    Wed, 11 Nov 2009 13:57:01 GMT
>>> To:      krbdev at mit.edu
>>> From:    Dan Searle <dan.searle at censornet.com>
>>> Subject: More memory leaks (1.6.4-beta1 release)
>>>
>>> Hi,
>>>
>>> I've been debugging the squid_kerb_auth helper some more and have found
>>> yet more memory leaks. I missed these last round because I didn't take
>>> into account (ignored) the still reachable blocks (malloced blocks which
>>> still have valid pointers).
>>>
>>> I've ignores the instances (loss records) with just 1 block or what seem
>>> to be a "fixed" number of still reachable blocks, i.e. I've only
>>> included here the loss records which seem to scale with the number of
>>> iterations the authentication helper goes through, and so are a threat
>>> to a running process...
>>>
>>> ==5314== 372 bytes in 31 blocks are still reachable in loss record 76 of 
>>> 82
>>> ==5314==    at 0x4022AB8: malloc (vg_replace_malloc.c:207)
>>> ==5314==    by 0x4032BE5: gssint_g_set_entry_add (util_set.c:61)
>>> ==5314==    by 0x4033B1B: g_save (util_validate.c:114)
>>> ==5314==    by 0x404097A: krb5_gss_acquire_cred (acquire_cred.c:645)
>>> ==5314==    by 0x403D23F: krb5_gss_accept_sec_context
>>> (accept_sec_context.c:302)
>>> ==5314==    by 0x404B192: k5glue_accept_sec_context (krb5_gss_glue.c:434)
>>> ==5314==    by 0x4034178: gss_accept_sec_context
>>> (g_accept_sec_context.c:196)
>>> ==5314==    by 0x40510A7: spnego_gss_accept_sec_context 
>>> (spnego_mech.c:1113)
>>> ==5314==    by 0x4034178: gss_accept_sec_context
>>> (g_accept_sec_context.c:196)
>>> ==5314==    by 0x8049C91: main (squid_kerb_auth.c:515)
>>>
>>> ==5314== 372 bytes in 31 blocks are still reachable in loss record 77 of 
>>> 82
>>> ==5314==    at 0x4022AB8: malloc (vg_replace_malloc.c:207)
>>> ==5314==    by 0x40A006A: krb5_ktfile_resolve (kt_file.c:207)
>>> ==5314==    by 0x409D900: krb5_kt_resolve (ktbase.c:129)
>>> ==5314==    by 0x409DB38: krb5_kt_default (ktdefault.c:41)
>>> ==5314==    by 0x4041EC1: krb5_gss_acquire_cred (acquire_cred.c:171)
>>> ==5314==    by 0x403D23F: krb5_gss_accept_sec_context
>>> (accept_sec_context.c:302)
>>> ==5314==    by 0x404B192: k5glue_accept_sec_context (krb5_gss_glue.c:434)
>>> ==5314==    by 0x4034178: gss_accept_sec_context
>>> (g_accept_sec_context.c:196)
>>> ==5314==    by 0x40510A7: spnego_gss_accept_sec_context 
>>> (spnego_mech.c:1113)
>>> ==5314==    by 0x4034178: gss_accept_sec_context
>>> (g_accept_sec_context.c:196)
>>> ==5314==    by 0x8049C91: main (squid_kerb_auth.c:515)
>>>
>>> ==5314== 527 bytes in 31 blocks are still reachable in loss record 78 of 
>>> 82
>>> ==5314==    at 0x4021BDE: calloc (vg_replace_malloc.c:397)
>>> ==5314==    by 0x40A013A: krb5_ktfile_resolve (kt_file.c:223)
>>> ==5314==    by 0x409D900: krb5_kt_resolve (ktbase.c:129)
>>> ==5314==    by 0x409DB38: krb5_kt_default (ktdefault.c:41)
>>> ==5314==    by 0x4041EC1: krb5_gss_acquire_cred (acquire_cred.c:171)
>>> ==5314==    by 0x403D23F: krb5_gss_accept_sec_context
>>> (accept_sec_context.c:302)
>>> ==5314==    by 0x404B192: k5glue_accept_sec_context (krb5_gss_glue.c:434)
>>> ==5314==    by 0x4034178: gss_accept_sec_context
>>> (g_accept_sec_context.c:196)
>>> ==5314==    by 0x40510A7: spnego_gss_accept_sec_context 
>>> (spnego_mech.c:1113)
>>> ==5314==    by 0x4034178: gss_accept_sec_context
>>> (g_accept_sec_context.c:196)
>>> ==5314==    by 0x8049C91: main (squid_kerb_auth.c:515)
>>>
>>> ==5314== 2,852 bytes in 31 blocks are still reachable in loss record 81
>>> of 82
>>> ==5314==    at 0x4022AB8: malloc (vg_replace_malloc.c:207)
>>> ==5314==    by 0x403F3C4: krb5_gss_acquire_cred (acquire_cred.c:497)
>>> ==5314==    by 0x403D23F: krb5_gss_accept_sec_context
>>> (accept_sec_context.c:302)
>>> ==5314==    by 0x404B192: k5glue_accept_sec_context (krb5_gss_glue.c:434)
>>> ==5314==    by 0x4034178: gss_accept_sec_context
>>> (g_accept_sec_context.c:196)
>>> ==5314==    by 0x40510A7: spnego_gss_accept_sec_context 
>>> (spnego_mech.c:1113)
>>> ==5314==    by 0x4034178: gss_accept_sec_context
>>> (g_accept_sec_context.c:196)
>>> ==5314==    by 0x8049C91: main (squid_kerb_auth.c:515)
>>>
>>> ==5314== 256,308 bytes in 31 blocks are still reachable in loss record
>>> 82 of 82
>>> ==5314==    at 0x4022AB8: malloc (vg_replace_malloc.c:207)
>>> ==5314==    by 0x40A008A: krb5_ktfile_resolve (kt_file.c:211)
>>> ==5314==    by 0x409D900: krb5_kt_resolve (ktbase.c:129)
>>> ==5314==    by 0x409DB38: krb5_kt_default (ktdefault.c:41)
>>> ==5314==    by 0x4041EC1: krb5_gss_acquire_cred (acquire_cred.c:171)
>>> ==5314==    by 0x403D23F: krb5_gss_accept_sec_context
>>> (accept_sec_context.c:302)
>>> ==5314==    by 0x404B192: k5glue_accept_sec_context (krb5_gss_glue.c:434)
>>> ==5314==    by 0x4034178: gss_accept_sec_context
>>> (g_accept_sec_context.c:196)
>>> ==5314==    by 0x40510A7: spnego_gss_accept_sec_context 
>>> (spnego_mech.c:1113)
>>> ==5314==    by 0x4034178: gss_accept_sec_context
>>> (g_accept_sec_context.c:196)
>>> ==5314==    by 0x8049C91: main (squid_kerb_auth.c:515)
>>>
>>> I've also debugged the squid_kerb_auth helper code and made sure it
>>> matches calls to gss_accept_sec_context() with calls to
>>> gss_delete_sec_context() which it does. So these still reachable leaks
>>> do appear to be bugs in the MIT Kerberos libs.
>>>
>>> Can anyone shed any light on these? as they are making MIT Kerberos
>>> unusable. Regards, Dan...
>>>
>>> -- 
>>> Dan Searle
>>>
>>> CensorNet Ltd - professional & affordable Web & E-mail filtering
>>> email: dan.searle at censornet.com web: www.censornet.com
>>> tel: 0845 230 9590 / fax: 0845 230 9591 / support: 0845 230 9592
>>> snail: Vallon House, Vantage Court Office Park, Winterbourne,
>>>        Bristol, BS16 1GW, UK.
>>>
>>> CensorNet Ltd is a registered company in England & Wales No. 05518629
>>> VAT registration number 901-2048-78
>>> Any views expressed in this email communication are those of the
>>> individual sender, except where the sender specifically states them to
>>> be the views of a member of Censornet Ltd.  Censornet Ltd. does not
>>> represent, warrant or guarantee that the integrity of this
>>> communication has been maintained nor that the communication is free
>>> of errors or interference.
>>>
>>>
>>> -------------------------------------------------------------------------------
>>> -----
>>> Scanned for viruses, spam and offensive content by CensorNet MailSafe
>>>
>>> Try CensorNet free for 14 days. Provide Internet access on your terms.
>>> Visit www.censornet.com for more information.
>>>
>>> _______________________________________________
>>> krbdev mailing list             krbdev at mit.edu
>>> https://mailman.mit.edu/mailman/listinfo/krbdev
>>>       
>> Presumably your iteration count in this sample was 31.
>> 3 of your 5 loss records are associated with calls to
>> krb5_ktfile_resolve.  Calls to krb5_ktfile_resolve/krb5_kt_default
>> should be balanced with calls to krb5_ktfile_close.
>> The relevant logic is in krb5/src/lib/gssapi/krb5/acquire_cred.c
>> so that's presumably where the missing krb5_ktfile_close call ought
>> to be.
>>
>> Both your remaining loss records are directly from gssapi.
>> specifically krb5_gss_acquire_cred.  It looks like calls to that
>> should be paired up with calls to krb5_gss_release_cred.
>> That could happen at the end of krb5_gss_accept_sec_context
>> if verifier_cred_handle is passed as 0, otherwise, it looks like
>> the application (squid?) should be responsible.
>>     
>
> This is a standalone application. All interaction with squid is via stdin 
> (base64 encoded token) and stdout.
>
>   
>> Presumably the
>> squid code should actually be calling gss_release_cred.
>> It's possible there's a bug here in the MIT code, but it would be
>> useful to first establish the credential isn't in fact being
>> passed out to squid.
>>
>>     
>
> I tested in the past several MIT/Heimdal versions on different Linux 
> distributions. Some distribution have fixed MIT memory leaks others haven't. 
> I think my squid_kerb_auth code is correct in freeing allocated memory (at 
> least i have seen one or two Linux distributions e.g. centos which don't 
> show leaks)
>
>   
>> -Marcus Watts
>> _______________________________________________
>> krbdev mailing list             krbdev at mit.edu
>> https://mailman.mit.edu/mailman/listinfo/krbdev
>>
>>     
> Regards
> Markus 
>
>
> _______________________________________________
> krbdev mailing list             krbdev at mit.edu
> https://mailman.mit.edu/mailman/listinfo/krbdev
>
> ------------------------------------------------------------------------------------
> Scanned for viruses, spam and offensive content by CensorNet MailSafe
>
> Try CensorNet free for 14 days. Provide Internet access on your terms.
> Visit www.censornet.com for more information.
>   
> ------------------------------------------------------------------------
>
>
> No virus found in this incoming message.
> Checked by AVG - www.avg.com 
> Version: 9.0.704 / Virus Database: 270.14.60/2496 - Release Date: 11/11/09 07:40:00
>
>   


-- 
Dan Searle

CensorNet Ltd - professional & affordable Web & E-mail filtering
email: dan.searle at censornet.com web: www.censornet.com
tel: 0845 230 9590 / fax: 0845 230 9591 / support: 0845 230 9592
snail: Vallon House, Vantage Court Office Park, Winterbourne,
       Bristol, BS16 1GW, UK.

CensorNet Ltd is a registered company in England & Wales No. 05518629
VAT registration number 901-2048-78
Any views expressed in this email communication are those of the
individual sender, except where the sender specifically states them to
be the views of a member of Censornet Ltd.  Censornet Ltd. does not
represent, warrant or guarantee that the integrity of this
communication has been maintained nor that the communication is free
of errors or interference. 


------------------------------------------------------------------------------------
Scanned for viruses, spam and offensive content by CensorNet MailSafe

Try CensorNet free for 14 days. Provide Internet access on your terms.
Visit www.censornet.com for more information.

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: krb5-1.6.4-beta1.patch
Url: http://mailman.mit.edu/pipermail/krbdev/attachments/20091112/c5f9199c/krb5-1.6.4-beta1.bat

From huaraz at moeller.plus.com  Thu Nov 12 16:43:47 2009
From: huaraz at moeller.plus.com (Markus Moeller)
Date: Thu, 12 Nov 2009 21:43:47 -0000
Subject: More memory leaks (1.6.4-beta1 release)
In-Reply-To: <4AFBDA48.2000402@censornet.com>
References: <4AFAC2AD.5090505@censornet.com>	<E1N8GYL-0005yn-Kd@bruson.ifs.umich.edu>
	<hdf8sr$5ua$1@ger.gmane.org> <4AFBDA48.2000402@censornet.com>
Message-ID: <9246E5EC4D714CC6B72ED84E3A23693A@VAIOLaptop>

Sorry Dan, but I changed systems in the mean time (to OpenSuse 11.1) and get 
no leak (only still reachable: 672 bytes in 18 blocks independant of the 
number of iterations).

For 1 auth request

==15788== 29 bytes in 4 blocks are still reachable in loss record 1 of 5
==15788==    at 0x4027DDE: malloc (in 
/usr/lib/valgrind/x86-linux/vgpreload_memcheck.so)
==15788==    by 0x4037FEE: gss_indicate_mechs (in 
/usr/lib/libgssapi_krb5.so.2.2)
==15788==    by 0x404FD0E: (within /usr/lib/libgssapi_krb5.so.2.2)
==15788==    by 0x4051147: (within /usr/lib/libgssapi_krb5.so.2.2)
==15788==    by 0x403361A: gss_accept_sec_context (in 
/usr/lib/libgssapi_krb5.so.2.2)
==15788==    by 0x8049E13: main (squid_kerb_auth.c:500)
==15788==
==15788==
==15788== 32 bytes in 1 blocks are still reachable in loss record 2 of 5
==15788==    at 0x4025E92: calloc (in 
/usr/lib/valgrind/x86-linux/vgpreload_memcheck.so)
==15788==    by 0x4037F59: gss_indicate_mechs (in 
/usr/lib/libgssapi_krb5.so.2.2)
==15788==    by 0x404FD0E: (within /usr/lib/libgssapi_krb5.so.2.2)
==15788==    by 0x4051147: (within /usr/lib/libgssapi_krb5.so.2.2)
==15788==    by 0x403361A: gss_accept_sec_context (in 
/usr/lib/libgssapi_krb5.so.2.2)
==15788==    by 0x8049E13: main (squid_kerb_auth.c:500)
==15788==
==15788==
==15788== 128 bytes in 4 blocks are still reachable in loss record 3 of 5
==15788==    at 0x4027DDE: malloc (in 
/usr/lib/valgrind/x86-linux/vgpreload_memcheck.so)
==15788==    by 0x4036694: (within /usr/lib/libgssapi_krb5.so.2.2)
==15788==    by 0x40367A0: (within /usr/lib/libgssapi_krb5.so.2.2)
==15788==    by 0x4036DD4: (within /usr/lib/libgssapi_krb5.so.2.2)
==15788==    by 0x40343BC: gss_acquire_cred (in 
/usr/lib/libgssapi_krb5.so.2.2)
==15788==    by 0x8049D7C: main (squid_kerb_auth.c:493)
==15788==
==15788==
==15788== 131 bytes in 8 blocks are still reachable in loss record 4 of 5
==15788==    at 0x4027DDE: malloc (in 
/usr/lib/valgrind/x86-linux/vgpreload_memcheck.so)
==15788==    by 0x41CD45F: strdup (in /lib/libc-2.9.so)
==15788==    by 0x40366BC: (within /usr/lib/libgssapi_krb5.so.2.2)
==15788==    by 0x40367A0: (within /usr/lib/libgssapi_krb5.so.2.2)
==15788==    by 0x4036DD4: (within /usr/lib/libgssapi_krb5.so.2.2)
==15788==    by 0x40343BC: gss_acquire_cred (in 
/usr/lib/libgssapi_krb5.so.2.2)
==15788==    by 0x8049D7C: main (squid_kerb_auth.c:493)
==15788==
==15788==
==15788== 352 bytes in 1 blocks are still reachable in loss record 5 of 5
==15788==    at 0x4027DDE: malloc (in 
/usr/lib/valgrind/x86-linux/vgpreload_memcheck.so)
==15788==    by 0x41B6B3E: (within /lib/libc-2.9.so)
==15788==    by 0x41B6C0B: fopen (in /lib/libc-2.9.so)
==15788==    by 0x4140F67: (within /lib/libcom_err.so.2.1)
==15788==    by 0x414115D: add_error_table (in /lib/libcom_err.so.2.1)
==15788==    by 0x4031161: (within /usr/lib/libgssapi_krb5.so.2.2)
==15788==    by 0x40305A4: (within /usr/lib/libgssapi_krb5.so.2.2)
==15788==    by 0x4036C5E: (within /usr/lib/libgssapi_krb5.so.2.2)
==15788==    by 0x40343BC: gss_acquire_cred (in 
/usr/lib/libgssapi_krb5.so.2.2)
==15788==    by 0x8049D7C: main (squid_kerb_auth.c:493)
==15788==
==15788== LEAK SUMMARY:
==15788==    definitely lost: 0 bytes in 0 blocks.
==15788==      possibly lost: 0 bytes in 0 blocks.
==15788==    still reachable: 672 bytes in 18 blocks.
==15788==         suppressed: 0 bytes in 0 blocks.
--15788--  memcheck: sanity checks: 4 cheap, 2 expensive
--15788--  memcheck: auxmaps: 0 auxmap entries (0k, 0M) in use
--15788--  memcheck: auxmaps_L1: 0 searches, 0 cmps, ratio 0:10
--15788--  memcheck: auxmaps_L2: 0 searches, 0 nodes
--15788--  memcheck: SMs: n_issued      = 19 (304k, 0M)
--15788--  memcheck: SMs: n_deissued    = 0 (0k, 0M)
--15788--  memcheck: SMs: max_noaccess  = 65535 (1048560k, 1023M)
--15788--  memcheck: SMs: max_undefined = 0 (0k, 0M)
--15788--  memcheck: SMs: max_defined   = 36 (576k, 0M)
--15788--  memcheck: SMs: max_non_DSM   = 19 (304k, 0M)
--15788--  memcheck: max sec V bit nodes:    0 (0k, 0M)
--15788--  memcheck: set_sec_vbits8 calls: 0 (new: 0, updates: 0)
--15788--  memcheck: max shadow mem size:   608k, 0M
--15788-- translate:            fast SP updates identified: 8,394 ( 89.1%)
--15788-- translate:   generic_known SP updates identified: 693 (  7.3%)
--15788-- translate: generic_unknown SP updates identified: 330 (  3.5%)
--15788--     tt/tc: 23,891 tt lookups requiring 25,400 probes
--15788--     tt/tc: 23,891 fast-cache updates, 3 flushes
--15788--  transtab: new        9,075 (209,982 -> 2,791,681; ratio 132:10) 
[0 scs]
--15788--  transtab: dumped     0 (0 -> ??)
--15788--  transtab: discarded  7 (189 -> ??)
--15788-- scheduler: 442,996 jumps (bb entries).
--15788-- scheduler: 4/19,118 major/minor sched events.
--15788--    sanity: 5 cheap, 2 expensive checks.
--15788--    exectx: 1,543 lists, 993 contexts (avg 0 per list)
--15788--    exectx: 2,464 searches, 2,046 full compares (830 per 1000)
--15788--    exectx: 26 cmp2, 3 cmp4, 0 cmpAll
--15788--  errormgr: 9 supplist searches, 360 comparisons during search
--15788--  errormgr: 4 errlist searches, 6 comparisons during search

and for 10000 requests

==15790== LEAK SUMMARY:
==15790==    definitely lost: 0 bytes in 0 blocks.
==15790==      possibly lost: 0 bytes in 0 blocks.
==15790==    still reachable: 672 bytes in 18 blocks.
==15790==         suppressed: 0 bytes in 0 blocks.
--15790--  memcheck: sanity checks: 69361 cheap, 351 expensive
--15790--  memcheck: auxmaps: 0 auxmap entries (0k, 0M) in use
--15790--  memcheck: auxmaps_L1: 0 searches, 0 cmps, ratio 0:10
--15790--  memcheck: auxmaps_L2: 0 searches, 0 nodes
--15790--  memcheck: SMs: n_issued      = 456 (7296k, 7M)
--15790--  memcheck: SMs: n_deissued    = 0 (0k, 0M)
--15790--  memcheck: SMs: max_noaccess  = 65535 (1048560k, 1023M)
--15790--  memcheck: SMs: max_undefined = 0 (0k, 0M)
--15790--  memcheck: SMs: max_defined   = 36 (576k, 0M)
--15790--  memcheck: SMs: max_non_DSM   = 456 (7296k, 7M)
--15790--  memcheck: max sec V bit nodes:    0 (0k, 0M)
--15790--  memcheck: set_sec_vbits8 calls: 0 (new: 0, updates: 0)
--15790--  memcheck: max shadow mem size:   7600k, 7M
--15790-- translate:            fast SP updates identified: 8,574 ( 89.1%)
--15790-- translate:   generic_known SP updates identified: 711 (  7.3%)
--15790-- translate: generic_unknown SP updates identified: 336 (  3.4%)
--15790--     tt/tc: 13,910,651 tt lookups requiring 14,978,428 probes
--15790--     tt/tc: 13,910,651 fast-cache updates, 3 flushes
--15790--  transtab: new        9,240 (213,732 -> 2,840,293; ratio 132:10) 
[0 scs]
--15790--  transtab: dumped     0 (0 -> ??)
--15790--  transtab: discarded  7 (189 -> ??)
--15790-- scheduler: 6,936,176,324 jumps (bb entries).
--15790-- scheduler: 69,361/376,007,102 major/minor sched events.
--15790--    sanity: 69362 cheap, 351 expensive checks.
--15790--    exectx: 1,543 lists, 1,087 contexts (avg 0 per list)
--15790--    exectx: 213,864,694 searches, 217,952,068 full compares (1,019 
per 1000)
--15790--    exectx: 26 cmp2, 3 cmp4, 0 cmpAll
--15790--  errormgr: 9 supplist searches, 360 comparisons during search
--15790--  errormgr: 4 errlist searches, 6 comparisons during search

Markus

----- Original Message ----- 
From: "Dan Searle" <dan.searle at censornet.com>
To: "Markus Moeller" <huaraz at moeller.plus.com>
Cc: <krbdev at mit.edu>
Sent: Thursday, November 12, 2009 9:50 AM
Subject: Re: More memory leaks (1.6.4-beta1 release)


> Hi,
>
> Since you say CentOS has a version of MIT Kerberos 5 which shows no leaks, 
> can you provide me with a link to their source code or be more specific 
> about which version of CentOS you were testing? I really need a solution 
> to this problem very quickly. I've tried to find CentOS's RPM's for MIT's 
> Kerberos but have so far failed.
> Dan...
>
> Markus Moeller wrote:
>> "Marcus Watts" <mdw at umich.edu> wrote in message 
>> news:E1N8GYL-0005yn-Kd at bruson.ifs.umich.edu...
>>
>>>> Date:    Wed, 11 Nov 2009 13:57:01 GMT
>>>> To:      krbdev at mit.edu
>>>> From:    Dan Searle <dan.searle at censornet.com>
>>>> Subject: More memory leaks (1.6.4-beta1 release)
>>>>
>>>> Hi,
>>>>
>>>> I've been debugging the squid_kerb_auth helper some more and have found
>>>> yet more memory leaks. I missed these last round because I didn't take
>>>> into account (ignored) the still reachable blocks (malloced blocks 
>>>> which
>>>> still have valid pointers).
>>>>
>>>> I've ignores the instances (loss records) with just 1 block or what 
>>>> seem
>>>> to be a "fixed" number of still reachable blocks, i.e. I've only
>>>> included here the loss records which seem to scale with the number of
>>>> iterations the authentication helper goes through, and so are a threat
>>>> to a running process...
>>>>
>>>> ==5314== 372 bytes in 31 blocks are still reachable in loss record 76 
>>>> of 82
>>>> ==5314==    at 0x4022AB8: malloc (vg_replace_malloc.c:207)
>>>> ==5314==    by 0x4032BE5: gssint_g_set_entry_add (util_set.c:61)
>>>> ==5314==    by 0x4033B1B: g_save (util_validate.c:114)
>>>> ==5314==    by 0x404097A: krb5_gss_acquire_cred (acquire_cred.c:645)
>>>> ==5314==    by 0x403D23F: krb5_gss_accept_sec_context
>>>> (accept_sec_context.c:302)
>>>> ==5314==    by 0x404B192: k5glue_accept_sec_context 
>>>> (krb5_gss_glue.c:434)
>>>> ==5314==    by 0x4034178: gss_accept_sec_context
>>>> (g_accept_sec_context.c:196)
>>>> ==5314==    by 0x40510A7: spnego_gss_accept_sec_context 
>>>> (spnego_mech.c:1113)
>>>> ==5314==    by 0x4034178: gss_accept_sec_context
>>>> (g_accept_sec_context.c:196)
>>>> ==5314==    by 0x8049C91: main (squid_kerb_auth.c:515)
>>>>
>>>> ==5314== 372 bytes in 31 blocks are still reachable in loss record 77 
>>>> of 82
>>>> ==5314==    at 0x4022AB8: malloc (vg_replace_malloc.c:207)
>>>> ==5314==    by 0x40A006A: krb5_ktfile_resolve (kt_file.c:207)
>>>> ==5314==    by 0x409D900: krb5_kt_resolve (ktbase.c:129)
>>>> ==5314==    by 0x409DB38: krb5_kt_default (ktdefault.c:41)
>>>> ==5314==    by 0x4041EC1: krb5_gss_acquire_cred (acquire_cred.c:171)
>>>> ==5314==    by 0x403D23F: krb5_gss_accept_sec_context
>>>> (accept_sec_context.c:302)
>>>> ==5314==    by 0x404B192: k5glue_accept_sec_context 
>>>> (krb5_gss_glue.c:434)
>>>> ==5314==    by 0x4034178: gss_accept_sec_context
>>>> (g_accept_sec_context.c:196)
>>>> ==5314==    by 0x40510A7: spnego_gss_accept_sec_context 
>>>> (spnego_mech.c:1113)
>>>> ==5314==    by 0x4034178: gss_accept_sec_context
>>>> (g_accept_sec_context.c:196)
>>>> ==5314==    by 0x8049C91: main (squid_kerb_auth.c:515)
>>>>
>>>> ==5314== 527 bytes in 31 blocks are still reachable in loss record 78 
>>>> of 82
>>>> ==5314==    at 0x4021BDE: calloc (vg_replace_malloc.c:397)
>>>> ==5314==    by 0x40A013A: krb5_ktfile_resolve (kt_file.c:223)
>>>> ==5314==    by 0x409D900: krb5_kt_resolve (ktbase.c:129)
>>>> ==5314==    by 0x409DB38: krb5_kt_default (ktdefault.c:41)
>>>> ==5314==    by 0x4041EC1: krb5_gss_acquire_cred (acquire_cred.c:171)
>>>> ==5314==    by 0x403D23F: krb5_gss_accept_sec_context
>>>> (accept_sec_context.c:302)
>>>> ==5314==    by 0x404B192: k5glue_accept_sec_context 
>>>> (krb5_gss_glue.c:434)
>>>> ==5314==    by 0x4034178: gss_accept_sec_context
>>>> (g_accept_sec_context.c:196)
>>>> ==5314==    by 0x40510A7: spnego_gss_accept_sec_context 
>>>> (spnego_mech.c:1113)
>>>> ==5314==    by 0x4034178: gss_accept_sec_context
>>>> (g_accept_sec_context.c:196)
>>>> ==5314==    by 0x8049C91: main (squid_kerb_auth.c:515)
>>>>
>>>> ==5314== 2,852 bytes in 31 blocks are still reachable in loss record 81
>>>> of 82
>>>> ==5314==    at 0x4022AB8: malloc (vg_replace_malloc.c:207)
>>>> ==5314==    by 0x403F3C4: krb5_gss_acquire_cred (acquire_cred.c:497)
>>>> ==5314==    by 0x403D23F: krb5_gss_accept_sec_context
>>>> (accept_sec_context.c:302)
>>>> ==5314==    by 0x404B192: k5glue_accept_sec_context 
>>>> (krb5_gss_glue.c:434)
>>>> ==5314==    by 0x4034178: gss_accept_sec_context
>>>> (g_accept_sec_context.c:196)
>>>> ==5314==    by 0x40510A7: spnego_gss_accept_sec_context 
>>>> (spnego_mech.c:1113)
>>>> ==5314==    by 0x4034178: gss_accept_sec_context
>>>> (g_accept_sec_context.c:196)
>>>> ==5314==    by 0x8049C91: main (squid_kerb_auth.c:515)
>>>>
>>>> ==5314== 256,308 bytes in 31 blocks are still reachable in loss record
>>>> 82 of 82
>>>> ==5314==    at 0x4022AB8: malloc (vg_replace_malloc.c:207)
>>>> ==5314==    by 0x40A008A: krb5_ktfile_resolve (kt_file.c:211)
>>>> ==5314==    by 0x409D900: krb5_kt_resolve (ktbase.c:129)
>>>> ==5314==    by 0x409DB38: krb5_kt_default (ktdefault.c:41)
>>>> ==5314==    by 0x4041EC1: krb5_gss_acquire_cred (acquire_cred.c:171)
>>>> ==5314==    by 0x403D23F: krb5_gss_accept_sec_context
>>>> (accept_sec_context.c:302)
>>>> ==5314==    by 0x404B192: k5glue_accept_sec_context 
>>>> (krb5_gss_glue.c:434)
>>>> ==5314==    by 0x4034178: gss_accept_sec_context
>>>> (g_accept_sec_context.c:196)
>>>> ==5314==    by 0x40510A7: spnego_gss_accept_sec_context 
>>>> (spnego_mech.c:1113)
>>>> ==5314==    by 0x4034178: gss_accept_sec_context
>>>> (g_accept_sec_context.c:196)
>>>> ==5314==    by 0x8049C91: main (squid_kerb_auth.c:515)
>>>>
>>>> I've also debugged the squid_kerb_auth helper code and made sure it
>>>> matches calls to gss_accept_sec_context() with calls to
>>>> gss_delete_sec_context() which it does. So these still reachable leaks
>>>> do appear to be bugs in the MIT Kerberos libs.
>>>>
>>>> Can anyone shed any light on these? as they are making MIT Kerberos
>>>> unusable. Regards, Dan...
>>>>
>>>> -- 
>>>> Dan Searle
>>>>
>>>> CensorNet Ltd - professional & affordable Web & E-mail filtering
>>>> email: dan.searle at censornet.com web: www.censornet.com
>>>> tel: 0845 230 9590 / fax: 0845 230 9591 / support: 0845 230 9592
>>>> snail: Vallon House, Vantage Court Office Park, Winterbourne,
>>>>        Bristol, BS16 1GW, UK.
>>>>
>>>> CensorNet Ltd is a registered company in England & Wales No. 05518629
>>>> VAT registration number 901-2048-78
>>>> Any views expressed in this email communication are those of the
>>>> individual sender, except where the sender specifically states them to
>>>> be the views of a member of Censornet Ltd.  Censornet Ltd. does not
>>>> represent, warrant or guarantee that the integrity of this
>>>> communication has been maintained nor that the communication is free
>>>> of errors or interference.
>>>>
>>>>
>>>> -------------------------------------------------------------------------------
>>>> -----
>>>> Scanned for viruses, spam and offensive content by CensorNet MailSafe
>>>>
>>>> Try CensorNet free for 14 days. Provide Internet access on your terms.
>>>> Visit www.censornet.com for more information.
>>>>
>>>> _______________________________________________
>>>> krbdev mailing list             krbdev at mit.edu
>>>> https://mailman.mit.edu/mailman/listinfo/krbdev
>>>>
>>> Presumably your iteration count in this sample was 31.
>>> 3 of your 5 loss records are associated with calls to
>>> krb5_ktfile_resolve.  Calls to krb5_ktfile_resolve/krb5_kt_default
>>> should be balanced with calls to krb5_ktfile_close.
>>> The relevant logic is in krb5/src/lib/gssapi/krb5/acquire_cred.c
>>> so that's presumably where the missing krb5_ktfile_close call ought
>>> to be.
>>>
>>> Both your remaining loss records are directly from gssapi.
>>> specifically krb5_gss_acquire_cred.  It looks like calls to that
>>> should be paired up with calls to krb5_gss_release_cred.
>>> That could happen at the end of krb5_gss_accept_sec_context
>>> if verifier_cred_handle is passed as 0, otherwise, it looks like
>>> the application (squid?) should be responsible.
>>>
>>
>> This is a standalone application. All interaction with squid is via stdin 
>> (base64 encoded token) and stdout.
>>
>>
>>> Presumably the
>>> squid code should actually be calling gss_release_cred.
>>> It's possible there's a bug here in the MIT code, but it would be
>>> useful to first establish the credential isn't in fact being
>>> passed out to squid.
>>>
>>>
>>
>> I tested in the past several MIT/Heimdal versions on different Linux 
>> distributions. Some distribution have fixed MIT memory leaks others 
>> haven't. I think my squid_kerb_auth code is correct in freeing allocated 
>> memory (at least i have seen one or two Linux distributions e.g. centos 
>> which don't show leaks)
>>
>>
>>> -Marcus Watts
>>> _______________________________________________
>>> krbdev mailing list             krbdev at mit.edu
>>> https://mailman.mit.edu/mailman/listinfo/krbdev
>>>
>>>
>> Regards
>> Markus
>>
>> _______________________________________________
>> krbdev mailing list             krbdev at mit.edu
>> https://mailman.mit.edu/mailman/listinfo/krbdev
>>
>> ------------------------------------------------------------------------------------
>> Scanned for viruses, spam and offensive content by CensorNet MailSafe
>>
>> Try CensorNet free for 14 days. Provide Internet access on your terms.
>> Visit www.censornet.com for more information.
>>   ------------------------------------------------------------------------
>>
>>
>> No virus found in this incoming message.
>> Checked by AVG - www.avg.com Version: 9.0.704 / Virus Database: 
>> 270.14.60/2496 - Release Date: 11/11/09 07:40:00
>>
>>
>
>
> -- 
> Dan Searle
>
> CensorNet Ltd - professional & affordable Web & E-mail filtering
> email: dan.searle at censornet.com web: www.censornet.com
> tel: 0845 230 9590 / fax: 0845 230 9591 / support: 0845 230 9592
> snail: Vallon House, Vantage Court Office Park, Winterbourne,
>       Bristol, BS16 1GW, UK.
>
> CensorNet Ltd is a registered company in England & Wales No. 05518629
> VAT registration number 901-2048-78
> Any views expressed in this email communication are those of the
> individual sender, except where the sender specifically states them to
> be the views of a member of Censornet Ltd.  Censornet Ltd. does not
> represent, warrant or guarantee that the integrity of this
> communication has been maintained nor that the communication is free
> of errors or interference.
>
> ------------------------------------------------------------------------------------
> Scanned for viruses, spam and offensive content by CensorNet MailSafe
>
> Try CensorNet free for 14 days. Provide Internet access on your terms.
> Visit www.censornet.com for more information.
>
> 



From mdw at umich.edu  Thu Nov 12 19:48:37 2009
From: mdw at umich.edu (Marcus Watts)
Date: Thu, 12 Nov 2009 19:48:37 -0500
Subject: More memory leaks (1.6.4-beta1 release) 
In-Reply-To: <4AFC2761.9070102@censornet.com> 
References: <4AFAC2AD.5090505@censornet.com>
	<E1N8GYL-0005yn-Kd@bruson.ifs.umich.edu>
	<hdf8sr$5ua$1@ger.gmane.org> <4AFC2761.9070102@censornet.com>
Message-ID: <E1N8kL7-0007gY-RM@bruson.ifs.umich.edu>

Dan writes:
> Date:    Thu, 12 Nov 2009 15:18:57 GMT
> To:      Markus Moeller <huaraz at moeller.plus.com>
> cc:      krbdev at mit.edu
> From:    Dan Searle <dan.searle at censornet.com>
> Subject: Re: More memory leaks (1.6.4-beta1 release)
> 
> Hi guys,
> 
> I've managed to come up with a patch to the krb5-1.6.4-beta1 release 
> that fixes the critical still reachable memory leaks, please see the 
> attached file. I would appreciate comments as my "fixes" may have other 
> side effects I'm unaware of.
> 
> Regards, Dan...

At first blush, your patch has the right kind of logic in the right kinds
of places.  It's exactly the sort of patch to send in - most localized
fix & all. (except I'd omit the "#warning"s.)  But this does make a nice
example of how resource leakage happens.

src/lib/gssapi/krb5/acquire_cred.c
acquire_accept_cred()
Your code to fix the return at 196 is very like the logic
at lines 182-187.  Except you call kt_close in a different
order.  (At the least, I'd move that just for the sake
	of sanity).

<start coding style rant>

As a general result, I would try to code it this way:

	krb5_keytab kt = NULL;
	OM_uint32 result = GSS_S_FAILURE;
...
	if (((code = krb5_kt_get_entry(...
		*minor_status = ...
		result = GSS_S_CRED_UNAVAIL;
		goto fail;
...
	/* hooray.  we made it */
	cred->keytab = kt;
	kt = 0;
	result = GSS_S_COMPLETE;
fail:
	if (kt) krb5_kt_close(context, kt);
	return result;

By making sure all the code goes through the "fail" logic
at the end, and "hiding" resources that are passed elsewhere,
I can make sure that I only need one copy of "postlogue" code,
and I get greater assurance that my code won't leak in some
odd wonderful way I hadn't tested.

And then there's
src/lib/gssapi/krb5/accept_sec_context.c
krb5_gss_accept_sec_context()

This logic does have the common exit strategy - but as you found it
didn't help.  This code very likely has other problems - trivial example:
the return at 982 fails to free scratch like at line 989.
It could benefit from having separate "error" and "cleanup" labels,
and having fewer returns at the end.  This would not be a simple task.

<end coding style rant>

				-Marcus Watts

From tlyu at MIT.EDU  Fri Nov 13 00:21:49 2009
From: tlyu at MIT.EDU (Tom Yu)
Date: Fri, 13 Nov 2009 00:21:49 -0500
Subject: call for volunteers: the great reindent
Message-ID: <ldvy6mb3spe.fsf@cathode-dark-space.mit.edu>

As you might have noticed, we have embarked upon an effort to reindent
our source tree, as some people have remarked that inconsistencies in
the formatting of our source code pose a barrier to entry to new
developers.  If you are interested in helping with this effort, please
take a look at the procedures at this wiki page:

    http://k5wiki.kerberos.org/wiki/Coding_style/Reindenting

and sign up to help.  (You will need a wiki account to edit the page,
but anyone with a working e-mail address can register for an account.)

I am currently targeting November 30 as the deadline for the bulk
reindenting effort.  Please let me know if you find the instructions
to be unclear, or if that wiki page could use any other sort of
improvement.  Thanks.

-- 
Tom Yu
Development Team Leader
MIT Kerberos Consortium

From ghudson at MIT.EDU  Fri Nov 13 01:13:59 2009
From: ghudson at MIT.EDU (Greg Hudson)
Date: Fri, 13 Nov 2009 01:13:59 -0500
Subject: Namespaces and inter-library private symbols
In-Reply-To: <20091110214855.GI1105@Sun.COM>
References: <200911101908.nAAJ8IOj001536@outgoing.mit.edu>
	<20091110214855.GI1105@Sun.COM>
Message-ID: <1258092839.28600.178.camel@ray>

On Tue, 2009-11-10 at 16:48 -0500, Nicolas Williams wrote:
> Vendors should just not ship k5-int.h and that's that.  Developers
> should have enough warning from the fact that they cannot find C
> prototype declarations for functions that they think might be useful to
> them but which ware internal.

Jeff Altman wrote:
> Symbols that are exported by libraries are inevitably used even when
> they are declared private.  The only way to ensure that third parties
> do not place dependencies on a function is to not export it.

So, those are the two extremes.  I think if we name a function
krb5int_foo, that's a pretty clear indication that it's not part of the
stable API or ABI.  Adding an extra layer of hassle (such as the
accessor) isn't going to stop a truly determined application writer from
using internal functionality.

Merely failing to prototype a function in krb5.h is not, in my opinion,
a clear indication.  It also runs afoul of autoconf tests for functions
entering the public API in later versions of krb5.  For instance, Luke
chose not to make krb5_get_credentials_for_proxy part of the public API
for 1.8 so that we can retain the freedom to change it.  But suppose we
change the function signature and then make it part of the public API in
1.9.  How can an application tell whether krb5_get_credentials_for_proxy
is available in the API of the libkrb5 it is building against?  The
usual AC_CHECK_FUNC autoconf test will find the symbol in krb5 1.8, even
though it's not part of that version's API.

I am awaiting clarification on an offlist comment about the accessor,
and I'll probably bring this up again with the MIT staff, but my
expectation is that we will standardize on using exported symbols with
the krb5int_ prefix for tree-internal inter-library functions.

Nico wrote:
> I recommend that you concentrate efforts on actual, useful features
> and bug fixes over mass symbol rename excercises.

For the moment, I'm just interested in standardizing a practice for
future work, although it's possible we will rename some newer non-public
krb5_ symbols to krb5int_ to avoid the autoconf problem described above.



From Nicolas.Williams at sun.com  Fri Nov 13 11:43:02 2009
From: Nicolas.Williams at sun.com (Nicolas Williams)
Date: Fri, 13 Nov 2009 10:43:02 -0600
Subject: Namespaces and inter-library private symbols
In-Reply-To: <1258092839.28600.178.camel@ray>
References: <200911101908.nAAJ8IOj001536@outgoing.mit.edu>
	<20091110214855.GI1105@Sun.COM> <1258092839.28600.178.camel@ray>
Message-ID: <20091113164302.GS1105@Sun.COM>

On Fri, Nov 13, 2009 at 01:13:59AM -0500, Greg Hudson wrote:
> On Tue, 2009-11-10 at 16:48 -0500, Nicolas Williams wrote:
> > Vendors should just not ship k5-int.h and that's that.  Developers
> > should have enough warning from the fact that they cannot find C
> > prototype declarations for functions that they think might be useful to
> > them but which ware internal.
> 
> Jeff Altman wrote:
> > Symbols that are exported by libraries are inevitably used even when
> > they are declared private.  The only way to ensure that third parties
> > do not place dependencies on a function is to not export it.

If you don't declare them in public/installed/shipped headers, then they
can only be used by folks who are willing to dig into the source to find
declarations.  If you don't export them then they can't be used period.

I definitely recommend not exporting symbols that need not be used
outside libkrb5 (and plugins, via the accessor).

Are there symbols which must be exported but aren't public?  (What we
might call "consolidation private" or "contracted private" in the Sun
world of development).  If not, then I strongly recommend Jeff's
proposal.  If there are, can you remove or promote them all so that you
only have libkrb5-private and public interfaces only?

> So, those are the two extremes.  I think if we name a function

I fully agree with Jeff though, but only for symbols that are not
"contracted" to other parties (see above).

> krb5int_foo, that's a pretty clear indication that it's not part of the
> stable API or ABI.  Adding an extra layer of hassle (such as the
> accessor) isn't going to stop a truly determined application writer from
> using internal functionality.

To be clear, I don't _mind_ the 'int' suffix to the krb5 prefix.  I just
don't think it's necessary: either way you're relying on convention
(header naming vs. symbol naming) or on not making relevant declarations
available (by not installing/shipping k5-int.h) to get third parties to
stay away from private symbols.

> Merely failing to prototype a function in krb5.h is not, in my opinion,
> a clear indication.  It also runs afoul of autoconf tests for functions
> entering the public API in later versions of krb5.  For instance, Luke

It depends on the autoconf test.  If it's looking only for a symbol in a
shared object's exported symbol table, then yes, autoconf will find it,
but any source code actually trying to use it will fail to compile.

> chose not to make krb5_get_credentials_for_proxy part of the public API
> for 1.8 so that we can retain the freedom to change it.  But suppose we
> change the function signature and then make it part of the public API in
> 1.9.  How can an application tell whether krb5_get_credentials_for_proxy
> is available in the API of the libkrb5 it is building against?  The

It can't have used krb5_get_credentials_for_proxy when built against
1.8.

> usual AC_CHECK_FUNC autoconf test will find the symbol in krb5 1.8, even
> though it's not part of that version's API.
> 
> I am awaiting clarification on an offlist comment about the accessor,
> and I'll probably bring this up again with the MIT staff, but my
> expectation is that we will standardize on using exported symbols with
> the krb5int_ prefix for tree-internal inter-library functions.

The accessor is important for plug-in access (to public and private
interfaces both) as a way to avoid DLL hell.  I'm OK with the accessor
being used to access private functions, provided there's convenience
macros for using them (but then too you'll still be relying on
convention to keep third parties from using private interfaces).

> Nico wrote:
> > I recommend that you concentrate efforts on actual, useful features
> > and bug fixes over mass symbol rename excercises.
> 
> For the moment, I'm just interested in standardizing a practice for
> future work, although it's possible we will rename some newer non-public
> krb5_ symbols to krb5int_ to avoid the autoconf problem described above.

The autoconf problem is a non-problem.  The key, above all, is to not
install private headers while defining private symbols in private
headers.

C doesn't have a neat way to deal with private vs. public interfaces
other than by declaration segregation through headers.  That's the
least, and also the most that can be done.  The rest is lexical
convention -- how desirable that is will vary with your p.o.v., but it's
certainly not the main thing to do, nor does guarantee anything, it's
just convention.

Nico
-- 

From ghudson at MIT.EDU  Fri Nov 13 12:17:46 2009
From: ghudson at MIT.EDU (Greg Hudson)
Date: Fri, 13 Nov 2009 12:17:46 -0500
Subject: Namespaces and inter-library private symbols
In-Reply-To: <20091113164302.GS1105@Sun.COM>
References: <200911101908.nAAJ8IOj001536@outgoing.mit.edu>
	<20091110214855.GI1105@Sun.COM> <1258092839.28600.178.camel@ray>
	<20091113164302.GS1105@Sun.COM>
Message-ID: <1258132666.28600.207.camel@ray>

On Fri, 2009-11-13 at 11:43 -0500, Nicolas Williams wrote:
> Are there symbols which must be exported but aren't public?

Uh, yes.  The subject of this thread is "inter-library private symbols."
The opening message of this thread lists numerous examples of non-public
libkrb5 symbols used by other parts of the tree.  We have dozens and
dozens of cases where we currently do this.

Symbols used only within a library are easy to handle, and are not at
issue in this thread.

> It depends on the autoconf test.  If it's looking only for a symbol in a
> shared object's exported symbol table, then yes, autoconf will find it,
> but any source code actually trying to use it will fail to compile.

Source code typically does not fail to compile when using a
non-prototyped function; at most, you generally get a warning, and often
only with certain compiler flags.

The normal method of checking libraries for symbols in autoconf is to
attempt to link a program using that function (un-prototyped) and see if
you succeed, which is equivalent to looking for the symbol in the shared
object's exported symbol table.  There is no easy way to use autoconf
tests which check for a prototype, because there is no portable compiler
behavior for detecting the use of a non-prototyped function.

> The accessor is important for plug-in access (to public and private
> interfaces both) as a way to avoid DLL hell.

The accessor is only used for private interfaces, and use of the
accessor begins by invoking a private libkrb5 function
(krb5int_accessor), so I believe this explanation is incorrect.



From Nicolas.Williams at sun.com  Fri Nov 13 12:40:57 2009
From: Nicolas.Williams at sun.com (Nicolas Williams)
Date: Fri, 13 Nov 2009 11:40:57 -0600
Subject: Namespaces and inter-library private symbols
In-Reply-To: <1258132666.28600.207.camel@ray>
References: <200911101908.nAAJ8IOj001536@outgoing.mit.edu>
	<20091110214855.GI1105@Sun.COM> <1258092839.28600.178.camel@ray>
	<20091113164302.GS1105@Sun.COM> <1258132666.28600.207.camel@ray>
Message-ID: <20091113174057.GX1105@Sun.COM>

On Fri, Nov 13, 2009 at 12:17:46PM -0500, Greg Hudson wrote:
> On Fri, 2009-11-13 at 11:43 -0500, Nicolas Williams wrote:
> > Are there symbols which must be exported but aren't public?
> 
> Uh, yes.  The subject of this thread is "inter-library private symbols."

In my defense, I hadn't finished my morning coffee :(

> The opening message of this thread lists numerous examples of non-public
> libkrb5 symbols used by other parts of the tree.  We have dozens and
> dozens of cases where we currently do this.

Can you eliminate them?

> > It depends on the autoconf test.  If it's looking only for a symbol in a
> > shared object's exported symbol table, then yes, autoconf will find it,
> > but any source code actually trying to use it will fail to compile.
> 
> Source code typically does not fail to compile when using a
> non-prototyped function; at most, you generally get a warning, and often
> only with certain compiler flags.

Sorry, I think I'm assuming C99 too much.  But you could require C99...

> > The accessor is important for plug-in access (to public and private
> > interfaces both) as a way to avoid DLL hell.
> 
> The accessor is only used for private interfaces, and use of the
> accessor begins by invoking a private libkrb5 function
> (krb5int_accessor), so I believe this explanation is incorrect.

Why would the accessor have come to happen if there was already a
convention for private symbols?  I glanced last week and IIRC I saw only
accessor uses by plug-ins.  DLL hell avoidance immediately came to mind.
I think it's the most natural explanation.  You might have to ask
whoever added the accessor though.

Nico
-- 

From raeburn at MIT.EDU  Fri Nov 13 13:24:07 2009
From: raeburn at MIT.EDU (Ken Raeburn)
Date: Fri, 13 Nov 2009 13:24:07 -0500
Subject: Namespaces and inter-library private symbols
In-Reply-To: <20091113164302.GS1105@Sun.COM>
References: <200911101908.nAAJ8IOj001536@outgoing.mit.edu>
	<20091110214855.GI1105@Sun.COM> <1258092839.28600.178.camel@ray>
	<20091113164302.GS1105@Sun.COM>
Message-ID: <A7D8CC95-60D1-47B8-B6F5-E48BD1266DD7@mit.edu>

On Nov 13, 2009, at 11:43, Nicolas Williams wrote:
> If you don't declare them in public/installed/shipped headers, then  
> they
> can only be used by folks who are willing to dig into the source to  
> find
> declarations.  If you don't export them then they can't be used  
> period.

There are still C compilers that will silently assume an int-returning  
function of unspecified arguments, if it hasn't seen a declaration.   
If after looking at some of our sources to see how something was done,  
someone tries adding a call to their code and it compiles, they may  
not think about it any further.

On the other hand, an interface that requires the use of a structure  
that's not in the installed headers, that's a somewhat bigger stick to  
beat them over the head with.  If they are using our sources, they can  
grab the internal headers, but they know (better) that they're doing it.

> Are there symbols which must be exported but aren't public?  (What we
> might call "consolidation private" or "contracted private" in the Sun
> world of development).  If not, then I strongly recommend Jeff's
> proposal.  If there are, can you remove or promote them all so that  
> you
> only have libkrb5-private and public interfaces only?

I think there are things we're doing that we want to use in multiple  
places internally, but don't want to be stuck maintaining indefinitely  
for random programs that ought not to be messing around with such  
things.  For example, the "send a message to service X in realm Y and  
wait for a response" code, or the wrappers around mutexes, or our  
getaddrinfo wrapper.  Or anything that lets us peek at internal state  
for debugging, printing values for test vectors, etc.

Ken

From Nicolas.Williams at sun.com  Fri Nov 13 13:25:31 2009
From: Nicolas.Williams at sun.com (Nicolas Williams)
Date: Fri, 13 Nov 2009 12:25:31 -0600
Subject: Namespaces and inter-library private symbols
In-Reply-To: <4AFB7CFB.8040104@secure-endpoints.com>
References: <200911101908.nAAJ8IOj001536@outgoing.mit.edu>
	<4AFB7CFB.8040104@secure-endpoints.com>
Message-ID: <20091113182531.GY1105@Sun.COM>

On Wed, Nov 11, 2009 at 10:11:55PM -0500, Jeffrey Altman wrote:
> I don't remember the introduction of the accessors as having anything to
> do with Windows in particular.  The problem was the pollution of the
> export name space from shared libraries and the desire to be able to
> change the names and parameters of truly internal private functions that
> must be used by gssapi without being forced to change the signature of
> the of the library.

If a run-time linker encodes prototype information into its shared
object outputs, then I agree that exporting private symbols becomes a
problem, and the accessor is probably the best solution.

Nico
-- 

From ghudson at MIT.EDU  Fri Nov 13 16:49:30 2009
From: ghudson at MIT.EDU (Greg Hudson)
Date: Fri, 13 Nov 2009 16:49:30 -0500
Subject: Namespaces and inter-library private symbols
In-Reply-To: <20091113182531.GY1105@Sun.COM>
References: <200911101908.nAAJ8IOj001536@outgoing.mit.edu>
	<4AFB7CFB.8040104@secure-endpoints.com> <20091113182531.GY1105@Sun.COM>
Message-ID: <1258148970.28600.239.camel@ray>

On Fri, 2009-11-13 at 13:25 -0500, Nicolas Williams wrote:
> If a run-time linker encodes prototype information into its shared
> object outputs, then I agree that exporting private symbols becomes a
> problem, and the accessor is probably the best solution.

No, I think encoding prototype information into shared object outputs is
highly unusual.  What's possibly confusing you is that C compilers
typically allow an application to invoke a function with no prototype
information, and will simply assume that the function returns int and
needs no argument conversions.  (This is true of gcc even with -std=c99,
although that flag does cause gcc to issue a warning.)



From ghudson at MIT.EDU  Mon Nov 16 04:43:31 2009
From: ghudson at MIT.EDU (ghudson@MIT.EDU)
Date: Mon, 16 Nov 2009 04:43:31 -0500 (EST)
Subject: Sanity check: re-exporting krb5_auth_con_set_req_cksumtype
Message-ID: <200911160943.nAG9hVQY004444@outgoing.mit.edu>

I'd like to re-export krb5_auth_con_set_req_cksumtype, and perhaps
krb5_auth_con_set_safe_cksumtype for parity.

These functions were prototyped in krb5 1.2, moved to #if KRB5_PRIVATE
in krb5 1.3, and moved out of krb5.h into k5-int.h in krb5 1.7.

set_req_cksumtype is used by kcmd.c to ensure compatibility with
pre-1.7 versions of the rlogin suite which did not correctly handle
keyed checksum types.  I can't find any uses of set_safe_cksumtype.

It's reasonable to use a private function in appl as long as appl is
bundled with the krb5 tree, but now that we're unbundling the
applications for 1.8 we need a cleaner layering.

From lukeh at padl.com  Mon Nov 16 05:04:26 2009
From: lukeh at padl.com (Luke Howard)
Date: Mon, 16 Nov 2009 11:04:26 +0100
Subject: Sanity check: re-exporting krb5_auth_con_set_req_cksumtype
In-Reply-To: <200911160943.nAG9hVQY004444@outgoing.mit.edu>
References: <200911160943.nAG9hVQY004444@outgoing.mit.edu>
Message-ID: <007896B3-7F47-469E-9C6A-23667B646F8C@padl.com>

Also, can we have some auth_con subkey accessors that return krb5_keys  
instead of krb5_keyblocks?

-- Luke

On 16/11/2009, at 10:43 AM, ghudson at MIT.EDU wrote:

> I'd like to re-export krb5_auth_con_set_req_cksumtype, and perhaps
> krb5_auth_con_set_safe_cksumtype for parity.
>
> These functions were prototyped in krb5 1.2, moved to #if KRB5_PRIVATE
> in krb5 1.3, and moved out of krb5.h into k5-int.h in krb5 1.7.
>
> set_req_cksumtype is used by kcmd.c to ensure compatibility with
> pre-1.7 versions of the rlogin suite which did not correctly handle
> keyed checksum types.  I can't find any uses of set_safe_cksumtype.
>
> It's reasonable to use a private function in appl as long as appl is
> bundled with the krb5 tree, but now that we're unbundling the
> applications for 1.8 we need a cleaner layering.
> _______________________________________________
> krbdev mailing list             krbdev at mit.edu
> https://mailman.mit.edu/mailman/listinfo/krbdev
>

--
www.padl.com | www.fghr.net


From ghudson at MIT.EDU  Mon Nov 16 05:55:33 2009
From: ghudson at MIT.EDU (Greg Hudson)
Date: Mon, 16 Nov 2009 05:55:33 -0500
Subject: Sanity check: re-exporting krb5_auth_con_set_req_cksumtype
In-Reply-To: <007896B3-7F47-469E-9C6A-23667B646F8C@padl.com>
References: <200911160943.nAG9hVQY004444@outgoing.mit.edu>
	<007896B3-7F47-469E-9C6A-23667B646F8C@padl.com>
Message-ID: <1258368933.24480.12.camel@ray>

On Mon, 2009-11-16 at 05:04 -0500, Luke Howard wrote:
> Also, can we have some auth_con subkey accessors that return krb5_keys  
> instead of krb5_keyblocks?

Yeah, I thought about doing that myself, to eliminate some unnecessary
key duplication in the GSSAPI code, but eventually settled on the side
of laziness.

Since we already have krb5_key reference counting, the hardest part is
choosing names, since we can't rename the old functions to say
"keyblock" instead of "key".  Perhaps appending _k to the original
functions would be sufficiently evocative:

  krb5_auth_con_getkey_k
  krb5_auth_con_getsendsubkey_k
  krb5_auth_con_getrecvsubkey_k



From jeremy.cunningham.hul4 at statefarm.com  Mon Nov 16 10:41:21 2009
From: jeremy.cunningham.hul4 at statefarm.com (Jeremy Cunningham)
Date: Mon, 16 Nov 2009 08:41:21 -0700
Subject: Demo tool
Message-ID: <146C378874046E4585902EAFCB8F058203EF957D@WPSC7330.OPR.STATEFARM.ORG>

I am grad student who is presenting to an undergrad class regarding
Kerberos though I am still in the process of learning about the product
myself.  Is there any type of demo tool I can show them that I can load
on my laptop?  

Thanks,
Jeremy

From hartmans at MIT.EDU  Mon Nov 16 14:48:33 2009
From: hartmans at MIT.EDU (Sam Hartman)
Date: Mon, 16 Nov 2009 14:48:33 -0500
Subject: Sanity check: re-exporting krb5_auth_con_set_req_cksumtype
In-Reply-To: <200911160943.nAG9hVQY004444@outgoing.mit.edu> (ghudson@mit.edu's
	message of "Mon\, 16 Nov 2009 04\:43\:31 -0500 \(EST\)")
References: <200911160943.nAG9hVQY004444@outgoing.mit.edu>
Message-ID: <tsl639az1wu.fsf@mit.edu>

I support exporting set_req_cksumtype but would rather not export
set_safe_cksumtype if we can avoid it.

From ghudson at MIT.EDU  Mon Nov 16 16:48:35 2009
From: ghudson at MIT.EDU (ghudson@MIT.EDU)
Date: Mon, 16 Nov 2009 16:48:35 -0500 (EST)
Subject: gssftpd and gss_acquire_cred
Message-ID: <200911162148.nAGLmZOp025638@outgoing.mit.edu>

gssftpd (and maybe also telnetd) calls gss_acquire_cred to get a
credential to pass to gss_accept_sec_context.  It uses the local
hostname as determined by gethostbyname on the result of gethostname,
and as a consequence won't work for any hostnames other than what it
sees as canonical, even if it has keytab keys for other names.

My understanding is that stock OpenSSH sshd does the same thing,
although if you have Simon's gss-keyex patch you can affect that
behavior by turning off GSSAPIStrictAcceptorCheck (default is to the
old behavior).

I've seen multiple claims that server apps should generally not use
acquire_cred and should just pass GSS_C_NO_CREDENTIAL to
accept_sec_context.  Correspondingly, I've heard claims that the
GSSAPIStrictAcceptorCheck variable in Simon's patch is needless
conservatism and that there's no reason anyone would want the default
setting (on).

My one concern is that without acquiring a credential, a custom-coded
client could use, say, an HTTP/hostname ticket to authenticate to the
ftpd service, if both keys live in the same keytab.  In some exotic
cases (such as proxied credentials, or forensic analysis of KDC logs)
that could be considered a security issue.  I'm willing to disregard
that issue as not compelling enough to outweight the usability issues
associated with hosts with multiple A records, but it seems worth at
least thinking about.

Opinions?  Also, telnetd does something similar in telnetd/spx.c
(although it uses only gethostname to determine the hostname to use,
no gethostbyname call), but I don't know whether that code is actually
used; information on that would be appreciated.

From lha at kth.se  Mon Nov 16 19:58:35 2009
From: lha at kth.se (=?iso-8859-1?Q?Love_H=F6rnquist_=C5strand?=)
Date: Mon, 16 Nov 2009 16:58:35 -0800
Subject: gssftpd and gss_acquire_cred
In-Reply-To: <200911162148.nAGLmZOp025638@outgoing.mit.edu>
References: <200911162148.nAGLmZOp025638@outgoing.mit.edu>
Message-ID: <C48924B2-51F5-4B7B-BB99-65370A052C05@kth.se>

If you care about the name, check service afterward.

The server probably doesn't know all names the kdc have given it though aliases.

gethostname() doesn't return a useful name that use useful in kerberos sense.

Love

16 nov 2009 kl. 13:48 skrev ghudson at MIT.EDU:

> gssftpd (and maybe also telnetd) calls gss_acquire_cred to get a
> credential to pass to gss_accept_sec_context.  It uses the local
> hostname as determined by gethostbyname on the result of gethostname,
> and as a consequence won't work for any hostnames other than what it
> sees as canonical, even if it has keytab keys for other names.
> 
> My understanding is that stock OpenSSH sshd does the same thing,
> although if you have Simon's gss-keyex patch you can affect that
> behavior by turning off GSSAPIStrictAcceptorCheck (default is to the
> old behavior).
> 
> I've seen multiple claims that server apps should generally not use
> acquire_cred and should just pass GSS_C_NO_CREDENTIAL to
> accept_sec_context.  Correspondingly, I've heard claims that the
> GSSAPIStrictAcceptorCheck variable in Simon's patch is needless
> conservatism and that there's no reason anyone would want the default
> setting (on).
> 
> My one concern is that without acquiring a credential, a custom-coded
> client could use, say, an HTTP/hostname ticket to authenticate to the
> ftpd service, if both keys live in the same keytab.  In some exotic
> cases (such as proxied credentials, or forensic analysis of KDC logs)
> that could be considered a security issue.  I'm willing to disregard
> that issue as not compelling enough to outweight the usability issues
> associated with hosts with multiple A records, but it seems worth at
> least thinking about.
> 
> Opinions?  Also, telnetd does something similar in telnetd/spx.c
> (although it uses only gethostname to determine the hostname to use,
> no gethostbyname call), but I don't know whether that code is actually
> used; information on that would be appreciated.
> _______________________________________________
> krbdev mailing list             krbdev at mit.edu
> https://mailman.mit.edu/mailman/listinfo/krbdev


From kenh at cmf.nrl.navy.mil  Mon Nov 16 20:11:13 2009
From: kenh at cmf.nrl.navy.mil (Ken Hornstein)
Date: Mon, 16 Nov 2009 20:11:13 -0500
Subject: gssftpd and gss_acquire_cred
In-Reply-To: <200911162148.nAGLmZOp025638@outgoing.mit.edu>
Message-ID: <200911170111.nAH1BDMw005516@hedwig.cmf.nrl.navy.mil>

>Opinions?  Also, telnetd does something similar in telnetd/spx.c
>(although it uses only gethostname to determine the hostname to use,
>no gethostbyname call), but I don't know whether that code is actually
>used; information on that would be appreciated.

For telnetd the code you care about is in libtelnet/kerberos5.c; the
code in spx.c is not used AFAIK.

ftpd is the only application server shipped with MIT Kerberos that
does this canonical name check; it's been a giant pain in the ass
for nearly forever.  We have a local patch which does a getsockname()
on the connection socket, but I've come to the conclusion that it's more
trouble than it's worth and GSS_C_NO_CREDENTIAL is easier.  Yes, there's
a slim possibility of a security vulnerability in some weird corner cases,
but IMHO those potential problems are not worth the impact to usability.

And Greg ... if you're really up for fixing long-standing multihomed
bugs with MIT Kerberos, I don't suppose you're willing to look at
password changing, are you?  That's been broken for nearly forever
as well (well, I suppose it's more hits you if you're behind a NAT);
I can supply gory details if you're interested.

--Ken

From tlyu at MIT.EDU  Mon Nov 16 20:24:28 2009
From: tlyu at MIT.EDU (Tom Yu)
Date: Mon, 16 Nov 2009 20:24:28 -0500
Subject: gssftpd and gss_acquire_cred
In-Reply-To: <200911170111.nAH1BDMw005516@hedwig.cmf.nrl.navy.mil> (Ken
	Hornstein's message of "Mon, 16 Nov 2009 20:11:13 -0500")
References: <200911170111.nAH1BDMw005516@hedwig.cmf.nrl.navy.mil>
Message-ID: <ldvaaym3pv7.fsf@cathode-dark-space.mit.edu>

Ken Hornstein <kenh at cmf.nrl.navy.mil> writes:

>>Opinions?  Also, telnetd does something similar in telnetd/spx.c
>>(although it uses only gethostname to determine the hostname to use,
>>no gethostbyname call), but I don't know whether that code is actually
>>used; information on that would be appreciated.
>
> For telnetd the code you care about is in libtelnet/kerberos5.c; the
> code in spx.c is not used AFAIK.
>
> ftpd is the only application server shipped with MIT Kerberos that
> does this canonical name check; it's been a giant pain in the ass
> for nearly forever.  We have a local patch which does a getsockname()
> on the connection socket, but I've come to the conclusion that it's more
> trouble than it's worth and GSS_C_NO_CREDENTIAL is easier.  Yes, there's
> a slim possibility of a security vulnerability in some weird corner cases,
> but IMHO those potential problems are not worth the impact to usability.
>
> And Greg ... if you're really up for fixing long-standing multihomed
> bugs with MIT Kerberos, I don't suppose you're willing to look at
> password changing, are you?  That's been broken for nearly forever
> as well (well, I suppose it's more hits you if you're behind a NAT);
> I can supply gory details if you're interested.

As I recall, the kpasswd situation runs up against the hard wall of
KRB_PRIV requiring addresses.  There are (in RFC 4120) "directional"
addresses but there is no obvious (at least to me) way to negotiate
them.  If you have suggestions of how to backward-compatibly negotiate
the use of directional addresses, I'd love to hear about it.
Convincing arguments about the safety of forgoing the address checks
in the kpasswd case are also welcome.

From kenh at cmf.nrl.navy.mil  Mon Nov 16 21:36:37 2009
From: kenh at cmf.nrl.navy.mil (Ken Hornstein)
Date: Mon, 16 Nov 2009 21:36:37 -0500
Subject: gssftpd and gss_acquire_cred
In-Reply-To: <ldvaaym3pv7.fsf@cathode-dark-space.mit.edu>
Message-ID: <200911170236.nAH2abSQ006400@hedwig.cmf.nrl.navy.mil>

>As I recall, the kpasswd situation runs up against the hard wall of
>KRB_PRIV requiring addresses.  There are (in RFC 4120) "directional"
>addresses but there is no obvious (at least to me) way to negotiate
>them.  If you have suggestions of how to backward-compatibly negotiate
>the use of directional addresses, I'd love to hear about it.

Well, since password-changing is semi-broken right now, I'm not sure
much negotiation is needed :-/

But seriously, it seems that there are a few obvious solutions:

- On the client side, try it with directional addresses; if you get the
  "Incorrect net address" error, fall back to regular IP addresses.

- On the server, accept either.

>Convincing arguments about the safety of forgoing the address checks
>in the kpasswd case are also welcome.

Honestly, that's what I do.  It has the added advantage of being a lot
less code.

In terms of a reflection attack, the change-pw payload includes an
AP-REQ for client->server and an AP-REP for the reply.  I cannot
see a meaningful way for a reflection attack to succeed, but I'm willing
to be proven wrong.

--Ken

From rra at stanford.edu  Mon Nov 16 21:56:43 2009
From: rra at stanford.edu (Russ Allbery)
Date: Mon, 16 Nov 2009 18:56:43 -0800
Subject: gssftpd and gss_acquire_cred
In-Reply-To: <200911170236.nAH2abSQ006400@hedwig.cmf.nrl.navy.mil> (Ken
	Hornstein's message of "Mon, 16 Nov 2009 21:36:37 -0500")
References: <200911170236.nAH2abSQ006400@hedwig.cmf.nrl.navy.mil>
Message-ID: <87aayl3llg.fsf@windlord.stanford.edu>

Ken Hornstein <kenh at cmf.nrl.navy.mil> writes:

>>Convincing arguments about the safety of forgoing the address checks
>>in the kpasswd case are also welcome.

> Honestly, that's what I do.  It has the added advantage of being a lot
> less code.

I suggest checking how many large Kerberos sites have a web site where
users can change passwords.  I bet it's a lot of them (I know we have one,
as do most of the peer institutions I've talked to).  None of them are
doing Kerberos-style IP checking, and I bet at most of those sites that's
how all the regular users change their passwords.

I think you'll find that most deployments have, in effect, turned off
address checking already.

-- 
Russ Allbery (rra at stanford.edu)             <http://www.eyrie.org/~eagle/>

From jhutz at cmu.edu  Mon Nov 16 23:07:51 2009
From: jhutz at cmu.edu (Jeffrey Hutzelman)
Date: Mon, 16 Nov 2009 23:07:51 -0500
Subject: gssftpd and gss_acquire_cred
In-Reply-To: <22885_1258419581_nAH0xeKg028844_C48924B2-51F5-4B7B-BB99-65370A052C05@kth.se>
References: <200911162148.nAGLmZOp025638@outgoing.mit.edu>
	<22885_1258419581_nAH0xeKg028844_C48924B2-51F5-4B7B-BB99-65370A052C05@kth.se>
Message-ID: <DC864884B57A7787C13BB455@atlantis.pc.cs.cmu.edu>

--On Monday, November 16, 2009 04:58:35 PM -0800 Love H?rnquist ?strand 
<lha at kth.se> wrote:

> If you care about the name, check service afterward.
>
> The server probably doesn't know all names the kdc have given it though
> aliases.
>
> gethostname() doesn't return a useful name that use useful in kerberos
> sense.

Agree.  Please, help stamp out this broken behavior.

-- Jeff


From jmontmartin at gmail.com  Tue Nov 17 05:35:14 2009
From: jmontmartin at gmail.com (Julien Montmartin)
Date: Tue, 17 Nov 2009 11:35:14 +0100
Subject: Can't find kfw-3.2.3 sources
Message-ID: <a27fd8fe0911170235r443d4d24mcf279b8484f76369@mail.gmail.com>

Hello,

I've some trouble with gss_acquire_cred(), it keeps saying "No principal in
keytab matches desired name" and I can't figure out what the problem is...
To understand what's going on, I'd like to explore it with the debugger...

My application link with the kfw-3.2.3 package I took here :
http://web.mit.edu/Kerberos/dist/kfw/3.2/kfw-3.2.3-alpha1/ but I can't find
the appropriate sources. Does someone know where I can find them ?


Julien

From lukeh at padl.com  Tue Nov 17 12:56:13 2009
From: lukeh at padl.com (Luke Howard)
Date: Tue, 17 Nov 2009 18:56:13 +0100
Subject: IAKERB
Message-ID: <08F81530-D422-4616-AA54-2FC60A0750B8@padl.com>

I'm pleased to announce an IAKERB implementation for MIT Kerberos:

	http://k5wiki.kerberos.org/wiki/Projects/IAKERB

IAKERB allows clients that cannot reach a KDC to proxy credentials  
acquisition via a GSS exchange with a service. This should reduce the  
dependence on protocols such as NTLM and Digest outside the firewall.

-- Luke

From hartmans at MIT.EDU  Tue Nov 17 14:41:02 2009
From: hartmans at MIT.EDU (Sam Hartman)
Date: Tue, 17 Nov 2009 14:41:02 -0500
Subject: gssftpd and gss_acquire_cred
In-Reply-To: <200911170236.nAH2abSQ006400@hedwig.cmf.nrl.navy.mil> (Ken
	Hornstein's message of "Mon\, 16 Nov 2009 21\:36\:37 -0500")
References: <200911170236.nAH2abSQ006400@hedwig.cmf.nrl.navy.mil>
Message-ID: <tsld43hvt0x.fsf@mit.edu>

>>>>> "Ken" == Ken Hornstein <kenh at cmf.nrl.navy.mil> writes:


    Ken> - On the server, accept either.

Or ignore the address check entirely.  For the kpasswd service,
although not in general, it would be safe to do this.  The requirement
for directional addresses is to avoid replays with direction switched.
I'm fairly sure the kpasswd protocols are not vulnerable to that.

From hartmans at MIT.EDU  Tue Nov 17 14:43:46 2009
From: hartmans at MIT.EDU (Sam Hartman)
Date: Tue, 17 Nov 2009 14:43:46 -0500
Subject: gssftpd and gss_acquire_cred
In-Reply-To: <C48924B2-51F5-4B7B-BB99-65370A052C05@kth.se> ("Love
	=?iso-8859-1?Q?H=F6rnquist_=C5strand=22's?= message of "Mon\,
	16 Nov 2009 16\:58\:35 -0800")
References: <200911162148.nAGLmZOp025638@outgoing.mit.edu>
	<C48924B2-51F5-4B7B-BB99-65370A052C05@kth.se>
Message-ID: <tsl8we5vswd.fsf@mit.edu>

>>>>> "Love" == Love H?rnquist ?strand <lha at kth.se> writes:

    Love> If you care about the name, check service afterward.  
    Love> The
    Love> server probably doesn't know all names the kdc have given it
    Love> though aliases.

This is not an issue for MIT Kerberos > 1.7.  We use the name from the
key we matched and ignore the name in the ticket.

From ghudson at MIT.EDU  Tue Nov 17 15:51:09 2009
From: ghudson at MIT.EDU (ghudson@MIT.EDU)
Date: Tue, 17 Nov 2009 15:51:09 -0500 (EST)
Subject: Crypto IOV/non-IOV code consolidation
Message-ID: <200911172051.nAHKp9NO003354@outgoing.mit.edu>

There is a lot of code duplication in libk5crypto right now for three
reasons:

  1. The IOV code was added in in parallel to the existing code,
     duplicating much of the non-IOV code.

  2. The AES derived-key code was added in in parallel to the existing
     DES3 derived-key key, duplicating much of it.  (Only for the
     normal path, though; the IOV implementation factors out the
     differing code.)

  3. Encryption and decryption code commonly does a lot of the same
     derived-key logic.  I don't plan to do anything about that at
     this time, but it does add another factor of two.

As a result, you can run across the same bit of logic as many as six
times while traversing the library.

The simplest starting point would be to take advantage of the existing
hatch in krb5_k_encrypt, which invokes krb5int_c_encrypt_aead_compat
if the enctype entry has no encrypt function (and likewise for
decryption).  That would allow us to eliminate the non-IOV encryption
code.

Tom has expressed concerns about the extra copying in the aead_compat
functions resulting from the IOV code assuming in-place encryption and
decryption.  I am not certain whether these copies have a significant
impact on performance, but I believe we can eliminate the need for
them by using a unified internal interface which would look a bit
like:

    krb5_error_code (*encrypt)(<pointers to providers>,
                               krb5_key key, krb5_keyusage keyusage,
                               krb5_data *ivec,
                               krb5_crypto_iov *input, krb5_crypto_iov *output,
                               size_t num_data);

(And similarly for decrypt.)  The IOV interfaces would pass the same
iov pointer for input and output.  The non-IOV interfaces would
construct separate fixed-length iovs for input and output.

I'm hoping to find time to do this bit of code reorg.  Some notes:

* The input and output iov structures aren't intrinsically parallel;
  the ciphertext contains a header, padding, and trailer while the
  plaintext is only data.  At this point I don't know whether the
  non-IOV APIs will construct plaintext IOV structures containing
  dummy header/padding/trailer entries so that the input and output
  have a 1:1 correspondence.

* krb5int_c_iov_{get,put}_block (internal functions used by the
  enc_provider implementations) will need some massaging.

* I'd like to eliminate the aead_provider structure at the same time,
  since it is confusing to have provider structures at two different
  levels of abstraction.  Since krb5int_dk_encrypt_iov needs to be
  polymorphic in which crypto_length function it calls, the enctype
  encrypt/decrypt functions will probably just receive a pointer to
  the enctype entry instead of the enc/hash/aead providers, and the
  crypto_length function will move from aead_provider to the enctype
  table.

* Another bit of grossness is that gss-krb5 calls into krb5int_hmac,
  passing a pointer to the RC4 enc_provider and the MD5 hash_provider.
  (All three symbols are obtained via krb5int_accessor.)  I need to
  take a good hard look at that to see whether it can be cleaned up.
  At a minimum it will need to be adjusted since the non-IOV functions
  it relies on will be going away.

From tsitkova at MIT.EDU  Tue Nov 17 16:02:26 2009
From: tsitkova at MIT.EDU (Zhanna Tsitkova)
Date: Tue, 17 Nov 2009 16:02:26 -0500
Subject: yarrow/prng - option to bypass
Message-ID: <5D72EA5D-9F11-46C4-8528-FE7BB8DFE798@mit.edu>

Hello,
I would like to bring up an idea  for the bypass of the native kerb  
yarrow impl and allow appls to use an alternative sources of  
randomness when is it desirable. The potential beneficiaries  of this  
option are mobile devices that want to use the single source of  
randomness and  systems that already use yarrow and  are forced to  
duplicate an effort in kerb framework.
Two approaches are possible: not build krb yarrow at all or bypass it  
at the run time. In any case the native kerberos yarrow impl must be  
default prng.

Opinions, ideas, comcerns?

Thanks,
Zhanna






From lha at kth.se  Tue Nov 17 16:43:02 2009
From: lha at kth.se (=?iso-8859-1?Q?Love_H=F6rnquist_=C5strand?=)
Date: Tue, 17 Nov 2009 13:43:02 -0800
Subject: gssftpd and gss_acquire_cred
In-Reply-To: <tsl8we5vswd.fsf@mit.edu>
References: <200911162148.nAGLmZOp025638@outgoing.mit.edu>
	<C48924B2-51F5-4B7B-BB99-65370A052C05@kth.se> <tsl8we5vswd.fsf@mit.edu>
Message-ID: <EEBA0CBA-E190-47BD-92F3-76C7BABD142E@kth.se>


17 nov 2009 kl. 11:43 skrev Sam Hartman:

>>>>>> "Love" == Love H?rnquist ?strand <lha at kth.se> writes:
> 
>    Love> If you care about the name, check service afterward.  
>    Love> The
>    Love> server probably doesn't know all names the kdc have given it
>    Love> though aliases.
> 
> This is not an issue for MIT Kerberos > 1.7.  We use the name from the
> key we matched and ignore the name in the ticket.

So then all application needs to be aware what the admin stuff into the keytab ? Same problem different scale.

Love




From hartmans-ietf at MIT.EDU  Tue Nov 17 16:50:37 2009
From: hartmans-ietf at MIT.EDU (Sam Hartman)
Date: Tue, 17 Nov 2009 16:50:37 -0500
Subject: A couple of notes about the FAST negotiation proposal
Message-ID: <tslzl6kvn0y.fsf@mit.edu>



At the working group meeting, I presented a proposal Larry made for
FAST negotiation.

As I've started to design an implementation of this proposal, I've run
into a couple of things that don't work as well as one might hope.

First, some KDCs (including MIT prior to 1.7 among others) will return
KDC_ERR_PREAUTH_FAILED not KDC_ERR_PREAUTH_REQUIRED if you have a
principal requiring pre-authentication and send a request that
includes padata but for which all the padata types are unknown to the
KDC.

The work around is to try again without including the negotiation hint
if you get PREAUTH_FAILED and if you otherwise would accept
PREAUTH_REQUIRED.  Naturally, if the ticket flag is set, you fail the
request because the padata is not unknown.  We should also require
that KDCs implementing this extension completely ignore unknown
padata.  (I think the preauth framework already does this).

The second issue surrounds cross-realm armor tickets.  These can come
up because you have a host key as an armor ticket and because a user
from another realm is logging in.  When Larry and I proposed the
negotiation proposal, I think we assumed it would be an AS-REQ
proposal.  However to handle the TGS-REQ case you end up needing to figure out whether each successive KDC supports FAST.
Note that here, we're talking about getting an armor ticket to be used in AS-REQ processing later, *not* the unrelated question of determining whether FAST can be used to protect a TGS request.

Here's an example.

alice at EXAMPLE.COM logs into a BOSTON.EXAMPLE.COM machine.
Her machine has a BOSTON.EXAMPLE.COM armor ticket.
It can use that to obtain a cross-realm ticket to use for FAST armor with the EXAMPLE.COM KDCS.

I can see a couple of approaches:

* Permit the form of negotiation I discussed last week for both AS and TGS
* Use FAST to protect the negotiation.

If FAST is used, you need to either:
* use krbtgt/EXAMPLE.COM at EXAMPLE.COM not krbtgt/EXAMPLE.COM at BOSTON.EXAMPLE.COM as an armor ticket so you actually talk to the EXAMPLE.COM KDCs and can figure out what they support
* Otherwise talk to the EXAMPLE.COM KDCs.

Thoughts?

From hartmans at MIT.EDU  Tue Nov 17 16:53:23 2009
From: hartmans at MIT.EDU (Sam Hartman)
Date: Tue, 17 Nov 2009 16:53:23 -0500
Subject: Confirming decision not to care about cross-realm armor for 1.8
Message-ID: <tslvdh8vmwc.fsf@mit.edu>



As you see from my message to ietf-krb-wg, cross-realm armor tickets
for FAST negotiation are a bit tricky.  My proposal is that we ignore
them for 1.8 and that we require FAST if the KDC we AS exchange with
to obtain the armor ticket supports FAST.

This isn't quite right for AD deployments, but I think we can evolve
our support as the standard evolves in the future.

--Sam

From lukeh at padl.com  Tue Nov 17 18:52:48 2009
From: lukeh at padl.com (Luke Howard)
Date: Wed, 18 Nov 2009 00:52:48 +0100
Subject: Crypto IOV/non-IOV code consolidation
In-Reply-To: <200911172051.nAHKp9NO003354@outgoing.mit.edu>
References: <200911172051.nAHKp9NO003354@outgoing.mit.edu>
Message-ID: <DC38EDE6-AD9B-4C75-A05A-431AEDAE138C@padl.com>

Whatever the details, I think this would be good to cleanup, and  
possibly at the GSS layer too.

-- Luke

From hartmans at MIT.EDU  Wed Nov 18 15:03:19 2009
From: hartmans at MIT.EDU (Sam Hartman)
Date: Wed, 18 Nov 2009 15:03:19 -0500
Subject: Crypto IOV/non-IOV code consolidation
In-Reply-To: <200911172051.nAHKp9NO003354@outgoing.mit.edu> (ghudson@mit.edu's
	message of "Tue\, 17 Nov 2009 15\:51\:09 -0500 \(EST\)")
References: <200911172051.nAHKp9NO003354@outgoing.mit.edu>
Message-ID: <tslws1nr46w.fsf@mit.edu>

I think this sounds like a great idea.


I think you may run into some trouble removing the copies in the
non-IOV case.  In particular, I think there are some cases besides
get_block and put_block that assume that the input and output are the
same.
Perhaps I'm wrong and it should certainly all be obvious.

From hartmans at MIT.EDU  Thu Nov 19 08:36:59 2009
From: hartmans at MIT.EDU (Sam Hartman)
Date: Thu, 19 Nov 2009 08:36:59 -0500
Subject: yarrow/prng - option to bypass
In-Reply-To: <5D72EA5D-9F11-46C4-8528-FE7BB8DFE798@mit.edu> (Zhanna Tsitkova's
	message of "Tue\, 17 Nov 2009 16\:02\:26 -0500")
References: <5D72EA5D-9F11-46C4-8528-FE7BB8DFE798@mit.edu>
Message-ID: <tsld43epres.fsf@mit.edu>

Help me understand the mobile device use case?  Is there a specific
mobile device you're thinking of?  If so, can you discuss details?

What would you do instead?

--Sam

From hartmans at MIT.EDU  Thu Nov 19 12:49:15 2009
From: hartmans at MIT.EDU (Sam Hartman)
Date: Thu, 19 Nov 2009 12:49:15 -0500 (EST)
Subject: krb5_k_make_checksum with 0 cksumtipe uses mandatory cksum type
Message-ID: <20091119174915.1FB294470@carter-zimmerman.suchdamage.org>

I've been annoyed once too many times by the fact that I have a key  and I want a checksum.
That should be one call; I should not have to call krb5int_c_mandatory_cksumtype and then check the return value.

So, I'm going to treat 0 cksumtype for krb5_k_make_cheksum as "use the mandatory cksumtype for this key."

This message serves as a call for objections.

From tsitkova at MIT.EDU  Thu Nov 19 13:23:35 2009
From: tsitkova at MIT.EDU (Zhanna Tsitkova)
Date: Thu, 19 Nov 2009 13:23:35 -0500
Subject: yarrow/prng - option to bypass
In-Reply-To: <tsld43epres.fsf@mit.edu>
References: <5D72EA5D-9F11-46C4-8528-FE7BB8DFE798@mit.edu>
	<tsld43epres.fsf@mit.edu>
Message-ID: <96205C0F-DB64-4D91-877D-55335244B94B@mit.edu>

On Nov 19, 2009, at 8:36 AM, Sam Hartman wrote:

> Help me understand the mobile device use case?  Is there a specific
> mobile device you're thinking of?  If so, can you discuss details?

Taking into account the limitations of the mob.dev/embedded systems in  
terms of memory, battery capacity etc one should think if some modules  
may be shared between various application sitting on the device. It is  
a general approach and PRNG seems to be a good candidate for this.  
Also, consider the case of prng optimization.
As for the question if I have a specific device in mind the answer is  
no. Having said that, I would like to point to the TeamF1 presentation  
@ KC conference slide" What?s Different About Embedded Kerberos?" that  
suggests that they do have proprietary PRNG outside the native  
Kerberos. If appropriate, and if secure and thread/fork safe, it could  
be used in place of native Kerb yarrow/prng.

> What would you do instead?
>
>
> --Sam

Consider an option to bypass yarrow in our code. The default should be  
use native kerberos yarrow

Thanks,
Zhanna







From hartmans at MIT.EDU  Thu Nov 19 13:48:11 2009
From: hartmans at MIT.EDU (Sam Hartman)
Date: Thu, 19 Nov 2009 13:48:11 -0500
Subject: yarrow/prng - option to bypass
In-Reply-To: <96205C0F-DB64-4D91-877D-55335244B94B@mit.edu> (Zhanna Tsitkova's
	message of "Thu\, 19 Nov 2009 13\:23\:35 -0500")
References: <5D72EA5D-9F11-46C4-8528-FE7BB8DFE798@mit.edu>
	<tsld43epres.fsf@mit.edu>
	<96205C0F-DB64-4D91-877D-55335244B94B@mit.edu>
Message-ID: <tslws1mnyfo.fsf@mit.edu>

>>>>> "Zhanna" == Zhanna Tsitkova <tsitkova at MIT.EDU> writes:

    Zhanna> On Nov 19, 2009, at 8:36 AM, Sam Hartman wrote:
    Zhanna>     Help me understand the mobile device use case?  Is
    Zhanna> there a specific mobile device you're thinking of?  If so,
    Zhanna> can you discuss details?


    Zhanna> Taking into account the limitations of the
    Zhanna> mob.dev/embedded systems in terms of memory, battery
    Zhanna> capacity etc one should think if some modules may be
    Zhanna> shared between various application sitting on the
    Zhanna> device. It is a general approach and PRNG seems to be a
    Zhanna> good candidate for this. Also, consider the case of prng
    Zhanna> optimization.  As for the question if I have a specific
    Zhanna> device in mind the answer is no.  Having said that, I
    Zhanna> would like to point to the TeamF1 presentation @ KC
    Zhanna> conference slide" What?s Different About Embedded
    Zhanna> Kerberos?" that suggests that they do have proprietary
    Zhanna> PRNG outside the native Kerberos. If appropriate, and if
    Zhanna> secure and thread/fork safe, it could be used in place of
    Zhanna> native Kerb yarrow /prng.

OK.  This makes sense.

So what you are saying above argues much more for something at build
time than at run time.  Also, what you're doing argues fairly strongly
for an interface that we expect vendors to replace.


So, I guess what I'd do here is develop an interface document
explaining what a vendor needed to do to plug in a new PRNG after
you're done making changes.  I think that's the only additional
deliverable I'd recommend over what you initially started with.

--Sam

From hartmans at painless-security.com  Thu Nov 19 14:49:04 2009
From: hartmans at painless-security.com (Sam Hartman)
Date: Thu, 19 Nov 2009 14:49:04 -0500 (EST)
Subject: Moving return_svr_referral_data after reply key generation
Message-ID: <20091119194904.6E1884898@carter-zimmerman.suchdamage.org>



Luke, is there any reason that return_svr_referral_data needs to be so
early?  Can I move it to after the call to kdc_fast_handle_reply_key
so I can include the fast negotiation stuff in the reply?

From lukeh at padl.com  Thu Nov 19 17:15:23 2009
From: lukeh at padl.com (Luke Howard)
Date: Thu, 19 Nov 2009 23:15:23 +0100
Subject: krb5_k_make_checksum with 0 cksumtipe uses mandatory cksum type
In-Reply-To: <20091119174915.1FB294470@carter-zimmerman.suchdamage.org>
References: <20091119174915.1FB294470@carter-zimmerman.suchdamage.org>
Message-ID: <60716A3F-C263-4907-944D-A5F13705389E@padl.com>


On 19/11/2009, at 6:49 PM, Sam Hartman wrote:

> I've been annoyed once too many times by the fact that I have a key   
> and I want a checksum.
> That should be one call; I should not have to call  
> krb5int_c_mandatory_cksumtype and then check the return value.
>
> So, I'm going to treat 0 cksumtype for krb5_k_make_cheksum as "use  
> the mandatory cksumtype for this key."

Hear, hear. The amount of times I've done that. And, to have to use an  
internal API to do this too...

-- Luke

From lukeh at padl.com  Thu Nov 19 17:17:33 2009
From: lukeh at padl.com (Luke Howard)
Date: Thu, 19 Nov 2009 23:17:33 +0100
Subject: Moving return_svr_referral_data after reply key generation
In-Reply-To: <20091119194904.6E1884898@carter-zimmerman.suchdamage.org>
References: <20091119194904.6E1884898@carter-zimmerman.suchdamage.org>
Message-ID: <A03BCDA5-CBEA-4C37-863F-6610654CA92C@padl.com>


On 19/11/2009, at 8:49 PM, Sam Hartman wrote:

>
>
> Luke, is there any reason that return_svr_referral_data needs to be so
> early?  Can I move it to after the call to kdc_fast_handle_reply_key
> so I can include the fast negotiation stuff in the reply?

I think you can move it anywhere you like (after the server is  
retrieved from the KDB, obviously).

There was something about this code that I was thinking about the  
other day, but I can't remember it right now. I don't think it was  
anything important.

-- Luke

From hotz at jpl.nasa.gov  Thu Nov 19 20:15:45 2009
From: hotz at jpl.nasa.gov (Henry B. Hotz)
Date: Thu, 19 Nov 2009 17:15:45 -0800
Subject: IAKERB
In-Reply-To: <mailman.633.1258563788.8683.krbdev@mit.edu>
References: <mailman.633.1258563788.8683.krbdev@mit.edu>
Message-ID: <1D28DFFB-FC07-4D2B-8A4F-968AD5648F2E@jpl.nasa.gov>


On Nov 18, 2009, at 9:03 AM, krbdev-request at mit.edu wrote:

> I'm pleased to announce an IAKERB implementation for MIT Kerberos:
> 
> 	http://k5wiki.kerberos.org/wiki/Projects/IAKERB
> 
> IAKERB allows clients that cannot reach a KDC to proxy credentials  
> acquisition via a GSS exchange with a service. This should reduce the  
> dependence on protocols such as NTLM and Digest outside the firewall.

I applaud the availability of a solution.  I bemoan the widespread, naive use of firewalls that creates the problem in the first place.  *sigh*

------------------------------------------------------
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 hartmans at MIT.EDU  Fri Nov 20 12:16:37 2009
From: hartmans at MIT.EDU (Sam Hartman)
Date: Fri, 20 Nov 2009 12:16:37 -0500 (EST)
Subject: Fast Negotiation: renewed and validated credentials
Message-ID: <20091120171637.5E21D48A3@carter-zimmerman.suchdamage.org>

I've discovered another problem; comments greatly appreciated.
This is from the wiki writeup:
Another complexity is handling of renewed and validated credentials.   Currently, the APIs for handling renewal and credential validation take a ccache, but do not write credentials out to the ccache.  Since there is no API documentation it's not clear what behavior changes are acceptable.  For a program today that runs the renewal and then replaces the credentials in the cache, writing out the credentials would be a no-op.  For a program that expects credentials unrelated to the renewal to remain in the cache and be undisturbed, that behavior change would be significant. Another approach might be to preserve set_config state across calls to krb5_cc_initialize.  That should not affect existing code, although it would make it difficult to unset configuration state in a ccache.


From lukeh at padl.com  Fri Nov 20 03:53:30 2009
From: lukeh at padl.com (Luke Howard)
Date: Fri, 20 Nov 2009 09:53:30 +0100
Subject: IAKERB
In-Reply-To: <1D28DFFB-FC07-4D2B-8A4F-968AD5648F2E@jpl.nasa.gov>
References: <mailman.633.1258563788.8683.krbdev@mit.edu>
	<1D28DFFB-FC07-4D2B-8A4F-968AD5648F2E@jpl.nasa.gov>
Message-ID: <2E2AA524-F6F1-4777-8E08-33895F96226F@padl.com>


On 20/11/2009, at 2:15 AM, Henry B. Hotz wrote:

>
> On Nov 18, 2009, at 9:03 AM, krbdev-request at mit.edu wrote:
>
>> I'm pleased to announce an IAKERB implementation for MIT Kerberos:
>>
>> 	http://k5wiki.kerberos.org/wiki/Projects/IAKERB
>>
>> IAKERB allows clients that cannot reach a KDC to proxy credentials
>> acquisition via a GSS exchange with a service. This should reduce the
>> dependence on protocols such as NTLM and Digest outside the firewall.
>
> I applaud the availability of a solution.  I bemoan the widespread,  
> naive use of firewalls that creates the problem in the first place.   
> *sigh*

It sounds like it will be too late for 1.8, unfortunately, but I'd  
love to hear from anyone that has an opportunity to test it.

The gss-sample application has been updated; you can test it with the - 
iakerb and -user/-pass options to gss-client.

-- Luke

From ghudson at MIT.EDU  Fri Nov 20 13:13:31 2009
From: ghudson at MIT.EDU (Greg Hudson)
Date: Fri, 20 Nov 2009 13:13:31 -0500
Subject: Fast Negotiation: renewed and validated credentials
In-Reply-To: <20091120171637.5E21D48A3@carter-zimmerman.suchdamage.org>
References: <20091120171637.5E21D48A3@carter-zimmerman.suchdamage.org>
Message-ID: <1258740811.3094.81.camel@ray>

Let me elaborate on this a little bit for the sake of those not closely
following the project.

The point of FAST, as it currently exists in MIT krb5, is to protect
AS-REQs for password-based principals using an armor ticket.  The armor
ticket is typically obtained using a regular AS request for a different
principal such as a host principal, which is presumed to have a strong
key.

Sam's project implements a feature which allows a client to determine,
while obtaining the armor ticket, whether the KDC understands FAST.  The
plan is to store the result of this negotiation in the armor ticket's
ccache using krb5_cc_set_config.  (Another option would be to claim a
ticket flag for local use and set a flag on the TGT.  For the moment
that option is not on the table.)

A complication of this plan is that our APIs for getting credentials
currently return the credential without storing it in the ccache; the
ccache operations are performed by the caller (e.g. kinit).  For
krb5_get_init_creds_{password,keytab} it is relatively straightforward
to solve this, because the API is extensible.  The caller can provide a
ccache via a new API krb5_get_init_creds_opt_set_ccache, and we get to
remove ccache operations from kinit.

The issue at hand is: what if someone decides to renew an armor ticket,
or validate a post-dated armor ticket?  The APIs for renewal and
validation do not take extensible options structures--but they do take
ccaches.  Currently, those ccaches are basically read-only; the caller
(typically kinit) takes responsibility for re-initializing the ccache
and storing the renewed or validated TGT.  This process would obliterate
the FAST negotiation state.

The solutions on the table are:

  1. Change the behavior of krb5_get_credentials_renew and
krb5_get_credentials_validate to re-initialize the ccache and store the
new TGT there.  The theory is that in pretty much all use cases, we
imagine that the caller was going to do that anyway.

  2. Change the behavior of krb5_cc_initialize to preserve set_config
state, so that FAST negotiation state is preserved when the caller
reinitializes the ccache.

  3. Don't support renewal or validation of armor tickets.  This would
be acceptable for the typical expected use case (using a host key to
armor a user AS-REQ) but might constrain weirder use cases, such as
using an existing user TGT to armor a request for a new one shortly
before reaching the end of your renewal lifetime.  (This option was
presented by Sam over Jabber; he didn't mention it in his mail.)

One could also imagine creating extended variants of the renew and
validate APIs.

I am still thinking about which solution I prefer.




From paul.moore at centrify.com  Fri Nov 20 13:32:06 2009
From: paul.moore at centrify.com (Paul Moore)
Date: Fri, 20 Nov 2009 10:32:06 -0800
Subject: MIT Kerberos - FIPS Validation
In-Reply-To: <42553961FD54AE41BF83834CB917221F0313454598@w92expo2.exchange.mit.edu>
References: <e47324780909161147u12efb0c0r52e530e9c2a63e0d@mail.gmail.com>
	<42553961FD54AE41BF83834CB917221F0313454598@w92expo2.exchange.mit.edu>
Message-ID: <BB7E16A14DE689469A181EC770AFBF4D03E7E861@exch-one.centrify.com>

there are no details there regarding what plans you have for FIPS
compliance.

Can you please state

- exactly what bits you will have certified (if any) (specific
libraries, entire client side package, kdc, entire server side package,
...)
- what changes will be made to those bits in order to be compliant


-----Original Message-----
From: krbdev-bounces at mit.edu [mailto:krbdev-bounces at mit.edu] On Behalf
Of Zhanna Tsitkova
Sent: Wednesday, September 16, 2009 7:57 PM
To: Thomas Harning Jr.; krbdev at mit.edu
Subject: RE: MIT Kerberos - FIPS Validation

It is work in progress.  Please, see Crypto Modularity proj @
http://k5wiki.kerberos.org/wiki/Projects/Crypto_modularity 

Zhanna
________________________________________
From: krbdev-bounces at MIT.EDU [krbdev-bounces at MIT.EDU] On Behalf Of
Thomas Harning Jr. [thomas.harning at trustbearer.com]
Sent: Wednesday, September 16, 2009 2:47 PM
To: krbdev at mit.edu
Subject: MIT Kerberos - FIPS Validation

Just wondering, has there been any work to make a FIPS-validated MIT
Kerberos client implementation?

I'm guessing that there is some built-in crypto in MIT Kerberos, or do
I have that wrong?  If the crypto is not built-into MIT Kerberos
client, is it implemented by OpenSSL or some other cryptography
library?

--
Thomas Harning Jr.
_______________________________________________
krbdev mailing list             krbdev at mit.edu
https://mailman.mit.edu/mailman/listinfo/krbdev

_______________________________________________
krbdev mailing list             krbdev at mit.edu
https://mailman.mit.edu/mailman/listinfo/krbdev


From tlyu at MIT.EDU  Fri Nov 20 14:08:32 2009
From: tlyu at MIT.EDU (Tom Yu)
Date: Fri, 20 Nov 2009 14:08:32 -0500
Subject: MIT Kerberos - FIPS Validation
In-Reply-To: <BB7E16A14DE689469A181EC770AFBF4D03E7E861@exch-one.centrify.com>
	(Paul Moore's message of "Fri, 20 Nov 2009 13:32:06 -0500")
References: <e47324780909161147u12efb0c0r52e530e9c2a63e0d@mail.gmail.com>
	<42553961FD54AE41BF83834CB917221F0313454598@w92expo2.exchange.mit.edu>
	<BB7E16A14DE689469A181EC770AFBF4D03E7E861@exch-one.centrify.com>
Message-ID: <ldvbpixt3nz.fsf@cathode-dark-space.mit.edu>

Paul Moore <paul.moore at centrify.com> writes:

> there are no details there regarding what plans you have for FIPS
> compliance.
>
> Can you please state
>
> - exactly what bits you will have certified (if any) (specific
> libraries, entire client side package, kdc, entire server side package,
> ...)
> - what changes will be made to those bits in order to be compliant

As far as we can tell, having the entire MIT Kerberos source tree
FIPS-validated would be prohibitively expensive, so we decided to
pursue FIPS compliance by enabling the use of non-builtin crypto
libraries, which might be FIPS-validated, and not seeking FIPS
validation for the builtin crypto.  If this is not sufficient for your
use cases, would you please explain why in detail?

Also, it would help to know what FIPS 140-2 security level is needed,
and what additional regulations or standards are governing your use
cases.

The crypto modularity project will enable the use of crypto libraries
different from the built-in MIT Kerberos crypto libraries.  One result
is that a user or vendor can build MIT Kerberos using a non-builtin
(possibly platform-native) FIPS-validated crypto library, such as a
validated version of OpenSSL.

>
>
> -----Original Message-----
> From: krbdev-bounces at mit.edu [mailto:krbdev-bounces at mit.edu] On Behalf
> Of Zhanna Tsitkova
> Sent: Wednesday, September 16, 2009 7:57 PM
> To: Thomas Harning Jr.; krbdev at mit.edu
> Subject: RE: MIT Kerberos - FIPS Validation
>
> It is work in progress.  Please, see Crypto Modularity proj @
> http://k5wiki.kerberos.org/wiki/Projects/Crypto_modularity 
>
> Zhanna
> ________________________________________
> From: krbdev-bounces at MIT.EDU [krbdev-bounces at MIT.EDU] On Behalf Of
> Thomas Harning Jr. [thomas.harning at trustbearer.com]
> Sent: Wednesday, September 16, 2009 2:47 PM
> To: krbdev at mit.edu
> Subject: MIT Kerberos - FIPS Validation
>
> Just wondering, has there been any work to make a FIPS-validated MIT
> Kerberos client implementation?
>
> I'm guessing that there is some built-in crypto in MIT Kerberos, or do
> I have that wrong?  If the crypto is not built-into MIT Kerberos
> client, is it implemented by OpenSSL or some other cryptography
> library?
>
> --
> Thomas Harning Jr.
> _______________________________________________
> krbdev mailing list             krbdev at mit.edu
> https://mailman.mit.edu/mailman/listinfo/krbdev
>
> _______________________________________________
> krbdev mailing list             krbdev at mit.edu
> https://mailman.mit.edu/mailman/listinfo/krbdev
>
> _______________________________________________
> krbdev mailing list             krbdev at mit.edu
> https://mailman.mit.edu/mailman/listinfo/krbdev

From hartmans at MIT.EDU  Fri Nov 20 14:35:40 2009
From: hartmans at MIT.EDU (Sam Hartman)
Date: Fri, 20 Nov 2009 14:35:40 -0500
Subject: Fast Negotiation: renewed and validated credentials
In-Reply-To: <1258740811.3094.81.camel@ray> (Greg Hudson's message of "Fri\,
	20 Nov 2009 13\:13\:31 -0500")
References: <20091120171637.5E21D48A3@carter-zimmerman.suchdamage.org>
	<1258740811.3094.81.camel@ray>
Message-ID: <tsl6395kn03.fsf@mit.edu>

Greg, I really appreciate the excellent write-up.
>>>>> "Greg" == Greg Hudson <ghudson at MIT.EDU> writes:

    Greg> krb5_cc_set_config.  (Another option would be to claim a
    Greg> ticket flag for local use and set a flag on the TGT.  For
    Greg> the moment that option is not on the table.)
Let's put it on the table.
This is the second complexity we've run into because of the particular design choices I'm making.
In my mind, that means we should be thinking about alternatives.

I'd like to discuss the tradeoffs of the different options.
    Greg>   1. Change the behavior of krb5_get_credentials_renew and
    Greg> krb5_get_credentials_validate to re-initialize the ccache
    Greg> and store the new TGT there.  The theory is that in pretty
    Greg> much all use cases, we imagine that the caller was going to
    Greg> do that anyway.

This probably doesn't break existing code.  However, existing code
will not get the benefits of negotiation, because if the existing code
calls krb5_cc_initialize then the negotiation state will be
overwritten.

    Greg>   2. Change the behavior of krb5_cc_initialize to preserve
    Greg> set_config state, so that FAST negotiation state is
    Greg> preserved when the caller reinitializes the ccache.

I don't think this breaks anything existing.  It makes it more
difficult to unset an option set by krb5_cc_set_config.

    Greg>   3. Don't support renewal or validation of armor tickets.
    Greg> This would be acceptable for the typical expected use case
    Greg> (using a host key to armor a user AS-REQ) but might
    Greg> constrain weirder use cases, such as using an existing user
    Greg> TGT to armor a request for a new one shortly before reaching
    Greg> the end of your renewal lifetime.  (This option was
    Greg> presented by Sam over Jabber; he didn't mention it in his
    Greg> mail.)

Good summary there.

4. Use a ticket flag rather than krb5_cc_set_config to store state in the ccache.

One positive benefit is that it may be more clear how to handle the cross-realm armor ticket case I discussed on the working group list.

The main drawback is that it leaves us with a longer-term problem in
that the krb5_cc_set_config interface really isn't useful when
combined with renewal and validation.  We could decide that
krb5_cc_set_config is a bad idea, although to me, it seems like it has
significant potential future utility.

I think this option is by far the easiest  option to implement, although I think it doesn't give us as many options for future extensibility.

5. Extend krb5_get_renew_creds and krb5_get_validate_creds to create new APIs that take an output ccache.

This option has similar effects to option 1, without the possibility
of breaking existing code.  It's slightly more difficult to implement
than option 1, although I don't think implementation would be
difficult at all.

I'd recommend that we drop option 1 as option 5 seems superior with
the exception of API clutter.

My current favorite is option 2, because it means negotiation will
work with existing code and because it does not break code.  If needed
we can introduce an API that initializes a cache without maintaining
config state.

However option 3 is attractive in its simplicity.

From hartmans at MIT.EDU  Fri Nov 20 14:57:16 2009
From: hartmans at MIT.EDU (Sam Hartman)
Date: Fri, 20 Nov 2009 14:57:16 -0500
Subject: Fast Negotiation: renewed and validated credentials
In-Reply-To: <tsl6395kn03.fsf@mit.edu> (Sam Hartman's message of "Fri\,
	20 Nov 2009 14\:35\:40 -0500")
References: <20091120171637.5E21D48A3@carter-zimmerman.suchdamage.org>
	<1258740811.3094.81.camel@ray> <tsl6395kn03.fsf@mit.edu>
Message-ID: <tsl1vjtkm03.fsf@mit.edu>

So, I looked in more detail at krb5_cc_set_config.  I misread the API.
Storing the cross-realm negotiation information will not be a problem.
Thus one reason for preferring option 4 (ticket flag) over the other
options does not apply.

From paul.moore at centrify.com  Fri Nov 20 15:11:24 2009
From: paul.moore at centrify.com (Paul Moore)
Date: Fri, 20 Nov 2009 12:11:24 -0800
Subject: MIT Kerberos - FIPS Validation
In-Reply-To: <ldvbpixt3nz.fsf@cathode-dark-space.mit.edu>
References: <e47324780909161147u12efb0c0r52e530e9c2a63e0d@mail.gmail.com><42553961FD54AE41BF83834CB917221F0313454598@w92expo2.exchange.mit.edu><BB7E16A14DE689469A181EC770AFBF4D03E7E861@exch-one.centrify.com>
	<ldvbpixt3nz.fsf@cathode-dark-space.mit.edu>
Message-ID: <BB7E16A14DE689469A181EC770AFBF4D03E7E8D5@exch-one.centrify.com>

OK - thats a good plan then

so in fact MIT Kerberos would not be FIPS certified since it would
contain (or could) no crypto code

I had looked at making mit libcrypto compliant

-----Original Message-----
From: Tom Yu [mailto:tlyu at MIT.EDU] 
Sent: Friday, November 20, 2009 11:09 AM
To: Paul Moore
Cc: tsitkova at mit.edu; Thomas Harning Jr.; krbdev at mit.edu
Subject: Re: MIT Kerberos - FIPS Validation

Paul Moore <paul.moore at centrify.com> writes:

> there are no details there regarding what plans you have for FIPS
> compliance.
>
> Can you please state
>
> - exactly what bits you will have certified (if any) (specific
> libraries, entire client side package, kdc, entire server side
package,
> ...)
> - what changes will be made to those bits in order to be compliant

As far as we can tell, having the entire MIT Kerberos source tree
FIPS-validated would be prohibitively expensive, so we decided to
pursue FIPS compliance by enabling the use of non-builtin crypto
libraries, which might be FIPS-validated, and not seeking FIPS
validation for the builtin crypto.  If this is not sufficient for your
use cases, would you please explain why in detail?

Also, it would help to know what FIPS 140-2 security level is needed,
and what additional regulations or standards are governing your use
cases.

The crypto modularity project will enable the use of crypto libraries
different from the built-in MIT Kerberos crypto libraries.  One result
is that a user or vendor can build MIT Kerberos using a non-builtin
(possibly platform-native) FIPS-validated crypto library, such as a
validated version of OpenSSL.

>
>
> -----Original Message-----
> From: krbdev-bounces at mit.edu [mailto:krbdev-bounces at mit.edu] On Behalf
> Of Zhanna Tsitkova
> Sent: Wednesday, September 16, 2009 7:57 PM
> To: Thomas Harning Jr.; krbdev at mit.edu
> Subject: RE: MIT Kerberos - FIPS Validation
>
> It is work in progress.  Please, see Crypto Modularity proj @
> http://k5wiki.kerberos.org/wiki/Projects/Crypto_modularity 
>
> Zhanna
> ________________________________________
> From: krbdev-bounces at MIT.EDU [krbdev-bounces at MIT.EDU] On Behalf Of
> Thomas Harning Jr. [thomas.harning at trustbearer.com]
> Sent: Wednesday, September 16, 2009 2:47 PM
> To: krbdev at mit.edu
> Subject: MIT Kerberos - FIPS Validation
>
> Just wondering, has there been any work to make a FIPS-validated MIT
> Kerberos client implementation?
>
> I'm guessing that there is some built-in crypto in MIT Kerberos, or do
> I have that wrong?  If the crypto is not built-into MIT Kerberos
> client, is it implemented by OpenSSL or some other cryptography
> library?
>
> --
> Thomas Harning Jr.
> _______________________________________________
> krbdev mailing list             krbdev at mit.edu
> https://mailman.mit.edu/mailman/listinfo/krbdev
>
> _______________________________________________
> krbdev mailing list             krbdev at mit.edu
> https://mailman.mit.edu/mailman/listinfo/krbdev
>
> _______________________________________________
> krbdev mailing list             krbdev at mit.edu
> https://mailman.mit.edu/mailman/listinfo/krbdev


From ghudson at MIT.EDU  Fri Nov 20 23:45:40 2009
From: ghudson at MIT.EDU (ghudson@MIT.EDU)
Date: Fri, 20 Nov 2009 23:45:40 -0500 (EST)
Subject: Zapping memory and C++ compatibility
Message-ID: <200911210445.nAL4jeKY016987@outgoing.mit.edu>

Back in 2002 or so, people noticed that certain compilers (I think gcc
3.x and Visual C++) would sometimes optimize out a memset() which they
could prove doesn't affect the execution of the program according to
standardized behaviors (which doesn't include accessing stack garbage
or the contents of core dumps or anything of that sort).  So, there
was a lot of discussion about how to securely zero passwords or
cryptographic keys.

We had out own discussion, which you can review at
http://mailman.mit.edu/pipermail/krbdev/2002-November/000871.html.
The eventual upshot was this collection of macros or inlines:

Win32: #define krb5int_zap_data(ptr, len) SecureZeroMemory(ptr, len)
gcc:   static inline void krb5int_zap_data(void *ptr, size_t len) {
       memset(ptr, 0, len); asm volatile ("" : : "g" (ptr), "g" (len)); }
else:  #define krb5int_zap_data(ptr, len) memset((volatile void *)ptr, 0, len)

The last construction was based on the idea that a hypothetical
compiler might see the cast through volatile void * and decide not to
perform an optimization.  It's not clear to me how valid this
reasoning is, since neither the proximal type (after the implicit cast
to void * by the call to memset) nor the original type is volatile.

Today's problem is that the last construction isn't valid C++.  We
have a test case which tries passing k5-int.h through C++ compiler,
and it now fails on Solaris with the native compiler.  It didn't fail
before because the macro was never expanded within k5-int.h, but now
it gets expanded by the new zapfree() inline function.

So, I'm trying to figure out how to resolve this C++ compatibility
issue without raising the likelihood of an information leakage
vulnerability.  A possible choice is to make the macro more obviously
wishy-washy by explicitly casting ptr back to void *:

  memset((void *)(volatile void *)ptr, 0, len)

Anyway, advice appreciated if anyone on the list has expertise in this
issue.

From warlord at MIT.EDU  Sat Nov 21 07:51:16 2009
From: warlord at MIT.EDU (Derek Atkins)
Date: Sat, 21 Nov 2009 07:51:16 -0500
Subject: Zapping memory and C++ compatibility
In-Reply-To: <200911210445.nAL4jeKY016987@outgoing.mit.edu>
References: <200911210445.nAL4jeKY016987@outgoing.mit.edu>
Message-ID: <20091121075116.2kwxt1tsococgsw4@webmail.mit.edu>

I think the problem is that you cannot use a C-style cast to cast an
object to a void* pointer in C++.  You might need to use a 'static_cast'
to do so, which means you might need to do something like:

#ifdef __cplusplus
#define krb5int_zap_data(ptr, len) memset(static_cast<volatile void 
*>(ptr), 0,
len)
#else
#define krb5int_zap_data(ptr, len) memset((volatile void *)ptr, 0, len)
#endif

-derek

Quoting ghudson at MIT.EDU:

> Back in 2002 or so, people noticed that certain compilers (I think gcc
> 3.x and Visual C++) would sometimes optimize out a memset() which they
> could prove doesn't affect the execution of the program according to
> standardized behaviors (which doesn't include accessing stack garbage
> or the contents of core dumps or anything of that sort).  So, there
> was a lot of discussion about how to securely zero passwords or
> cryptographic keys.
>
> We had out own discussion, which you can review at
> http://mailman.mit.edu/pipermail/krbdev/2002-November/000871.html.
> The eventual upshot was this collection of macros or inlines:
>
> Win32: #define krb5int_zap_data(ptr, len) SecureZeroMemory(ptr, len)
> gcc:   static inline void krb5int_zap_data(void *ptr, size_t len) {
>       memset(ptr, 0, len); asm volatile ("" : : "g" (ptr), "g" (len)); }
> else:  #define krb5int_zap_data(ptr, len) memset((volatile void 
> *)ptr, 0, len)
>
> The last construction was based on the idea that a hypothetical
> compiler might see the cast through volatile void * and decide not to
> perform an optimization.  It's not clear to me how valid this
> reasoning is, since neither the proximal type (after the implicit cast
> to void * by the call to memset) nor the original type is volatile.
>
> Today's problem is that the last construction isn't valid C++.  We
> have a test case which tries passing k5-int.h through C++ compiler,
> and it now fails on Solaris with the native compiler.  It didn't fail
> before because the macro was never expanded within k5-int.h, but now
> it gets expanded by the new zapfree() inline function.
>
> So, I'm trying to figure out how to resolve this C++ compatibility
> issue without raising the likelihood of an information leakage
> vulnerability.  A possible choice is to make the macro more obviously
> wishy-washy by explicitly casting ptr back to void *:
>
>  memset((void *)(volatile void *)ptr, 0, len)
>
> Anyway, advice appreciated if anyone on the list has expertise in this
> issue.
> _______________________________________________
> krbdev mailing list             krbdev at mit.edu
> https://mailman.mit.edu/mailman/listinfo/krbdev
>



-- 
       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
       Member, MIT Student Information Processing Board  (SIPB)
       URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
       warlord at MIT.EDU                        PGP key available


From shuque at isc.upenn.edu  Sun Nov 22 21:38:04 2009
From: shuque at isc.upenn.edu (Shumon Huque)
Date: Sun, 22 Nov 2009 21:38:04 -0500
Subject: IAKERB
In-Reply-To: <1D28DFFB-FC07-4D2B-8A4F-968AD5648F2E@jpl.nasa.gov>
References: <mailman.633.1258563788.8683.krbdev@mit.edu>
	<1D28DFFB-FC07-4D2B-8A4F-968AD5648F2E@jpl.nasa.gov>
Message-ID: <20091123023804.GA775@isc.upenn.edu>

On Thu, Nov 19, 2009 at 05:15:45PM -0800, Henry B. Hotz wrote:
> 
> On Nov 18, 2009, at 9:03 AM, krbdev-request at mit.edu wrote:
> 
> > I'm pleased to announce an IAKERB implementation for MIT Kerberos:
> > 
> > 	http://k5wiki.kerberos.org/wiki/Projects/IAKERB
> > 
> > IAKERB allows clients that cannot reach a KDC to proxy credentials  
> > acquisition via a GSS exchange with a service. This should reduce the  
> > dependence on protocols such as NTLM and Digest outside the firewall.

> I applaud the availability of a solution.  I bemoan the widespread,
> naive use of firewalls that creates the problem in the first place.
> *sigh*

It's not just firewalls. Another interesting use case for this
is network access authentication, eg. 802.1x/EAP, where clients
have to complete a link layer authentication (eg. via a wireless
access point and a RADIUS server) before they even have an IP
address. In such cases the RADIUS server would likely act as the 
IAKERB proxy.

Of course this requires the IETF to finish developing a GSSAPI
method for EAP ...

--Shumon.

From mike.patnode at centrify.com  Mon Nov 23 11:30:32 2009
From: mike.patnode at centrify.com (Mike Patnode)
Date: Mon, 23 Nov 2009 08:30:32 -0800
Subject: Zapping memory and C++ compatibility
In-Reply-To: <20091121075116.2kwxt1tsococgsw4@webmail.mit.edu>
References: <200911210445.nAL4jeKY016987@outgoing.mit.edu>
	<20091121075116.2kwxt1tsococgsw4@webmail.mit.edu>
Message-ID: <BB7E16A14DE689469A181EC770AFBF4D03E7EA17@exch-one.centrify.com>

Without a reference in front of me, I'm fairly certain C style casts are
mapped to reinterpret_cast in C++.  In this case it's simple syntax
sugar.  In any case, they are certainly allowed in C++.

mp

-----Original Message-----
From: krbdev-bounces at mit.edu [mailto:krbdev-bounces at mit.edu] On Behalf
Of Derek Atkins
Sent: Saturday, November 21, 2009 4:51 AM
To: ghudson at mit.edu
Cc: krbdev at mit.edu
Subject: Re: Zapping memory and C++ compatibility

I think the problem is that you cannot use a C-style cast to cast an
object to a void* pointer in C++.  You might need to use a 'static_cast'
to do so, which means you might need to do something like:

#ifdef __cplusplus
#define krb5int_zap_data(ptr, len) memset(static_cast<volatile void 
*>(ptr), 0,
len)
#else
#define krb5int_zap_data(ptr, len) memset((volatile void *)ptr, 0, len)
#endif

-derek

Quoting ghudson at MIT.EDU:

> Back in 2002 or so, people noticed that certain compilers (I think gcc
> 3.x and Visual C++) would sometimes optimize out a memset() which they
> could prove doesn't affect the execution of the program according to
> standardized behaviors (which doesn't include accessing stack garbage
> or the contents of core dumps or anything of that sort).  So, there
> was a lot of discussion about how to securely zero passwords or
> cryptographic keys.
>
> We had out own discussion, which you can review at
> http://mailman.mit.edu/pipermail/krbdev/2002-November/000871.html.
> The eventual upshot was this collection of macros or inlines:
>
> Win32: #define krb5int_zap_data(ptr, len) SecureZeroMemory(ptr, len)
> gcc:   static inline void krb5int_zap_data(void *ptr, size_t len) {
>       memset(ptr, 0, len); asm volatile ("" : : "g" (ptr), "g" (len));
}
> else:  #define krb5int_zap_data(ptr, len) memset((volatile void 
> *)ptr, 0, len)
>
> The last construction was based on the idea that a hypothetical
> compiler might see the cast through volatile void * and decide not to
> perform an optimization.  It's not clear to me how valid this
> reasoning is, since neither the proximal type (after the implicit cast
> to void * by the call to memset) nor the original type is volatile.
>
> Today's problem is that the last construction isn't valid C++.  We
> have a test case which tries passing k5-int.h through C++ compiler,
> and it now fails on Solaris with the native compiler.  It didn't fail
> before because the macro was never expanded within k5-int.h, but now
> it gets expanded by the new zapfree() inline function.
>
> So, I'm trying to figure out how to resolve this C++ compatibility
> issue without raising the likelihood of an information leakage
> vulnerability.  A possible choice is to make the macro more obviously
> wishy-washy by explicitly casting ptr back to void *:
>
>  memset((void *)(volatile void *)ptr, 0, len)
>
> Anyway, advice appreciated if anyone on the list has expertise in this
> issue.
> _______________________________________________
> krbdev mailing list             krbdev at mit.edu
> https://mailman.mit.edu/mailman/listinfo/krbdev
>



-- 
       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
       Member, MIT Student Information Processing Board  (SIPB)
       URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
       warlord at MIT.EDU                        PGP key available

_______________________________________________
krbdev mailing list             krbdev at mit.edu
https://mailman.mit.edu/mailman/listinfo/krbdev


From lukeh at padl.com  Sat Nov 21 08:23:26 2009
From: lukeh at padl.com (Luke Howard)
Date: Sat, 21 Nov 2009 14:23:26 +0100
Subject: Zapping memory and C++ compatibility
In-Reply-To: <20091121075116.2kwxt1tsococgsw4@webmail.mit.edu>
References: <200911210445.nAL4jeKY016987@outgoing.mit.edu>
	<20091121075116.2kwxt1tsococgsw4@webmail.mit.edu>
Message-ID: <F0228101-4B22-40DC-BB4D-F33462DA1F41@padl.com>


On 21/11/2009, at 1:51 PM, Derek Atkins wrote:

> I think the problem is that you cannot use a C-style cast to cast an
> object to a void* pointer in C++.  You might need to use a  
> 'static_cast'
> to do so, which means you might need to do something like:

I don't know what the spec says, but in my brief foray into C++ with  
OpenSAML, C-style casts work fine.

-- Luke

From guenther at gmail.com  Mon Nov 23 17:52:50 2009
From: guenther at gmail.com (Philip Guenther)
Date: Mon, 23 Nov 2009 14:52:50 -0800
Subject: Zapping memory and C++ compatibility
In-Reply-To: <BB7E16A14DE689469A181EC770AFBF4D03E7EA17@exch-one.centrify.com>
References: <200911210445.nAL4jeKY016987@outgoing.mit.edu>
	<20091121075116.2kwxt1tsococgsw4@webmail.mit.edu>
	<BB7E16A14DE689469A181EC770AFBF4D03E7EA17@exch-one.centrify.com>
Message-ID: <dd0728a90911231452w4fc0202ep5b384d2fcfb2ab5e@mail.gmail.com>

On Mon, Nov 23, 2009 at 8:30 AM, Mike Patnode <mike.patnode at centrify.com> wrote:
> Without a reference in front of me, I'm fairly certain C style casts are
> mapped to reinterpret_cast in C++. ?In this case it's simple syntax
> sugar. ?In any case, they are certainly allowed in C++.

No, they are not directly mapped to reinterpret_cast.  They are mapped
to the first option which is legal of a list possibilities that starts
with "just a const_cast" and, IIRC, ends with "just a
reinterpret_cast" with possibilities that include static_cast in the
middle.  (I don't remember the exact list well enough to quote it
here.)  In this case, assuming the original pointer is a 'char *' or
similar, it'll do the combination of a static_cast (from char * to
void *) and a const_cast (from void * to volatile void *).  I.e., the
cast is not the problem.

...
>> Today's problem is that the last construction isn't valid C++. ?We
>> have a test case which tries passing k5-int.h through C++ compiler,
>> and it now fails on Solaris with the native compiler. ?It didn't fail
>> before because the macro was never expanded within k5-int.h, but now
>> it gets expanded by the new zapfree() inline function.
...
>> A possible choice is to make the macro more obviously
>> wishy-washy by explicitly casting ptr back to void *:
>>
>> memset((void *)(volatile void *)ptr, 0, len)

I guess people missed this bit, as it shows that the cast is fine and
that it's the implicit conversion that is rejected by the compiler.
Comparing g++ and gcc's output might make it more obvious:

$ cat f.cpp
#include <string.h>

int main(void)
{
        char ptr[13];
        int len = 13;
        memset((volatile void *)ptr, 0, len);
        return 0;
}
$ g++ -c f.cpp
f.cpp: In function `int main()':
f.cpp:7: error: invalid conversion from `volatile void*' to `void*'
$
$ mv f.cpp f.c
$ gcc -c f.c
f.c: In function `main':
f.c:7: warning: passing arg 1 of `memset' discards qualifiers from
pointer target type
$

IMO, the 'safe' thing would be to have an actual function
krb5int_zap_data() defined in its own .c file which does the zeroing
out and not mess with volatile at all.  That'll solve it for
file-by-file optimizers.  Whole-program optimizers are at least
theoretically in a position to defeat all work arounds.  Suggestions
for dealing with them would need to come from someone who has access
to one.


Philip Guenther


From ghudson at MIT.EDU  Tue Nov 24 09:42:42 2009
From: ghudson at MIT.EDU (ghudson@MIT.EDU)
Date: Tue, 24 Nov 2009 09:42:42 -0500 (EST)
Subject: Memory leak in recent fast_util.c change (r23325)
Message-ID: <200911241442.nAOEggef000481@outgoing.mit.edu>

Sam, r23325 leaks fast_armored_req if it rejects based on the presence
of tgs_subkey, because it returns immediately instead of setting
retval and relying on the if ladder.