From hartmans at MIT.EDU  Mon Nov  3 11:59:11 2008
From: hartmans at MIT.EDU (Sam Hartman)
Date: Mon, 03 Nov 2008 11:59:11 -0500
Subject: String handling in krb5
In-Reply-To: <200810232100.m9NL0sRf020960@outgoing.mit.edu> (ghudson@MIT.EDU's
	message of "Thu, 23 Oct 2008 17:00:54 -0400 (EDT)")
References: <200810232100.m9NL0sRf020960@outgoing.mit.edu>
Message-ID: <tsl63n4ycdc.fsf@mit.edu>

Greg, is it safe to use k5buf for strings that may contain nulls?
If so, is cstr really the right name for the function to get a char *?

From ghudson at MIT.EDU  Mon Nov  3 12:09:58 2008
From: ghudson at MIT.EDU (Greg Hudson)
Date: Mon, 03 Nov 2008 12:09:58 -0500
Subject: String handling in krb5
In-Reply-To: <tsl63n4ycdc.fsf@mit.edu>
References: <200810232100.m9NL0sRf020960@outgoing.mit.edu>
	<tsl63n4ycdc.fsf@mit.edu>
Message-ID: <1225732198.8616.4.camel@ray>

On Mon, 2008-11-03 at 11:59 -0500, Sam Hartman wrote:
> Greg, is it safe to use k5buf for strings that may contain nulls?
> If so, is cstr really the right name for the function to get a char *?

I could rename it to krb5int_buf_data.  The point of calling it the "C
string" is that the caller can be assured that it's null-terminated, but
perhaps that name would be too unnatural for code using the k5bufs with
binary data.



From hartmans at MIT.EDU  Mon Nov  3 15:13:13 2008
From: hartmans at MIT.EDU (Sam Hartman)
Date: Mon, 03 Nov 2008 15:13:13 -0500
Subject: String handling in krb5
In-Reply-To: <1225732198.8616.4.camel@ray> (Greg Hudson's message of "Mon, 03
	Nov 2008 12:09:58 -0500")
References: <200810232100.m9NL0sRf020960@outgoing.mit.edu>
	<tsl63n4ycdc.fsf@mit.edu> <1225732198.8616.4.camel@ray>
Message-ID: <tslmyggwoti.fsf@mit.edu>

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

    Greg> On Mon, 2008-11-03 at 11:59 -0500, Sam Hartman wrote:
    >> Greg, is it safe to use k5buf for strings that may contain
    >> nulls?  If so, is cstr really the right name for the function
    >> to get a char *?

    Greg> I could rename it to krb5int_buf_data.  The point of calling
    Greg> it the "C string" is that the caller can be assured that
    Greg> it's null-terminated, but perhaps that name would be too
    Greg> unnatural for code using the k5bufs with binary data.

I'm OK with either interpretation but I think supporting internal nulls is a good idea for this interface.

From ashutosh.datar at hp.com  Tue Nov  4 00:52:18 2008
From: ashutosh.datar at hp.com (Datar, Ashutosh Anil)
Date: Tue, 4 Nov 2008 05:52:18 +0000
Subject: Query regarding the ticket options passed by an application
In-Reply-To: <BF98D2A6A737054A8611EB5263F35D0D6039F99A5E@GVW1154EXB.americas.hpqcorp.net>
References: <BF98D2A6A737054A8611EB5263F35D0D6039F99A5E@GVW1154EXB.americas.hpqcorp.net>
Message-ID: <BF98D2A6A737054A8611EB5263F35D0D6050F48EEC@GVW1154EXB.americas.hpqcorp.net>

Hi,

Can someone provide the inputs on this?
Is the current behavior for options 'forwardable' and 'proxiable' expected one?

Thanks and Regards,
Ashutosh

________________________________
From: Datar, Ashutosh Anil
Sent: Monday, October 20, 2008 3:04 PM
To: krbdev at mit.edu
Cc: PDL-krbteam
Subject: Query regarding the ticket options passed set an application

Hi,

I had a query regarding the treatment given to options ("forwardable" or "proxiable") passed by an application through the call krb5_get_in_tkt_with_password ().

What we observed while working on PAM Kerberos (libpam_krb5) is that, if an option is not mentioned by the PAM configuration file, then the mentioned function (krb5_get_in_tkt_with_password) sets it to "false".
Now that the option is set to something, the libdefault value for that option won't be considered at all. Because, the code in function krb5_get_init_creds () checks to see if the option is already set (to something, be it false or true) and if set, then takes the previously specified value.

This makes a difference when no option is specified in PAM but the same option is set to true in Kerberos configuration; because in this case, the Kerberos option will be totally ignored.

====================================================================
     Options are set in krb5int_populate_gic_opt () like:

          :
     if (options&KDC_OPT_FORWARDABLE)
         krb5_get_init_creds_opt_set_forwardable(opt, 1);
     else krb5_get_init_creds_opt_set_forwardable(opt, 0);
     if (options&KDC_OPT_PROXIABLE)
         krb5_get_init_creds_opt_set_proxiable(opt, 1);
     else krb5_get_init_creds_opt_set_proxiable(opt, 0);
          :

     Functions krb5_get_init_creds sets the options as follows:

     if (options && (options->flags & KRB5_GET_INIT_CREDS_OPT_FORWARDABLE))
        tempint = options->forwardable;
     else if ((ret = krb5_libdefault_boolean(context, &client->realm,
                                            "forwardable", &tempint)) == 0)
            ;
     else
        tempint = 0;
     if (tempint)
        request.kdc_options |= KDC_OPT_FORWARDABLE;
====================================================================

Now the question is if there is any specific reason behind keeping it like this?
Because, the "libdefaults" in krb5.conf being the default options for libkrb5 library, an application can override them but in case an application doesn't mention about the option, it can always refer to the default value set for that option in Kerberos configuration.
Also, the default values of these options being "false", if none of the configurations (application and Kerberos) are mentioning about an option, it will not affect the application logic also.

While searching online, I could see few of the other implementations, where the specific options from application configuration (PAM here) take preference but otherwise the defaults from krb5.conf will always be considered.

Can you please let me know if this is the expected behavior and if yes, why?

Thanks and Regards,
Ashutosh

From hartmans at MIT.EDU  Tue Nov  4 07:33:50 2008
From: hartmans at MIT.EDU (Sam Hartman)
Date: Tue, 04 Nov 2008 07:33:50 -0500
Subject: Query regarding the ticket options passed by an application
In-Reply-To: <BF98D2A6A737054A8611EB5263F35D0D6050F48EEC@GVW1154EXB.americas.hpqcorp.net>
	(Ashutosh Anil Datar's message of "Tue, 4 Nov 2008 05:52:18 +0000")
References: <BF98D2A6A737054A8611EB5263F35D0D6039F99A5E@GVW1154EXB.americas.hpqcorp.net>
	<BF98D2A6A737054A8611EB5263F35D0D6050F48EEC@GVW1154EXB.americas.hpqcorp.net>
Message-ID: <tslprlbvff5.fsf@mit.edu>

>>>>> "Datar," == Datar, Ashutosh Anil <ashutosh.datar at hp.com> writes:

    Datar,> Hi, Can someone provide the inputs on this?  Is the
    Datar,> current behavior for options 'forwardable' and 'proxiable'
    Datar,> expected one?

    Datar,> Thanks and Regards, Ashutosh

    Datar,> ________________________________ From: Datar, Ashutosh
    Datar,> Anil Sent: Monday, October 20, 2008 3:04 PM To:
    Datar,> krbdev at mit.edu Cc: PDL-krbteam Subject: Query regarding
    Datar,> the ticket options passed set an application

    Datar,> Hi,

    Datar,> I had a query regarding the treatment given to options
    Datar,> ("forwardable" or "proxiable") passed by an application
    Datar,> through the call krb5_get_in_tkt_with_password ().

    Datar,> What we observed while working on PAM Kerberos
    Datar,> (libpam_krb5) is that, if an option is not mentioned by
    Datar,> the PAM configuration file, then the mentioned function
    Datar,> (krb5_get_in_tkt_with_password) sets it to "false".  Now
    Datar,> that the option is set to something, the libdefault value
    Datar,> for that option won't be considered at all. Because, the
    Datar,> code in function krb5_get_init_creds () checks to see if
    Datar,> the option is already set (to something, be it false or
    Datar,> true) and if set, then takes the previously specified
    Datar,> value.

    Datar,> This makes a difference when no option is specified in PAM
    Datar,> but the same option is set to true in Kerberos
    Datar,> configuration; because in this case, the Kerberos option
    Datar,> will be totally ignored.

    Datar,> ====================================================================
    Datar,> Options are set in krb5int_populate_gic_opt () like:

    Datar,>           : if (options&KDC_OPT_FORWARDABLE)
    Datar,> krb5_get_init_creds_opt_set_forwardable(opt, 1); else
    Datar,> krb5_get_init_creds_opt_set_forwardable(opt, 0); if
    Datar,> (options&KDC_OPT_PROXIABLE)
    Datar,> krb5_get_init_creds_opt_set_proxiable(opt, 1); else
    Datar,> krb5_get_init_creds_opt_set_proxiable(opt, 0); :

    Datar,>      Functions krb5_get_init_creds sets the options as
    Datar,> follows:

    Datar,>      if (options && (options->flags &
    Datar,> KRB5_GET_INIT_CREDS_OPT_FORWARDABLE)) tempint =
    Datar,> options->forwardable; else if ((ret =
    Datar,> krb5_libdefault_boolean(context, &client->realm,
    Datar,> "forwardable", &tempint)) == 0) ; else tempint = 0; if
    Datar,> (tempint) request.kdc_options |= KDC_OPT_FORWARDABLE;
    Datar,> ====================================================================

    Datar,> Now the question is if there is any specific reason behind
    Datar,> keeping it like this?  Because, the "libdefaults" in
    Datar,> krb5.conf being the default options for libkrb5 library,
    Datar,> an application can override them but in case an
    Datar,> application doesn't mention about the option, it can
    Datar,> always refer to the default value set for that option in
    Datar,> Kerberos configuration.  Also, the default values of these
    Datar,> options being "false", if none of the configurations
    Datar,> (application and Kerberos) are mentioning about an option,
    Datar,> it will not affect the application logic also.

    Datar,> While searching online, I could see few of the other
    Datar,> implementations, where the specific options from
    Datar,> application configuration (PAM here) take preference but
    Datar,> otherwise the defaults from krb5.conf will always be
    Datar,> considered.

    Datar,> Can you please let me know if this is the expected
    Datar,> behavior and if yes, why?

    Datar,> Thanks and Regards, Ashutosh
    Datar,> _______________________________________________ krbdev
    Datar,> mailing list krbdev at mit.edu
    Datar,> https://mailman.mit.edu/mailman/listinfo/krbdev


Yes, it is expected that krb5_get_in_tkt_with_password does not
respect libdefault values.  It's an older API.  Use
krb5_get_init_creds_password if you want libdefault values to be
respected.


A PAM module that is using that old API seems highly unfortunate today.

From rra at stanford.edu  Tue Nov  4 12:37:13 2008
From: rra at stanford.edu (Russ Allbery)
Date: Tue, 04 Nov 2008 09:37:13 -0800
Subject: Query regarding the ticket options passed by an application
In-Reply-To: <BF98D2A6A737054A8611EB5263F35D0D6050F48EEC@GVW1154EXB.americas.hpqcorp.net>
	(Ashutosh Anil Datar's message of "Tue\,
	4 Nov 2008 05\:52\:18 +0000")
References: <BF98D2A6A737054A8611EB5263F35D0D6039F99A5E@GVW1154EXB.americas.hpqcorp.net>
	<BF98D2A6A737054A8611EB5263F35D0D6050F48EEC@GVW1154EXB.americas.hpqcorp.net>
Message-ID: <87fxm7qto6.fsf@windlord.stanford.edu>

"Datar, Ashutosh Anil" <ashutosh.datar at hp.com> writes:

> What we observed while working on PAM Kerberos (libpam_krb5) is that, if
> an option is not mentioned by the PAM configuration file, then the
> mentioned function (krb5_get_in_tkt_with_password) sets it to "false".

Which PAM module is this?  Switching to a newer PAM module would probably
fix this problem.

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

From since at opendemand.com  Wed Nov  5 09:42:07 2008
From: since at opendemand.com (Stephen Ince)
Date: Wed, 5 Nov 2008 09:42:07 -0500
Subject: gss_init_sec_context error for spnego
References: <20081015205426.GM8906@Sun.COM><536.1224104710@malison.ait.iastate.edu><20081015211618.GP8906@Sun.COM><54b301c92f10$d25b97d0$6e00a8c0@desktop2><607001c93228$962222f0$6e00a8c0@desktop2><87abczqx5o.fsf@mocca.josefsson.org><621a01c932c0$10671330$6e00a8c0@desktop2><878wsjpbl9.fsf@mocca.josefsson.org><62b901c932f3$11146200$6e00a8c0@desktop2><62f301c932f6$85a8b6e0$6e00a8c0@desktop2><F2C4A344-42B5-457B-BD6E-681AEBE9C138@mit.edu>
	<635a01c93310$cb23e3b0$6e00a8c0@desktop2>
Message-ID: <0b9b01c93f54$ad7c5860$6e00a8c0@desktop2>

I have been meaning to update this thread. This issue was IIS was returning 
a NTLM token.  Thanx for all the help.

Steve
----- Original Message ----- 
From: "Stephen Ince" <since at opendemand.com>
To: "Ken Raeburn" <raeburn at mit.edu>; <krbdev at mit.edu>
Sent: Monday, October 20, 2008 7:00 PM
Subject: Re: gss_init_sec_context error for spnego


> Ken,
>    It is a http client. I am try to add kerberos negotiate(spnego) support
> for our http client. I am using mit kfw libraries on win32. I noticed that
> mozilla uses sspi on win32 but I don't think this is necessary. I just 
> would
> like to use one kerberos package.
> I have the authentication working for apache/mit KDC server, but not for
> IIS/AD server. Is it the AD that is messing up?
>
> req_flags=  GSS_C_MUTUAL_FLAG|GSS_C_DELEG_FLAG|GSS_C_REPLAY_FLAG
> gss_init_sec_context // using the network
> //check the ret_flags, if the token from IIS will be encrypted?
> // use http to get to input token from IIS.
>
> int decode_len = apr_base64_decode_len(header);
> input_token.value = (char*)malloc(decode_len +1);
> input_token.length = apr_base64_decode(input_token.value,header);
>
> gss_init_sec_context // set the input_token, this fails for IIS but not 
> for
> Apache
> // I get a "Message stream modified" error
>
>
> Steve
>
>
> ----- Original Message ----- 
> From: "Ken Raeburn" <raeburn at MIT.EDU>
> To: "Stephen Ince" <since at opendemand.com>
> Cc: <krbdev at MIT.EDU>
> Sent: Monday, October 20, 2008 5:16 PM
> Subject: Re: gss_init_sec_context error for spnego
>
>
>> On Oct 20, 2008, at 16:57, Stephen Ince wrote:
>>> I think my hunch was correct, IIS is ignoring the req_flags.  Everything
>>> worked when I tested apache. The format of the token coming back  from
>>> IIS
>>> must be encrypted. I did an ethereal snoop and noticed that
>>> gss_init_sec_context fails and does not make any network calls.
>>> Is there a way I can check for the format of the IIS token from the
>>> first
>>> gss_init_sec_context? I do not tell IIS to encrypt the token.
>>
>> Right, gss_init_sec_context doesn't talk to the server.  It forms
>> messages for you to send -- depending on your application protocol,
>> perhaps base-64 encoded, perhaps with some wrapper text, etc -- and  then
>> (for the next call) you give it a message you got back from the  server.
>> If you're using Kerberos, it *may* use the network to talk to  the KDC,
>> but if you already have local credentials, it may not need to.
>>
>> As Tom indicated earlier, it's not really clear from your messages  what
>> you're doing -- whether the code you're working on is even on the  client
>> or server side and what software you're talking to.  Are you  talking to
>> Apache/IIS over the net with web client code you're  modifying, or is 
>> your
>> software plugging in to the server and getting  contacted with IE?
>>
>> Ken
>>
>
> _______________________________________________
> krbdev mailing list             krbdev at mit.edu
> https://mailman.mit.edu/mailman/listinfo/krbdev
> 


From hartmans at MIT.EDU  Wed Nov  5 11:18:07 2008
From: hartmans at MIT.EDU (Sam Hartman)
Date: Wed, 05 Nov 2008 11:18:07 -0500
Subject: Initial comments request: AEAD Encryption API
Message-ID: <tsld4haqh8g.fsf@mit.edu>



Folks, I'm helping Luke Howard who is working on getting a number of
Microsoft extensions integrated into MIT Kerberos.  I'm putting
together documentation sufficient for our review of the work as well
as reviewing his code.

I'd like to get some early comments on
http://k5wiki.kerberos.org/wiki/Projects/AEAD_encryption_API .

In particular, I'd definitely like feedback on the open design
questions and on the implementation choices.  If you want to look at
code, take a look at the mskrb-integ branch.


Sam Hartman
Principal, Painless Security

From raeburn at MIT.EDU  Wed Nov  5 18:11:11 2008
From: raeburn at MIT.EDU (Ken Raeburn)
Date: Wed, 5 Nov 2008 18:11:11 -0500
Subject: Initial comments request: AEAD Encryption API
In-Reply-To: <tsld4haqh8g.fsf@mit.edu>
References: <tsld4haqh8g.fsf@mit.edu>
Message-ID: <11114B84-4A85-4596-83DD-88B3215349BC@mit.edu>

On Nov 5, 2008, at 11:18, Sam Hartman wrote:
> Folks, I'm helping Luke Howard who is working on getting a number of
> Microsoft extensions integrated into MIT Kerberos.  I'm putting
> together documentation sufficient for our review of the work as well
> as reviewing his code.
>
> I'd like to get some early comments on
> http://k5wiki.kerberos.org/wiki/Projects/AEAD_encryption_API .

A spec for the crypto stuff would help.  And API docs.

> In particular, I'd definitely like feedback on the open design
> questions and on the implementation choices.  If you want to look at
> code, take a look at the mskrb-integ branch.

> Design questions
> Supporting multiple data chunks that are not block-size aligned is  
> tricky . Is it actually needed?

Without a spec, I can only guess that it would be, at least for the  
associated data.

> The API exposes padding separate from trailers. However RFC 3961 has  
> neither concept. Is this the right balance?

Once you start doing scatter-gather and in-place encryption, it's hard  
to keep things abstract.  RFC 3961 imposes a few arbitrary-looking  
constraints, but having easily separated padding and trailers, and an  
identifiable integrity-check tag, is not among them.

I'd have been happy to rework 3961 to include some form of AEAD  
support so we don't have to provide the building blocks for SSPI to  
build it at a higher level, but that got shot down every time I  
suggested it.  (To be fair, we were focusing on 4120 at the time,  
where it could've been used but not without making more drastic  
changes relative to 1510 than most of us wanted.)  Skimming the code  
and trying to work back to a rough idea of how a spec might work, it  
looks to me like AEAD is "defined" for RC4 and for the simplified- 
profile cryptosystems, but not in the general case.  (And much as we  
might dislike DES, if we want to provide AEAD as truly general  
functionality, it must be defined there too.)  So if we were to adopt  
an algorithm that doesn't use the simplified profile, we'd have to  
also specify how AEAD would work, with (as yet) no framework for how  
that specification should be written up.

> With the existing crypto systems, the order between data chunks and  
> sign_only chunks matters. That is, (data|sign_only|data) will  
> produce a different checksum than (sign_only|data|data). Do we want  
> callers to depend on this, or will doing so create a problem if we  
> have a crypto system based on RFc 5116? I suspect that we want to  
> say that a crypto system may treat the sign_only chunks as one  
> ordered sequence and the data chunks as another ordered sequence but  
> not require that the relative ordering between data chunks and  
> sign_only chunks affect the cipher text.

Depends on SSPI usage, I guess.  That may be a loosening of the  
security properties it currently gives.  That may be something to talk  
about in Minneapolis if you're going; it looks like I won't be.   
(Either a change to SSPI, with Larry, or a convergence between GSS-API  
and SSPI functionality, and the associated effect on Kerberos crypto  
if we want to maintain a generic Kerberos mechanism, in either or both  
working groups.)

It already looks like the protection is kind of weak for two  
consecutive chunks of the same type; an attacker could push data  
around and adjust some lengths, and ciphertext and plaintext wind up  
moving from one block to another, with no change to the checksum.  If  
the chunking is purely for convenience and not intended to be  
protected or to carry meaning, then yes, I think perhaps we could  
define something based on RFC 5116.

> The API design assumes fixed-length headers, padding and trailers.

It also looks like for decryption you have to know how to separate the  
different components (e.g., ciphertext from trailer) before decrypting.

> I'm not sure how padding is supposed to work. Does the API reduce  
> padding size?

> Implementation notes
> While the API supports in-place encryption the implementation does  
> not significantly reduce the number of copies.

We should decide if in-place encryption is important to us.  Forcing  
the application to explicitly copy an input it wants to use multiple  
times is annoying, but in-place encryption can help memory-constrained  
environments.

I can imagine some specific uses for separate inputs and outputs with  
scatter-gather.  For example, Tom and I have discussed a possible ASN. 
1 encoder scheme that tracks the various bits of data to be put  
together (tags, encoded numbers, etc), but avoids actually copying the  
application data (strings, buffers) until assembling the final result  
(instead of our current annoying copy-backwards-and-reverse-at-the-end  
approach); for a message part to be encrypted, with scatter-gather  
input and a big buffer output, we could avoid the copying altogether  
except as it happens in the encryption process.  Requiring it to be in- 
place means copying the application data to temporary storage before  
encrypting, like we do now.

But trying to implement the "ask for the size needed" approach in  
encryption would probably have to be extended to (1) ask for the  
number of chunks needed, and (2) ask for the size of each, or maybe  
all at once, once the iov structures are allocated.

> The implementation is parallel to the existing implementation. In  
> particular, the existing APIs are not implemented in terms of the  
> new APIs. New code is required (with significant copying) from the  
> generic API layer down to the enc_provider layer, although of course  
> raw crypto primitives are used.
> Currently sanity checking buffers--for example making sure there is  
> a trailer chunk--is left to the enc_provider implementations.

Currently, there's no AEAD for DES, so we can't just build generic  
encryption on top of generic AEAD.  And having to separate ciphertext  
and trailers means building generic decryption on top of generic AEAD  
would be kind of ugly even if we had the DES support, unless we  
implement a new chunk type for "everything thrown together", or a way  
to pull out the lengths of the different parts.

Ken

From Nicolas.Williams at sun.com  Wed Nov  5 18:30:25 2008
From: Nicolas.Williams at sun.com (Nicolas Williams)
Date: Wed, 5 Nov 2008 17:30:25 -0600
Subject: Initial comments request: AEAD Encryption API
In-Reply-To: <11114B84-4A85-4596-83DD-88B3215349BC@mit.edu>
References: <tsld4haqh8g.fsf@mit.edu>
	<11114B84-4A85-4596-83DD-88B3215349BC@mit.edu>
Message-ID: <20081105233024.GO106460@Sun.COM>

On Wed, Nov 05, 2008 at 06:11:11PM -0500, Ken Raeburn wrote:
> On Nov 5, 2008, at 11:18, Sam Hartman wrote:
> > Folks, I'm helping Luke Howard who is working on getting a number of
> > Microsoft extensions integrated into MIT Kerberos.  I'm putting
> > together documentation sufficient for our review of the work as well
> > as reviewing his code.
> >
> > I'd like to get some early comments on
> > http://k5wiki.kerberos.org/wiki/Projects/AEAD_encryption_API .
> 
> A spec for the crypto stuff would help.  And API docs.

+1

> > The API exposes padding separate from trailers. However RFC 3961 has  
> > neither concept. Is this the right balance?
> 
> Once you start doing scatter-gather and in-place encryption, it's hard  
> to keep things abstract.  RFC 3961 imposes a few arbitrary-looking  
> constraints, but having easily separated padding and trailers, and an  
> identifiable integrity-check tag, is not among them.

A revision certainly seems likely to be needed.

First, to specify AEAD by generic composition for the existing enctypes.

Second, to specify new enctypes that use AEAD modes of AES and avoid
generic composition.

There may not be enough interest in the latter.

> > With the existing crypto systems, the order between data chunks and  
> > sign_only chunks matters. That is, (data|sign_only|data) will  
> > produce a different checksum than (sign_only|data|data). Do we want  
> > callers to depend on this, or will doing so create a problem if we  
> > have a crypto system based on RFc 5116? I suspect that we want to  
> > say that a crypto system may treat the sign_only chunks as one  
> > ordered sequence and the data chunks as another ordered sequence but  
> > not require that the relative ordering between data chunks and  
> > sign_only chunks affect the cipher text.

I'd have to re-read RFC5116.  Certainly being compliant with it would be
nice.

> It already looks like the protection is kind of weak for two  
> consecutive chunks of the same type; an attacker could push data  
> around and adjust some lengths, and ciphertext and plaintext wind up  
> moving from one block to another, with no change to the checksum.  If  
> the chunking is purely for convenience and not intended to be  
> protected or to carry meaning, then yes, I think perhaps we could  
> define something based on RFC 5116.

Chunks should be logically concatenated.

> > The API design assumes fixed-length headers, padding and trailers.
> 
> It also looks like for decryption you have to know how to separate the  
> different components (e.g., ciphertext from trailer) before decrypting.

I'd rather not have as constrained an API as the SSPI was.  Let there be
functions that the caller can call to determine the lengths of the
headers, padding and trailers, but do let's assume that for any one
context (enctype) they are, in fact, fixed.

> > Implementation notes
> > While the API supports in-place encryption the implementation does  
> > not significantly reduce the number of copies.
> 
> We should decide if in-place encryption is important to us.  Forcing  
> the application to explicitly copy an input it wants to use multiple  
> times is annoying, but in-place encryption can help memory-constrained  
> environments.

In-place crypto helps a lot.  Please leave it in.  (Lots of HW crypto
accelerators support in-place crypto, but I suspect that the really
important thing is L2 cache pressure.)

> I can imagine some specific uses for separate inputs and outputs with  
> scatter-gather.  For example, Tom and I have discussed a possible ASN. 
> 1 encoder scheme that tracks the various bits of data to be put  
> together (tags, encoded numbers, etc), but avoids actually copying the  
> application data (strings, buffers) until assembling the final result  
> (instead of our current annoying copy-backwards-and-reverse-at-the-end  
> approach); for a message part to be encrypted, with scatter-gather  
> input and a big buffer output, we could avoid the copying altogether  
> except as it happens in the encryption process.  Requiring it to be in- 
> place means copying the application data to temporary storage before  
> encrypting, like we do now.

Providing support for in-place crypto != requiring use of in-lace crypto
APIs.

Crypto HW might have scatter/gather chunk alignment requirements, but if
you have mostly large chunks then you can internally create a larger
chain of chunks and copy only small amounts of data and still take
advantage of in-place crypto.

> > The implementation is parallel to the existing implementation. In  
> > particular, the existing APIs are not implemented in terms of the  
> > new APIs. New code is required (with significant copying) from the  
> > generic API layer down to the enc_provider layer, although of course  
> > raw crypto primitives are used.

If that's for performance reasons, then that's quite understandable.

> > Currently sanity checking buffers--for example making sure there is  
> > a trailer chunk--is left to the enc_provider implementations.
> 
> Currently, there's no AEAD for DES, so we can't just build generic  
> encryption on top of generic AEAD.  And having to separate ciphertext  
> and trailers means building generic decryption on top of generic AEAD  
> would be kind of ugly even if we had the DES support, unless we  
> implement a new chunk type for "everything thrown together", or a way  
> to pull out the lengths of the different parts.

I think you could define AEAD for DES by generic composition and then
have the old routines use the new AEAD ones, but without using the "AD"
part.  That'd work, if you're careful.  I think that's what Sam meant.
But I'm not sure that it's worth doing just for reducing code
duplication since it will add overhead to the most common cases.

Nico
-- 

From raeburn at MIT.EDU  Wed Nov  5 20:05:44 2008
From: raeburn at MIT.EDU (Ken Raeburn)
Date: Wed, 5 Nov 2008 20:05:44 -0500
Subject: Initial comments request: AEAD Encryption API
In-Reply-To: <20081105233024.GO106460@Sun.COM>
References: <tsld4haqh8g.fsf@mit.edu>
	<11114B84-4A85-4596-83DD-88B3215349BC@mit.edu>
	<20081105233024.GO106460@Sun.COM>
Message-ID: <83F323F9-F919-4B6B-8AF2-2285CBF73C84@mit.edu>

On Nov 5, 2008, at 18:30, Nicolas Williams wrote:
> First, to specify AEAD by generic composition for the existing  
> enctypes.

Not so generic, given that rc4 and simplified-profile versions appear  
to be rather different.  At least, not if we want this to actually be  
compatible with Microsoft, and, separate from extending RFC 3961, MIT  
does need the Microsoft compatibility right now.

> Second, to specify new enctypes that use AEAD modes of AES and avoid
> generic composition.

Probably a good idea eventually, yes, especially if the performance is  
significantly better than the separate encryption and HMAC with  
different keys that we're doing now.

> There may not be enough interest in the latter.

If such a mode is implemented in crypto accelerators (e.g., done for  
IPsec, but not built into the network hardware), there may be some  
benefit to supporting it in Kerberos/GSSAPI kernel modules for NFSv4  
etc, but otherwise I'm not sure where the impetus would come from; I  
don't know that many Kerberos-based applications find encryption to be  
a bottleneck.  And if one does channel bindings to IPsec and skips the  
GSSAPI-level encryption, there'd still be little point.

Ken

From hartmans at MIT.EDU  Wed Nov  5 20:49:47 2008
From: hartmans at MIT.EDU (Sam Hartman)
Date: Wed, 05 Nov 2008 20:49:47 -0500
Subject: Initial comments request: AEAD Encryption API
In-Reply-To: <20081105233024.GO106460@Sun.COM> (Nicolas Williams's message of
	"Wed, 5 Nov 2008 17:30:25 -0600")
References: <tsld4haqh8g.fsf@mit.edu>
	<11114B84-4A85-4596-83DD-88B3215349BC@mit.edu>
	<20081105233024.GO106460@Sun.COM>
Message-ID: <tslej1pmxms.fsf@mit.edu>

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

    Nicolas> On Wed, Nov 05, 2008 at 06:11:11PM -0500, Ken Raeburn
    Nicolas> wrote:
    >> On Nov 5, 2008, at 11:18, Sam Hartman wrote: > Folks, I'm
    >> helping Luke Howard who is working on getting a number of >
    >> Microsoft extensions integrated into MIT Kerberos.  I'm putting
    >> > together documentation sufficient for our review of the work
    >> as well > as reviewing his code.
    >> >
    >> > I'd like to get some early comments on >
    >> http://k5wiki.kerberos.org/wiki/Projects/AEAD_encryption_API .
    >> 
    >> A spec for the crypto stuff would help.  And API docs.

    Nicolas> +1

    >> > The API exposes padding separate from trailers. However RFC
    >> 3961 has > neither concept. Is this the right balance?
    >> 
    >> Once you start doing scatter-gather and in-place encryption,
    >> it's hard to keep things abstract.  RFC 3961 imposes a few
    >> arbitrary-looking constraints, but having easily separated
    >> padding and trailers, and an identifiable integrity-check tag,
    >> is not among them.

    Nicolas> A revision certainly seems likely to be needed.

Both this and a spec for the protocol level details of what Microsoft has done are out of scope for what Luke and I are funded to do.
I don't know if the EU filings from Microsoft contain details on this.

    >> > The implementation is parallel to the existing
    >> implementation. In > particular, the existing APIs are not
    >> implemented in terms of the > new APIs. New code is required
    >> (with significant copying) from the > generic API layer down to
    >> the enc_provider layer, although of course > raw crypto
    >> primitives are used.

    Nicolas> If that's for performance reasons, then that's quite
    Nicolas> understandable.

It was done to simplify implementation and to avoid the whole tree depending on a new feature.


--Sam

From raeburn at MIT.EDU  Thu Nov  6 12:12:49 2008
From: raeburn at MIT.EDU (Ken Raeburn)
Date: Thu, 6 Nov 2008 12:12:49 -0500
Subject: Initial comments request: AEAD Encryption API
In-Reply-To: <tslej1pmxms.fsf@mit.edu>
References: <tsld4haqh8g.fsf@mit.edu>
	<11114B84-4A85-4596-83DD-88B3215349BC@mit.edu>
	<20081105233024.GO106460@Sun.COM> <tslej1pmxms.fsf@mit.edu>
Message-ID: <63D02894-3A1C-4EC8-82D3-F024FE9A2694@mit.edu>

On Nov 5, 2008, at 20:49, Sam Hartman wrote:
>    Nicolas> A revision [to RFC 3961] certainly seems likely to be  
> needed.
>
> Both this and a spec for the protocol level details of what  
> Microsoft has done are out of scope for what Luke and I are funded  
> to do.
> I don't know if the EU filings from Microsoft contain details on this.

Certainly I understand not updating the RFC as part of the contract  
work.  But at the IETF perhaps we should consider it.

Some reference for the MS protocol is important if we want to be able  
to evaluate the code, fix any bugs that may come up later, figure out  
if we can extend it to new cryptosystems, etc.  Otherwise, going  
forward, maintaining code that has to conform to specs we don't have  
will be a major pain.  I wouldn't expect you guys to write new  
protocol docs, but if Luke's got a pointer to documentation someplace,  
it would be good to put it into either the doc tree or comments in the  
source.

Ken

From since at opendemand.com  Thu Nov  6 14:08:49 2008
From: since at opendemand.com (Stephen Ince)
Date: Thu, 6 Nov 2008 14:08:49 -0500
Subject: kerberos preauthentication
References: <tsld4haqh8g.fsf@mit.edu><11114B84-4A85-4596-83DD-88B3215349BC@mit.edu><20081105233024.GO106460@Sun.COM>
	<tslej1pmxms.fsf@mit.edu>
	<63D02894-3A1C-4EC8-82D3-F024FE9A2694@mit.edu>
Message-ID: <007901c94043$1bdfad40$6e00a8c0@desktop2>

My kerberos client fails when IIS preauthenticaion is disabled. I have been 
doing some reading on this but I need some guidance.  I am using the MIT KFW 
package on win32.
On the client-side how is kerberos preauthenticaion enable/disabled?
Is there a way to check if the server has preauthenticaion enable/disabled?


Steve 


From lhoward at MIT.EDU  Sat Nov  8 07:58:27 2008
From: lhoward at MIT.EDU (Luke Howard)
Date: Sat, 8 Nov 2008 23:58:27 +1100
Subject: Initial comments request: AEAD Encryption API
In-Reply-To: <63D02894-3A1C-4EC8-82D3-F024FE9A2694@mit.edu>
References: <tsld4haqh8g.fsf@mit.edu>
	<11114B84-4A85-4596-83DD-88B3215349BC@mit.edu>
	<20081105233024.GO106460@Sun.COM> <tslej1pmxms.fsf@mit.edu>
	<63D02894-3A1C-4EC8-82D3-F024FE9A2694@mit.edu>
Message-ID: <35A597BF-2420-432F-8505-D6E6B019B091@mit.edu>


On 07/11/2008, at 4:12 AM, Ken Raeburn wrote:

> On Nov 5, 2008, at 20:49, Sam Hartman wrote:
>>   Nicolas> A revision [to RFC 3961] certainly seems likely to be  
>> needed.
>>
>> Both this and a spec for the protocol level details of what  
>> Microsoft has done are out of scope for what Luke and I are funded  
>> to do.
>> I don't know if the EU filings from Microsoft contain details on  
>> this.
>
> Certainly I understand not updating the RFC as part of the contract  
> work.  But at the IETF perhaps we should consider it.
>
> Some reference for the MS protocol is important if we want to be  
> able to evaluate the code, fix any bugs that may come up later,  
> figure out if we can extend it to new cryptosystems, etc.   
> Otherwise, going forward, maintaining code that has to conform to  
> specs we don't have will be a major pain.  I wouldn't expect you  
> guys to write new protocol docs, but if Luke's got a pointer to  
> documentation someplace, it would be good to put it into either the  
> doc tree or comments in the source.


In the Microsoft protocol documentation, see [MS-KILE] 3.4.5.4ff:  
GSS_WrapEx() and friends.

Unfortunately, there are bugs in the documentation, particularly with  
respect to the handling of RRC in RFC 4121 (indeed, that appears to be  
a bug in Windows). We can but best document in the code.

-- Luke

From lhoward at MIT.EDU  Sat Nov  8 08:09:21 2008
From: lhoward at MIT.EDU (Luke Howard)
Date: Sun, 9 Nov 2008 00:09:21 +1100
Subject: Initial comments request: AEAD Encryption API
In-Reply-To: <11114B84-4A85-4596-83DD-88B3215349BC@mit.edu>
References: <tsld4haqh8g.fsf@mit.edu>
	<11114B84-4A85-4596-83DD-88B3215349BC@mit.edu>
Message-ID: <A341A22C-8EA5-4DC3-81E1-32EC53CECB52@mit.edu>

>> Supporting multiple data chunks that are not block-size aligned is  
>> tricky . Is it actually needed?
>
> Without a spec, I can only guess that it would be, at least for the  
> associated data.

I think it is fine to support, and in any case likely easier for the  
associated data (I'm not aware of any checksum mechanisms used with  
Kerberos that require the input data to be padded).

In the current implementation, a single padding buffer is provided to  
pad the total length of all encrypted data buffers to the blocksize.  
For GSS, the padding buffer length is indicated by the contents  
thereof (pre-RFC 4121) or EC (post-RFC 4121).

> It already looks like the protection is kind of weak for two  
> consecutive chunks of the same type; an attacker could push data  
> around and adjust some lengths, and ciphertext and plaintext wind up  
> moving from one block to another, with no change to the checksum.   
> If the chunking is purely for convenience and not intended to be  
> protected or to carry meaning, then yes, I think perhaps we could  
> define something based on RFC 5116.

I'm not familiar with RFC 5116 but I will read it. But yes, I have  
been assuming chunking is for convenience and associated data. The  
chunks would typically be concatenated before sending.

>> The API design assumes fixed-length headers, padding and trailers.
>
> It also looks like for decryption you have to know how to separate  
> the different components (e.g., ciphertext from trailer) before  
> decrypting.

Yes. For the DCE case this is carried in the RPC PDU itself.

-- Luke

From lukeh at padl.com  Sat Nov  8 15:21:36 2008
From: lukeh at padl.com (Luke Howard)
Date: Sun, 9 Nov 2008 07:21:36 +1100
Subject: Initial comments request: AEAD Encryption API
In-Reply-To: <A341A22C-8EA5-4DC3-81E1-32EC53CECB52@mit.edu>
References: <tsld4haqh8g.fsf@mit.edu>
	<11114B84-4A85-4596-83DD-88B3215349BC@mit.edu>
	<A341A22C-8EA5-4DC3-81E1-32EC53CECB52@mit.edu>
Message-ID: <768ABA8A-60E4-443B-8448-061B18F22BAB@padl.com>


On 09/11/2008, at 12:09 AM, Luke Howard wrote:

>>> Supporting multiple data chunks that are not block-size aligned is
>>> tricky . Is it actually needed?
>>
>> Without a spec, I can only guess that it would be, at least for the
>> associated data.
>
> I think it is fine to support, and in any case likely easier for the
> associated data (I'm not aware of any checksum mechanisms used with
> Kerberos that require the input data to be padded).

Except for DES-MAC.

-- Luke

From hartmans at MIT.EDU  Sat Nov  8 17:02:32 2008
From: hartmans at MIT.EDU (Sam Hartman)
Date: Sat, 08 Nov 2008 17:02:32 -0500
Subject: Initial comments request: AEAD Encryption API
In-Reply-To: <768ABA8A-60E4-443B-8448-061B18F22BAB@padl.com> (Luke Howard's
	message of "Sun, 9 Nov 2008 07:21:36 +1100")
References: <tsld4haqh8g.fsf@mit.edu>
	<11114B84-4A85-4596-83DD-88B3215349BC@mit.edu>
	<A341A22C-8EA5-4DC3-81E1-32EC53CECB52@mit.edu>
	<768ABA8A-60E4-443B-8448-061B18F22BAB@padl.com>
Message-ID: <tsl7i7dc1vr.fsf@mit.edu>

>>>>> "Luke" == Luke Howard <lukeh at padl.com> writes:

    Luke> On 09/11/2008, at 12:09 AM, Luke Howard wrote:

    >>>> Supporting multiple data chunks that are not block-size
    >>>> aligned is tricky . Is it actually needed?
    >>>  Without a spec, I can only guess that it would be, at least
    >>> for the associated data.
    >>  I think it is fine to support, and in any case likely easier
    >> for the associated data (I'm not aware of any checksum
    >> mechanisms used with Kerberos that require the input data to be
    >> padded).

    Luke> Except for DES-MAC.

I think it's safe to say we only care about des-mac in the GSS case if that.


From baron at bundesbrandschatzamt.de  Tue Nov 11 14:55:47 2008
From: baron at bundesbrandschatzamt.de (Andreas Gerler)
Date: Tue, 11 Nov 2008 20:55:47 +0100 (CET)
Subject: krbPrincNamingAttr ignored by kdb_ldap
Message-ID: <alpine.LRH.2.00.0811111927450.25493@marvin.home.bundesbrandschatzamt.de>

Hi,

Iam wondering why the kerberos.schema file contains krbPrincNamingAttr but 
the ldap kdb plugin lacks support for it.
At $work Ive got an already productive ldap with passwords and would like 
to introduce kerberos for sso.

so long...

Baron


From since at opendemand.com  Wed Nov 12 07:01:22 2008
From: since at opendemand.com (Stephen Ince)
Date: Wed, 12 Nov 2008 07:01:22 -0500
Subject: kerberos preauthentication IIS
References: <tsld4haqh8g.fsf@mit.edu><11114B84-4A85-4596-83DD-88B3215349BC@mit.edu><20081105233024.GO106460@Sun.COM>
	<tslej1pmxms.fsf@mit.edu>
	<63D02894-3A1C-4EC8-82D3-F024FE9A2694@mit.edu>
Message-ID: <00d001c944be$61eb5ee0$6e00a8c0@desktop2>

I am using MIT KFW 3.22 on win XP. I have a httpclient that connects to an 
IIS server/using kerberos 5.  I am able to successfully connect when IIS 
enables preauth. I fail when IIS disables preauth. I used ethereal and it 
looks the http client does get a NON preauth token. I have done some reading 
and it looks IIS may not support kerberos 5 with non preauth. It looks like 
it has to kerberos 4.  It looks like IE always uses preauth and may switch 
to kerberos 4 for NON preauth.

Is there a flag of setting in krb5.ini to switch to kerberos 4 for non 
preauth?

Steve 


From hartmans at MIT.EDU  Wed Nov 12 09:46:48 2008
From: hartmans at MIT.EDU (Sam Hartman)
Date: Wed, 12 Nov 2008 09:46:48 -0500
Subject: kerberos preauthentication IIS
In-Reply-To: <00d001c944be$61eb5ee0$6e00a8c0@desktop2> (Stephen Ince's message
	of "Wed, 12 Nov 2008 07:01:22 -0500")
References: <tsld4haqh8g.fsf@mit.edu>
	<11114B84-4A85-4596-83DD-88B3215349BC@mit.edu>
	<20081105233024.GO106460@Sun.COM> <tslej1pmxms.fsf@mit.edu>
	<63D02894-3A1C-4EC8-82D3-F024FE9A2694@mit.edu>
	<00d001c944be$61eb5ee0$6e00a8c0@desktop2>
Message-ID: <tslr65h57dz.fsf@mit.edu>

Hi.  You posted this message previously.  I guess you did not get a
response.  First, you're posting to the wrong place; krbdev at mit.edu is
for de.development discussions of MIT Kerberos.  You're not really
talking about how to write code for Kerberos; you're more talking
about how to use the product.  That discussion belongs on
kerberos at mit.edu.

However, I can also explain why I at least did not answer your
question.  As far as I know, IIS does not do pre-authentication--I
mean that in the sense that I cannot think of anything that IIS would
be doing that would be called pre-authentication.  There is something
Kerberos does that is called pre-authentication, but that doesn't fit
well into your question.

--Sam


From since at opendemand.com  Wed Nov 12 10:25:57 2008
From: since at opendemand.com (Stephen Ince)
Date: Wed, 12 Nov 2008 10:25:57 -0500
Subject: kerberos preauthentication IIS
References: <tsld4haqh8g.fsf@mit.edu><11114B84-4A85-4596-83DD-88B3215349BC@mit.edu><20081105233024.GO106460@Sun.COM>
	<tslej1pmxms.fsf@mit.edu><63D02894-3A1C-4EC8-82D3-F024FE9A2694@mit.edu><00d001c944be$61eb5ee0$6e00a8c0@desktop2>
	<tslr65h57dz.fsf@mit.edu>
Message-ID: <015b01c944da$f64beca0$6e00a8c0@desktop2>

Thx. Gotcha.  IIS does have a pre-authentication mode. Which is set by 
default.
----- Original Message ----- 
From: "Sam Hartman" <hartmans at mit.edu>
To: "Stephen Ince" <since at opendemand.com>
Cc: <krbdev at mit.edu>; "Matthew Devine" <mdevine at opendemand.com>
Sent: Wednesday, November 12, 2008 9:46 AM
Subject: Re: kerberos preauthentication IIS


> Hi.  You posted this message previously.  I guess you did not get a
> response.  First, you're posting to the wrong place; krbdev at mit.edu is
> for de.development discussions of MIT Kerberos.  You're not really
> talking about how to write code for Kerberos; you're more talking
> about how to use the product.  That discussion belongs on
> kerberos at mit.edu.
>
> However, I can also explain why I at least did not answer your
> question.  As far as I know, IIS does not do pre-authentication--I
> mean that in the sense that I cannot think of anything that IIS would
> be doing that would be called pre-authentication.  There is something
> Kerberos does that is called pre-authentication, but that doesn't fit
> well into your question.
>
> --Sam
>
> 


From since at opendemand.com  Wed Nov 12 18:28:41 2008
From: since at opendemand.com (Stephen Ince)
Date: Wed, 12 Nov 2008 18:28:41 -0500
Subject: kerberos preauthentication IIS
References: <tsld4haqh8g.fsf@mit.edu><11114B84-4A85-4596-83DD-88B3215349BC@mit.edu><20081105233024.GO106460@Sun.COM>
	<tslej1pmxms.fsf@mit.edu><63D02894-3A1C-4EC8-82D3-F024FE9A2694@mit.edu><00d001c944be$61eb5ee0$6e00a8c0@desktop2>
	<tslr65h57dz.fsf@mit.edu>
Message-ID: <02e701c9451e$65f65e30$6e00a8c0@desktop2>

I figured it out. Here is is the solution.
krb5.ini
[libdefaults]
        default_tgs_enctypes = des-cbc-crc
        default_tkt_enctypes = des-cbc-crc

code
------------------------------------------------------------
krb5_preauthtype PREAUTH_LIST[] = {KRB5_PADATA_ENC_TIMESTAMP,0};
:
    err = krb5_get_in_tkt_with_password(
        krb5->context,
        kdcFlags, NULL, NULL, PREAUTH_LIST, password, krb5->ccache, 
&krb5->credentials, 0);

    /* if we failed try one more time w/o preauthentication */
    if(err){
        err = krb5_get_in_tkt_with_password(
            krb5->context,
            kdcFlags, NULL, NULL, NULL, password, krb5->ccache, 
&krb5->credentials, 0);
    }

----- Original Message ----- 
From: "Sam Hartman" <hartmans at mit.edu>
To: "Stephen Ince" <since at opendemand.com>
Cc: <krbdev at mit.edu>; "Matthew Devine" <mdevine at opendemand.com>
Sent: Wednesday, November 12, 2008 9:46 AM
Subject: Re: kerberos preauthentication IIS


> Hi.  You posted this message previously.  I guess you did not get a
> response.  First, you're posting to the wrong place; krbdev at mit.edu is
> for de.development discussions of MIT Kerberos.  You're not really
> talking about how to write code for Kerberos; you're more talking
> about how to use the product.  That discussion belongs on
> kerberos at mit.edu.
>
> However, I can also explain why I at least did not answer your
> question.  As far as I know, IIS does not do pre-authentication--I
> mean that in the sense that I cannot think of anything that IIS would
> be doing that would be called pre-authentication.  There is something
> Kerberos does that is called pre-authentication, but that doesn't fit
> well into your question.
>
> --Sam
>
> 


From hartmans at MIT.EDU  Wed Nov 12 23:46:03 2008
From: hartmans at MIT.EDU (Sam Hartman)
Date: Wed, 12 Nov 2008 23:46:03 -0500
Subject: kerberos preauthentication IIS
In-Reply-To: <02e701c9451e$65f65e30$6e00a8c0@desktop2> (Stephen Ince's message
	of "Wed, 12 Nov 2008 18:28:41 -0500")
References: <tsld4haqh8g.fsf@mit.edu>
	<11114B84-4A85-4596-83DD-88B3215349BC@mit.edu>
	<20081105233024.GO106460@Sun.COM> <tslej1pmxms.fsf@mit.edu>
	<63D02894-3A1C-4EC8-82D3-F024FE9A2694@mit.edu>
	<00d001c944be$61eb5ee0$6e00a8c0@desktop2> <tslr65h57dz.fsf@mit.edu>
	<02e701c9451e$65f65e30$6e00a8c0@desktop2>
Message-ID: <tslhc6c1bec.fsf@mit.edu>

Setting the default_tgs_enctypes and the default_tkt_enctypes is a fairly bad idea from a security standpoint.
It forces you to use DES, which is fairly insecure at this point rather than RC4.

Also, krb5_get_in_tkt is a deprecated API; use krb5_get_init_creds_password instead.

From hotz at jpl.nasa.gov  Thu Nov 13 14:12:44 2008
From: hotz at jpl.nasa.gov (Henry B. Hotz)
Date: Thu, 13 Nov 2008 11:12:44 -0800
Subject: kerberos preauthentication IIS
In-Reply-To: <mailman.551.1226596311.16994.krbdev@mit.edu>
References: <mailman.551.1226596311.16994.krbdev@mit.edu>
Message-ID: <491C7C2C.5050902@jpl.nasa.gov>

I'll second what Sam says:

1)  You should get better information from kerberos at mit.edu.

2)  The "solution" you show is a bad idea, though it does suggest some 
areas where the real problem may be.

Most likely you have a problem with Windows setup interactions.  This 
list is for MIT Kerberos, not Microsoft Kerberos issues.

I will suggest one hint for you to consider:  the /TrustEncryp option on 
the ktpass command.  I don't do much Windows, though, so I may be way 
off base.  I also can't help with any more details.

krbdev-request at mit.edu wrote:
> Date: Wed, 12 Nov 2008 18:28:41 -0500
> From: "Stephen Ince" <since at opendemand.com>
> Subject: Re: kerberos preauthentication IIS
> To: "Sam Hartman" <hartmans at mit.edu>
> Cc: krbdev at mit.edu
> Message-ID: <02e701c9451e$65f65e30$6e00a8c0 at desktop2>
> Content-Type: text/plain; format=flowed; charset="iso-8859-1";
>         reply-type=original
> 
> I figured it out. Here is is the solution.
> krb5.ini
> [libdefaults]
>         default_tgs_enctypes = des-cbc-crc
>         default_tkt_enctypes = des-cbc-crc
> 
> code
> ------------------------------------------------------------
> krb5_preauthtype PREAUTH_LIST[] = {KRB5_PADATA_ENC_TIMESTAMP,0};
> :
>     err = krb5_get_in_tkt_with_password(
>         krb5->context,
>         kdcFlags, NULL, NULL, PREAUTH_LIST, password, krb5->ccache,
> &krb5->credentials, 0);
> 
>     /* if we failed try one more time w/o preauthentication */
>     if(err){
>         err = krb5_get_in_tkt_with_password(
>             krb5->context,
>             kdcFlags, NULL, NULL, NULL, password, krb5->ccache,
> &krb5->credentials, 0);
>     }
> 
> ----- Original Message -----
> From: "Sam Hartman" <hartmans at mit.edu>
> To: "Stephen Ince" <since at opendemand.com>
> Cc: <krbdev at mit.edu>; "Matthew Devine" <mdevine at opendemand.com>
> Sent: Wednesday, November 12, 2008 9:46 AM
> Subject: Re: kerberos preauthentication IIS
> 
> 
>> Hi.  You posted this message previously.  I guess you did not get a
>> response.  First, you're posting to the wrong place; krbdev at mit.edu is
>> for de.development discussions of MIT Kerberos.  You're not really
>> talking about how to write code for Kerberos; you're more talking
>> about how to use the product.  That discussion belongs on
>> kerberos at mit.edu.
>>
>> However, I can also explain why I at least did not answer your
>> question.  As far as I know, IIS does not do pre-authentication--I
>> mean that in the sense that I cannot think of anything that IIS would
>> be doing that would be called pre-authentication.  There is something
>> Kerberos does that is called pre-authentication, but that doesn't fit
>> well into your question.
>>
>> --Sam

-- 
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 since at opendemand.com  Fri Nov 14 11:04:33 2008
From: since at opendemand.com (Stephen Ince)
Date: Fri, 14 Nov 2008 11:04:33 -0500
Subject: krb5_init_context krb5_parse_name memory leaks
References: <tsld4haqh8g.fsf@mit.edu><11114B84-4A85-4596-83DD-88B3215349BC@mit.edu><20081105233024.GO106460@Sun.COM>
	<tslej1pmxms.fsf@mit.edu><63D02894-3A1C-4EC8-82D3-F024FE9A2694@mit.edu><00d001c944be$61eb5ee0$6e00a8c0@desktop2>
	<tslr65h57dz.fsf@mit.edu>
Message-ID: <230801c94672$af4bb440$6e00a8c0@desktop2>

I do not know if I should post this question here or the general.
I noticed that I have the kfw-3-2-2-final kerberos api has some memory 
leaks. I am running some purify memory profiling tests. Here is what I 
noticed.

    // memory leak for krb5_parse_name (allocate)
    if (err = krb5_parse_name(krb5->context, username, &krb5->client)){

   //deallocate
   if (krb5->client) krb5_free_principal(krb5->context, krb5->client);

[W] MLK: Memory leak of 28 bytes from 1 block allocated in krb5_parse_name 
[KRB5_32.DLL]
        Distribution of leaked blocks
                28 bytes from 1 block of 28 bytes (0x003c8af8)
        Allocation location
            malloc         [C:\WINDOWS\SYSTEM32\MSVCR71.DLL]
            krb5_parse_name [C:\OPENLOAD\BIN\KRB5_32.DLL]



    // memory leak for krb5_init_context (allocate)
    if (err = krb5_init_context(&krb5->context)){ // line 92

   //deallocate
    krb5_free_context(krb5->context);


[W] MLK: Memory leak of 1164 bytes from 1 block allocated in 
krb5_init_secure_context [KRB5_32.DLL]
        Distribution of leaked blocks
              1164 bytes from 1 block of 1164 bytes (0x003c6190)
        Allocation location
            malloc         [C:\WINDOWS\SYSTEM32\MSVCR71.DLL]
            krb5_init_secure_context [C:\OPENLOAD\BIN\KRB5_32.DLL]
            krb5_init      [C:\work\flood_openload\flood_krb5.c:92]


From raeburn at MIT.EDU  Fri Nov 14 13:32:22 2008
From: raeburn at MIT.EDU (Ken Raeburn)
Date: Fri, 14 Nov 2008 13:32:22 -0500
Subject: krb5_init_context krb5_parse_name memory leaks
In-Reply-To: <230801c94672$af4bb440$6e00a8c0@desktop2>
References: <tsld4haqh8g.fsf@mit.edu><11114B84-4A85-4596-83DD-88B3215349BC@mit.edu><20081105233024.GO106460@Sun.COM>
	<tslej1pmxms.fsf@mit.edu><63D02894-3A1C-4EC8-82D3-F024FE9A2694@mit.edu><00d001c944be$61eb5ee0$6e00a8c0@desktop2>
	<tslr65h57dz.fsf@mit.edu> <230801c94672$af4bb440$6e00a8c0@desktop2>
Message-ID: <9DFA96BB-0D89-4D5B-896B-F74C89CC6A28@mit.edu>

(As an aside, please don't use "reply-to" to select a mailing list for  
a message that isn't related to the message you're "replying" to.  The  
message comes out with headers that say it's following up to that  
message and belongs in the same thread.  I suspect a lot of people use  
threaded views in their mail readers.  If I hadn't been interested in  
following up on "AEAD Encryption API" email when reading email just  
now, I would've skipped right over the whole "thread" including your  
message, which would've been displayed as one line in my mailbox  
summary.  Similarly, if I wanted to reply to some of the AEAD  
discussion just now, I would have examined the thread's messages, and  
still skipped yours as off-topic.)

On Nov 14, 2008, at 11:04, Stephen Ince wrote:
> I do not know if I should post this question here or the general.
> I noticed that I have the kfw-3-2-2-final kerberos api has some memory
> leaks. I am running some purify memory profiling tests. Here is what I
> noticed.
>
>    // memory leak for krb5_parse_name (allocate)
>    if (err = krb5_parse_name(krb5->context, username, &krb5->client)){
>
>   //deallocate
>   if (krb5->client) krb5_free_principal(krb5->context, krb5->client);
>
> [W] MLK: Memory leak of 28 bytes from 1 block allocated in  
> krb5_parse_name
> [KRB5_32.DLL]
>        Distribution of leaked blocks
>                28 bytes from 1 block of 28 bytes (0x003c8af8)
>        Allocation location
>            malloc         [C:\WINDOWS\SYSTEM32\MSVCR71.DLL]
>            krb5_parse_name [C:\OPENLOAD\BIN\KRB5_32.DLL]


On a 32-bit platform, 28 bytes looks like the right size for  
krb5_principal_data.  Maybe principal name components too, but you  
don't indicate what name is being parsed.  However,  
krb5_free_principal does free the principal data structure that it's  
passed.

These little fragments of sources aren't enough for me to figure out  
what's going on (e.g., how do I know the free routines are being  
called?), though I could write a test case of my own and see if maybe  
purify complains about it on Solaris (which is the only platform where  
we've got Purify), or valgrind on Linux/x86, but I can't be sure of  
reproducing the problem you're seeing.  Can you give me a (simple?)  
test case that definitely shows the problem for you?

Ken

From since at opendemand.com  Fri Nov 14 18:25:02 2008
From: since at opendemand.com (Stephen Ince)
Date: Fri, 14 Nov 2008 18:25:02 -0500
Subject: krb5_init_context krb5_parse_name memory leaks
References: <tsld4haqh8g.fsf@mit.edu><11114B84-4A85-4596-83DD-88B3215349BC@mit.edu><20081105233024.GO106460@Sun.COM>
	<tslej1pmxms.fsf@mit.edu><63D02894-3A1C-4EC8-82D3-F024FE9A2694@mit.edu><00d001c944be$61eb5ee0$6e00a8c0@desktop2>
	<tslr65h57dz.fsf@mit.edu> <230801c94672$af4bb440$6e00a8c0@desktop2>
	<9DFA96BB-0D89-4D5B-896B-F74C89CC6A28@mit.edu>
Message-ID: <23d001c946b0$386e4930$6e00a8c0@desktop2>

Gotcha. Won't use reply=to. I did not know that. I will try and generate a 
simple test case.


----- Original Message ----- 
From: "Ken Raeburn" <raeburn at MIT.EDU>
To: "Stephen Ince" <since at opendemand.com>
Cc: <krbdev at MIT.EDU>
Sent: Friday, November 14, 2008 1:32 PM
Subject: Re: krb5_init_context krb5_parse_name memory leaks


> (As an aside, please don't use "reply-to" to select a mailing list for  a 
> message that isn't related to the message you're "replying" to.  The 
> message comes out with headers that say it's following up to that  message 
> and belongs in the same thread.  I suspect a lot of people use  threaded 
> views in their mail readers.  If I hadn't been interested in  following up 
> on "AEAD Encryption API" email when reading email just  now, I would've 
> skipped right over the whole "thread" including your  message, which 
> would've been displayed as one line in my mailbox  summary.  Similarly, if 
> I wanted to reply to some of the AEAD  discussion just now, I would have 
> examined the thread's messages, and  still skipped yours as off-topic.)
>
> On Nov 14, 2008, at 11:04, Stephen Ince wrote:
>> I do not know if I should post this question here or the general.
>> I noticed that I have the kfw-3-2-2-final kerberos api has some memory
>> leaks. I am running some purify memory profiling tests. Here is what I
>> noticed.
>>
>>    // memory leak for krb5_parse_name (allocate)
>>    if (err = krb5_parse_name(krb5->context, username, &krb5->client)){
>>
>>   //deallocate
>>   if (krb5->client) krb5_free_principal(krb5->context, krb5->client);
>>
>> [W] MLK: Memory leak of 28 bytes from 1 block allocated in 
>> krb5_parse_name
>> [KRB5_32.DLL]
>>        Distribution of leaked blocks
>>                28 bytes from 1 block of 28 bytes (0x003c8af8)
>>        Allocation location
>>            malloc         [C:\WINDOWS\SYSTEM32\MSVCR71.DLL]
>>            krb5_parse_name [C:\OPENLOAD\BIN\KRB5_32.DLL]
>
>
> On a 32-bit platform, 28 bytes looks like the right size for 
> krb5_principal_data.  Maybe principal name components too, but you  don't 
> indicate what name is being parsed.  However,  krb5_free_principal does 
> free the principal data structure that it's  passed.
>
> These little fragments of sources aren't enough for me to figure out 
> what's going on (e.g., how do I know the free routines are being 
> called?), though I could write a test case of my own and see if maybe 
> purify complains about it on Solaris (which is the only platform where 
> we've got Purify), or valgrind on Linux/x86, but I can't be sure of 
> reproducing the problem you're seeing.  Can you give me a (simple?)  test 
> case that definitely shows the problem for you?
>
> Ken
> 


From raeburn at MIT.EDU  Fri Nov 14 19:20:54 2008
From: raeburn at MIT.EDU (Ken Raeburn)
Date: Fri, 14 Nov 2008 19:20:54 -0500
Subject: exiting multithreaded processes, unloading libraries, and cleanup
Message-ID: <E8DC2CE3-D7B7-4855-8913-84C044BE108D@mit.edu>

Our library maintains some internal state, like per-thread data,  
global linked lists of error tables, etc.  We can't simply rewrite our  
public APIs to get rid of it all, and we can't demand that people use  
non-standard APIs for stuff like GSSAPI to help us get around it.   
Because some applications may dynamically load and unload our  
libraries, we use the OS-provided library finalization hooks to free  
some things up at unload time (and I think we may miss some things but  
that's "just" a bug).  Unfortunately, the same hooks get used at  
unload and process-exit time.

We've had some bug reports of sporadic crashes in the Kerberos library  
when a multithreaded process exits.  Generally the problem seems to be  
that one process calls exit (which causes library cleanup functions to  
be invoked, which in the Kerberos libraries frees up storage, deletes  
per-thread-data keys, etc), but another process is still running code  
in the Kerberos library (which needs the freed-up data).

It appears from http://msdn.microsoft.com/en-us/library/ms682583.aspx  
that on Windows we can distinguish unloading a library from process  
termination, so we can just skip the cleanup functions in the process  
termination case, and let the actual process termination free up  
resources.  That just leaves the UNIX builds and KfM.

We can't use atexit() to set a flag to disable the cleanup functions,  
because (1) we get no guarantee of the relative order of execution of  
atexit handlers and library finalization functions, and (2) the  
registered handler would have to be removed if the library is  
unloaded, and that can't be done portably.

It occurred to me that a simple reference-count mechanism may be most  
of what we need.  Not only would an "initialized library" (init  
function called, fini function not yet called) be a reference, but  
certain objects like krb5_context would as well.  So if one thread  
calls exit and thus invokes the library finalizer functions, but  
another thread is actively messing around with a krb5_context, the  
additional internal data in the libraries won't be freed up unless the  
context is destroyed before the exiting thread finishes the cleanup  
functions.  (If the process exits first, obviously all the process  
resources go away at that time, as do any still-running threads that  
might be using them.)

Once the cleanup has been done, ideally, only a smaller subset of  
functions (like krb5_init_context) that might need some of this  
internal state can be expected to be called.  Those interfaces can  
check for the presence of this internal state, or just some flags we  
set up for the purpose, and return errors if they're called post- 
cleanup.  Unlike some random code somewhere in the middle of a library  
function that's running when the cleanup functions zap the internal  
state, the entry points of these functions won't be assuming the  
existence of that internal state.

Obviously there's some refinement to do, like breaking it down by  
library in case a process unloads gssapi but still has krb5 loaded  
through other dependencies.  And the other object types (ref counts)  
and APIs (error on post-cleanup invocation) need to be figured out, so  
it's not a trivial project.

There may be some places in the support library where this isn't  
enough, but I think it'll take care of most of the problems.

Does anyone see a problem with this sort of approach?

Ken

From raeburn at MIT.EDU  Mon Nov 17 16:07:08 2008
From: raeburn at MIT.EDU (Ken Raeburn)
Date: Mon, 17 Nov 2008 16:07:08 -0500
Subject: performance of krb5 dejagnu test suite (tests/dejagnu)
Message-ID: <828FA05F-6C13-40B9-9412-504BF89B6380@mit.edu>

Until recently, our test suite in tests/dejagnu was set up to make  
about a dozen passes through the full set of tests, with each pass  
using a different configuration of encryption types or other  
parameters specified in the config files.  This is kind of wasteful,  
because some of the tests don't exercise anything new based on the  
encryption type beyond needing to be able to get tickets of a given  
encryption type, and one test would suffice for that.  One of the  
passes differed from another only in that TCP was used to communicate  
with the KDC rather than UDP; that won't affect, for example, how well  
the ftp client and server work, as long as tickets can be acquired,  
and a program like "kvno" can test that as well as the ftp client can,  
and with less extraneous stuff going on.

There are a few tests that depend on the session key type.  For  
example, telnet requires a DES key (and we should, for example, test  
that it'll get a DES session key as long as DES is an allowed  
encryption type, even if the default session key type is not DES, and  
even if we've already got credentials with other key types), and the  
appl/bsd and GSSAPI protocols have different paths followed for each  
of the early encryption types before we generalized them properly  
(assuming that we've actually done so even now).

I checked in some changes recently to make some of the tests get run  
only once during a full run, like for example the password-changing  
tests and the new kprop test.  I got rid of the TCP pass, and replaced  
it with a separate test exercising the TCP path, which only gets run  
once.  This cut down the run time of the test suite a bit, but it's  
still kind of long.

Eventually I think we should eliminate the multiple-pass stuff in the  
overall test suite configuration, and replace it with iterators over  
certain tests, describing different enctype configurations to use.   
For example, for the rlogin/rsh/rcp tests, only the session key we're  
going to get is relevant, not the master key type in the KDC or the  
key type of the TGS principal.  (The support in the works for  
encryption type negotiation -- RFC 4537 -- will complicate those tests  
that do depend on the subsession key encryption type too, as we'll  
have to make sure that the various possible changes in encryption type  
from session key to subsession key don't break anything.)  But we  
should also test that the KDC will run and we can get tickets if those  
key types are types not supported by the clients, as long as we have a  
compatible session key type.  And other tests may depend on whether  
krb4 support is enabled, or salt types used, etc, and the iterations  
over those tests should reflect that, not the full set of enctype  
configuration options we use now.

If anyone feels like doing a bit more speedup work, the slowest tests  
that still get run in every pass or nearly every pass include rsh,  
rcp, and rlogin; in a recent test on one of my reasonably fast  
machines, each invocation took ~9 seconds or more, totaling upwards of  
6.5 minutes (out of a total of nearly 11 minutes for that whole test  
suite).  As I said above, they do need to be run for different session  
key types, but not for variations in master key type and the like.

I suspect there are probably unnecessary delays somewhere in these  
tests, too.  If nothing else, there's a two-second delay put in to  
wait for the rshd/rlogind server to start up in standalone mode (and  
similarly in many of the other tests); testing for reachability in a  
loop, or having the server output something when it's started  
listening in standalone mode, would probably let us cut the delay  
significantly in normal cases, probably to a fraction of a second.   
That might not explain how some of the tests chew up 10-16 seconds  
though.

Ken

From since at opendemand.com  Thu Nov 20 14:07:19 2008
From: since at opendemand.com (Stephen Ince)
Date: Thu, 20 Nov 2008 14:07:19 -0500
Subject: gss_krb5_ccache_name memory leak?
Message-ID: <36a601c94b43$35cd5170$6e00a8c0@desktop2>

I seem to have some memory leaks in gss_krb5_ccache_name call? I have been 
doing some snooping and it looks some state is kept per thread. It looks 
like the memory leak is linear with the number of threads. Is there a way to 
cleanup the memory for gss_krb5_ccache_name. I have tried the following.


    krb5_lock();
    if( neg_ctx->context == GSS_C_NO_CONTEXT){
        major_status =gss_krb5_ccache_name(&minor_status,krb5->ccache_name, 
&old_name);
   :
   }
    major_status = gss_init_sec_context(&minor_status,
  :
    if(old_name)gss_krb5_ccache_name(&minor_status,old_name, NULL);
    krb5_unlock();

I get the following memory leaks.
300 bytes -> 25 Threads

600 bytes -> 50 Threads

1200 bytes -> 100 Threads



From since at opendemand.com  Fri Nov 21 19:50:33 2008
From: since at opendemand.com (Stephen Ince)
Date: Fri, 21 Nov 2008 19:50:33 -0500
Subject: rewrite gss_krb5_ccache_name
Message-ID: <027201c94c3c$536422f0$6e00a8c0@desktop2>

I would like to rewrite or write a similiar function to gss_krb5_ccache_name 
that does not do any strdups.
I am using kfw-3-2-2-final on win32.  I see that gss_krb5_ccache_name is 
defined in set_ccache.c but none of the functions that it uses are exported 
or visible.
gss_krb5_ccache_name is leaking the name of the cache per thread that is 
created. Which my case is a lot of threads that get created.
Basically write a "xgss_krb5_ccache_name" that set the default kerberos 
cache but does not do a strdup.
e.g.
OM_uint32 KRB5_CALLCONV
xgss_krb5_ccache_name(minor_status, name){
:
    if (!err)
        kg_set_ccache_name (&err, name);

:
}

I noticed that kg_set_ccache_name is not visable outside the lib. I can not 
seem to find it.
Any guidance would be appreciated.


Steve 


From jaltman at secure-endpoints.com  Fri Nov 21 20:44:04 2008
From: jaltman at secure-endpoints.com (Jeffrey Altman)
Date: Fri, 21 Nov 2008 20:44:04 -0500
Subject: rewrite gss_krb5_ccache_name
In-Reply-To: <027201c94c3c$536422f0$6e00a8c0@desktop2>
References: <027201c94c3c$536422f0$6e00a8c0@desktop2>
Message-ID: <492763E4.6090400@secure-endpoints.com>

Stephen Ince wrote:
> I would like to rewrite or write a similiar function to gss_krb5_ccache_name 
> that does not do any strdups.
> I am using kfw-3-2-2-final on win32.  I see that gss_krb5_ccache_name is 
> defined in set_ccache.c but none of the functions that it uses are exported 
> or visible.
> gss_krb5_ccache_name is leaking the name of the cache per thread that is 
> created. Which my case is a lot of threads that get created.
> Basically write a "xgss_krb5_ccache_name" that set the default kerberos 
> cache but does not do a strdup.
> e.g.
> OM_uint32 KRB5_CALLCONV
> xgss_krb5_ccache_name(minor_status, name){
> :
>     if (!err)
>         kg_set_ccache_name (&err, name);
> 
> :
> }
> 
> I noticed that kg_set_ccache_name is not visable outside the lib. I can not 
> seem to find it.
> Any guidance would be appreciated.
> 
> 
> Steve 

Steve:

For thread safety reasons the gss library uses thread local storage
(TLS) to store a number of values including ccache name and error
messages.  The TLS stored value must be a copy in order to prevent
corruption when the original source string is deallocated or altered.

It sounds like the processing model that you are using is similar to:

 1. accept incoming connection
 2. create thread to process the connection
 3. upon completion of the connection, terminate thread

which in turn is resulting in leakage of the TLS stored values.

If that is the case, the real bug here is that the gssapi32.dll
does not implement a DLL_THREAD_DETACH routine which would free
any allocated memory stored under the registered TLS keys.

Please confirm.

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

From jhutz at cmu.edu  Fri Nov 21 22:28:54 2008
From: jhutz at cmu.edu (Jeffrey Hutzelman)
Date: Fri, 21 Nov 2008 21:28:54 -0600
Subject: rewrite gss_krb5_ccache_name
In-Reply-To: <200811220145.mAM1j2fX013202@toasties.srv.cs.cmu.edu>
References: <027201c94c3c$536422f0$6e00a8c0@desktop2>
	<200811220145.mAM1j2fX013202@toasties.srv.cs.cmu.edu>
Message-ID: <F48BB6E07FADAF71DD35AED3@atlantis.pc.cs.cmu.edu>

--On Friday, November 21, 2008 08:44:04 PM -0500 Jeffrey Altman 
<jaltman at secure-endpoints.com> wrote:

> For thread safety reasons the gss library uses thread local storage
> (TLS) to store a number of values including ccache name and error
> messages.  The TLS stored value must be a copy in order to prevent
> corruption when the original source string is deallocated or altered.

In the example Stephen posted, he does the following:

    krb5_lock();
    if( neg_ctx->context == GSS_C_NO_CONTEXT){
        major_status =gss_krb5_ccache_name(&minor_status,krb5->ccache_name,
&old_name);
   :
   }
    major_status = gss_init_sec_context(&minor_status,
  :
    if(old_name)gss_krb5_ccache_name(&minor_status,old_name, NULL);
    krb5_unlock();


In this example, when the first call to gss_krb5_ccache_name() is called, 
the library makes a copy of krb5->ccache_name and stores it in TLS, as Jeff 
describes above.  It must make a copy, because, as Jeff hints, the library 
doesn't know that you aren't going to do something to that string after the 
call returns which changes it or makes it invalid, or do something like 
pass the same pointer to gss_krb5_ccache_name() in multiple threads.  It 
would be possible to have an alternative interface in which you pass 
&krb5->ccache_name and the library zeroes it, but that would likely be less 
convenient for this caller, and a number of others.  It would also mean 
that krb5->ccache_name would have to have been dynamically allocated by the 
caller, because the library's thread destructor has to free it if the 
thread exits or is cancelled without explicitly reclaiming the TLS.

The first call to gss_krb5_ccache_name() also returns in old_name the 
previous ccache name (or a dynamically-allocated copy, with the library's 
copy being freed).  Once the call returns, this value belongs to the 
caller; the library guarantees it no longer has a copy of it.  That also 
means it's the caller's to free.

The second call to gss_krb5_ccache_name() behaves exactly as the first.  It 
stores a copy of old_name, not the original, for the same reasons as 
before.  It also frees the previously-set value without returning it, since 
the third argument was given as NULL.


After the second call to gss_krb5_ccache_name(), old_name STILL belongs to 
the caller.  In this case it is the calling thread which is failing to free 
storage.



> If that is the case, the real bug here is that the gssapi32.dll
> does not implement a DLL_THREAD_DETACH routine which would free
> any allocated memory stored under the registered TLS keys.

Well, if you're not doing that, you certainly should...

-- Jeff

From jaltman at secure-endpoints.com  Fri Nov 21 23:57:54 2008
From: jaltman at secure-endpoints.com (Jeffrey Altman)
Date: Fri, 21 Nov 2008 23:57:54 -0500
Subject: rewrite gss_krb5_ccache_name
In-Reply-To: <F48BB6E07FADAF71DD35AED3@atlantis.pc.cs.cmu.edu>
References: <027201c94c3c$536422f0$6e00a8c0@desktop2>	<200811220145.mAM1j2fX013202@toasties.srv.cs.cmu.edu>
	<F48BB6E07FADAF71DD35AED3@atlantis.pc.cs.cmu.edu>
Message-ID: <49279152.9030701@secure-endpoints.com>

Jeffrey Hutzelman wrote:
> --On Friday, November 21, 2008 08:44:04 PM -0500 Jeffrey Altman 
> <jaltman at secure-endpoints.com> wrote:
> 
>> For thread safety reasons the gss library uses thread local storage
>> (TLS) to store a number of values including ccache name and error
>> messages.  The TLS stored value must be a copy in order to prevent
>> corruption when the original source string is deallocated or altered.
> 
> In the example Stephen posted, he does the following:
> 
>     krb5_lock();
>     if( neg_ctx->context == GSS_C_NO_CONTEXT){
>         major_status =gss_krb5_ccache_name(&minor_status,krb5->ccache_name,
> &old_name);
>    :
>    }
>     major_status = gss_init_sec_context(&minor_status,
>   :
>     if(old_name)gss_krb5_ccache_name(&minor_status,old_name, NULL);
>     krb5_unlock();
> 

Stephen wrote that he tried the above code only after

   major_status =gss_krb5_ccache_name(&minor_status,
                                      krb5_ccache_name,
                                      NULL);

resulted in a leak.  When the 'old_name' parameter is provided a NULL
input there is no responsibility on the part of the function caller
to free the memory.

Note that there is a second problem with this api.  When a non-NULL
'old_name' parameter is provided, it must be freed using the same
free() as is linked to the gssapi32.dll library.  Unfortunately,
there is no gss_krb5_free_ccname() function in the API available
to make sure that this is possible.  As a result, passing anything
other than NULL as the 'old_name' parameter is dangerous on Windows.

>> If that is the case, the real bug here is that the gssapi32.dll
>> does not implement a DLL_THREAD_DETACH routine which would free
>> any allocated memory stored under the registered TLS keys.
> 
> Well, if you're not doing that, you certainly should...

Indeed, this should be fixed.

Jeffrey Altman



From jhutz at cmu.edu  Sat Nov 22 00:13:21 2008
From: jhutz at cmu.edu (Jeffrey Hutzelman)
Date: Fri, 21 Nov 2008 23:13:21 -0600
Subject: rewrite gss_krb5_ccache_name
In-Reply-To: <49279152.9030701@secure-endpoints.com>
References: <027201c94c3c$536422f0$6e00a8c0@desktop2>
	<200811220145.mAM1j2fX013202@toasties.srv.cs.cmu.edu>
	<F48BB6E07FADAF71DD35AED3@atlantis.pc.cs.cmu.edu>
	<49279152.9030701@secure-endpoints.com>
Message-ID: <517F56DD1283DFF10635C66F@atlantis.pc.cs.cmu.edu>

--On Friday, November 21, 2008 11:57:54 PM -0500 Jeffrey Altman 
<jaltman at secure-endpoints.com> wrote:

> Note that there is a second problem with this api.  When a non-NULL
> 'old_name' parameter is provided, it must be freed using the same
> free() as is linked to the gssapi32.dll library.  Unfortunately,
> there is no gss_krb5_free_ccname() function in the API available
> to make sure that this is possible.  As a result, passing anything
> other than NULL as the 'old_name' parameter is dangerous on Windows.

This is indeed a bug in the API.  The old_name parameter should never have 
been a char **; it should have been a gss_buffer_t, which would have 
allowed it to be released using gss_release_buffer().

-- Jeff

From since at opendemand.com  Sat Nov 22 10:33:34 2008
From: since at opendemand.com (Stephen Ince)
Date: Sat, 22 Nov 2008 10:33:34 -0500
Subject: rewrite gss_krb5_ccache_name 
References: <027201c94c3c$536422f0$6e00a8c0@desktop2>
	<200811220145.mAM1j2fX013202@toasties.srv.cs.cmu.edu>
	<F48BB6E07FADAF71DD35AED3@atlantis.pc.cs.cmu.edu>
	<49279152.9030701@secure-endpoints.com>
	<517F56DD1283DFF10635C66F@atlantis.pc.cs.cmu.edu>
Message-ID: <02e501c94cb7$ae8e5760$6e00a8c0@desktop2>

Is there a work around for this? Can I write my own xgss_krb5_ccache_name? 
Or can I force a free?

----- Original Message ----- 
From: "Jeffrey Hutzelman" <jhutz at cmu.edu>
To: <jaltman at secure-endpoints.com>
Cc: "Stephen Ince" <since at opendemand.com>; "krbdev" <krbdev at mit.edu>; 
<jhutz at cmu.edu>
Sent: Saturday, November 22, 2008 12:13 AM
Subject: Re: rewrite gss_krb5_ccache_name


> --On Friday, November 21, 2008 11:57:54 PM -0500 Jeffrey Altman 
> <jaltman at secure-endpoints.com> wrote:
>
>> Note that there is a second problem with this api.  When a non-NULL
>> 'old_name' parameter is provided, it must be freed using the same
>> free() as is linked to the gssapi32.dll library.  Unfortunately,
>> there is no gss_krb5_free_ccname() function in the API available
>> to make sure that this is possible.  As a result, passing anything
>> other than NULL as the 'old_name' parameter is dangerous on Windows.
>
> This is indeed a bug in the API.  The old_name parameter should never have 
> been a char **; it should have been a gss_buffer_t, which would have 
> allowed it to be released using gss_release_buffer().
>
> -- Jeff
> 


From jaltman at secure-endpoints.com  Sat Nov 22 10:54:56 2008
From: jaltman at secure-endpoints.com (Jeffrey Altman)
Date: Sat, 22 Nov 2008 10:54:56 -0500
Subject: rewrite gss_krb5_ccache_name
In-Reply-To: <02e501c94cb7$ae8e5760$6e00a8c0@desktop2>
References: <027201c94c3c$536422f0$6e00a8c0@desktop2>
	<200811220145.mAM1j2fX013202@toasties.srv.cs.cmu.edu>
	<F48BB6E07FADAF71DD35AED3@atlantis.pc.cs.cmu.edu>
	<49279152.9030701@secure-endpoints.com>
	<517F56DD1283DFF10635C66F@atlantis.pc.cs.cmu.edu>
	<02e501c94cb7$ae8e5760$6e00a8c0@desktop2>
Message-ID: <49282B50.4020903@secure-endpoints.com>

You do not need to write this function.   That is not the bug you are
experiencing.
The bug is the library's failure to deallocate memory assigned to Thread
Local Storage.
You are not using the 'old_name' parameter set to anything other than NULL.

The way to avoid this problem is to redesign your application to use a
pool of pre-existing worker threads instead of spinning off a new thread
for each connection and letting it die when the application terminates. 
This solution would also use less CPU.

Jeffrey Altman

Stephen Ince wrote:
> Is there a work around for this? Can I write my own
> xgss_krb5_ccache_name? Or can I force a free?
>
> ----- Original Message ----- From: "Jeffrey Hutzelman" <jhutz at cmu.edu>
> To: <jaltman at secure-endpoints.com>
> Cc: "Stephen Ince" <since at opendemand.com>; "krbdev" <krbdev at mit.edu>;
> <jhutz at cmu.edu>
> Sent: Saturday, November 22, 2008 12:13 AM
> Subject: Re: rewrite gss_krb5_ccache_name
>
>
>> --On Friday, November 21, 2008 11:57:54 PM -0500 Jeffrey Altman
>> <jaltman at secure-endpoints.com> wrote:
>>
>>> Note that there is a second problem with this api.  When a non-NULL
>>> 'old_name' parameter is provided, it must be freed using the same
>>> free() as is linked to the gssapi32.dll library.  Unfortunately,
>>> there is no gss_krb5_free_ccname() function in the API available
>>> to make sure that this is possible.  As a result, passing anything
>>> other than NULL as the 'old_name' parameter is dangerous on Windows.
>>
>> This is indeed a bug in the API.  The old_name parameter should never
>> have been a char **; it should have been a gss_buffer_t, which would
>> have allowed it to be released using gss_release_buffer().
>>
>> -- Jeff
>>
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3355 bytes
Desc: S/MIME Cryptographic Signature
Url : http://mailman.mit.edu/pipermail/krbdev/attachments/20081122/00ff882f/smime.bin

From raeburn at MIT.EDU  Sat Nov 22 12:08:06 2008
From: raeburn at MIT.EDU (Ken Raeburn)
Date: Sat, 22 Nov 2008 12:08:06 -0500
Subject: rewrite gss_krb5_ccache_name
In-Reply-To: <49279152.9030701@secure-endpoints.com>
References: <027201c94c3c$536422f0$6e00a8c0@desktop2>	<200811220145.mAM1j2fX013202@toasties.srv.cs.cmu.edu>
	<F48BB6E07FADAF71DD35AED3@atlantis.pc.cs.cmu.edu>
	<49279152.9030701@secure-endpoints.com>
Message-ID: <CA23B028-E87E-493F-BB6F-E9911FAF8690@mit.edu>

On Nov 21, 2008, at 23:57, Jeffrey Altman wrote:
>>> If that is the case, the real bug here is that the gssapi32.dll
>>> does not implement a DLL_THREAD_DETACH routine which would free
>>> any allocated memory stored under the registered TLS keys.
>>
>> Well, if you're not doing that, you certainly should...
>
> Indeed, this should be fixed.

Looks to me like krb5int_thread_detach_hook should mostly be doing  
that.  It's the handler in the support library, but all our TSD use is  
funneled through some bookkeeping in the support library, to improve  
things on platforms where OS handles (TLS indices, pthread keys) on  
TSD may be a limited resource.  It ought to be deallocating any  
registered per-thread data, though it looks like maybe the bookkeeping  
data itself isn't properly freed.

Ken

From since at opendemand.com  Sat Nov 22 13:29:16 2008
From: since at opendemand.com (Stephen Ince)
Date: Sat, 22 Nov 2008 13:29:16 -0500
Subject: rewrite gss_krb5_ccache_name
References: <027201c94c3c$536422f0$6e00a8c0@desktop2>
	<200811220145.mAM1j2fX013202@toasties.srv.cs.cmu.edu>
	<F48BB6E07FADAF71DD35AED3@atlantis.pc.cs.cmu.edu>
	<49279152.9030701@secure-endpoints.com>
	<517F56DD1283DFF10635C66F@atlantis.pc.cs.cmu.edu>
	<02e501c94cb7$ae8e5760$6e00a8c0@desktop2>
	<49282B50.4020903@secure-endpoints.com>
Message-ID: <031501c94cd0$39fc14a0$6e00a8c0@desktop2>

Thx. Not really possible and has other side effects. We need the application 
needs to run as lean as possible. One thread consumes a lot of memory and 
will have to be around for the life of the program. At one point you could 
have 2000 threads and at another point 10 threads. We basically simulate 
browsers and their http connections.

Steve
----- Original Message ----- 
From: "Jeffrey Altman" <jaltman at secure-endpoints.com>
To: "Stephen Ince" <since at opendemand.com>
Cc: "Jeffrey Hutzelman" <jhutz at cmu.edu>; "krbdev" <krbdev at mit.edu>
Sent: Saturday, November 22, 2008 10:54 AM
Subject: Re: rewrite gss_krb5_ccache_name


> You do not need to write this function.   That is not the bug you are
> experiencing.
> The bug is the library's failure to deallocate memory assigned to Thread
> Local Storage.
> You are not using the 'old_name' parameter set to anything other than 
> NULL.
>
> The way to avoid this problem is to redesign your application to use a
> pool of pre-existing worker threads instead of spinning off a new thread
> for each connection and letting it die when the application terminates.
> This solution would also use less CPU.
>
> Jeffrey Altman
>
> Stephen Ince wrote:
>> Is there a work around for this? Can I write my own
>> xgss_krb5_ccache_name? Or can I force a free?
>>
>> ----- Original Message ----- From: "Jeffrey Hutzelman" <jhutz at cmu.edu>
>> To: <jaltman at secure-endpoints.com>
>> Cc: "Stephen Ince" <since at opendemand.com>; "krbdev" <krbdev at mit.edu>;
>> <jhutz at cmu.edu>
>> Sent: Saturday, November 22, 2008 12:13 AM
>> Subject: Re: rewrite gss_krb5_ccache_name
>>
>>
>>> --On Friday, November 21, 2008 11:57:54 PM -0500 Jeffrey Altman
>>> <jaltman at secure-endpoints.com> wrote:
>>>
>>>> Note that there is a second problem with this api.  When a non-NULL
>>>> 'old_name' parameter is provided, it must be freed using the same
>>>> free() as is linked to the gssapi32.dll library.  Unfortunately,
>>>> there is no gss_krb5_free_ccname() function in the API available
>>>> to make sure that this is possible.  As a result, passing anything
>>>> other than NULL as the 'old_name' parameter is dangerous on Windows.
>>>
>>> This is indeed a bug in the API.  The old_name parameter should never
>>> have been a char **; it should have been a gss_buffer_t, which would
>>> have allowed it to be released using gss_release_buffer().
>>>
>>> -- Jeff
>>>
>>
> 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 1880 bytes
Desc: not available
Url : http://mailman.mit.edu/pipermail/krbdev/attachments/20081122/c6c42e07/smime.bin

From deengert at anl.gov  Mon Nov 24 11:01:24 2008
From: deengert at anl.gov (Douglas E. Engert)
Date: Mon, 24 Nov 2008 10:01:24 -0600
Subject: rewrite gss_krb5_ccache_name
In-Reply-To: <031501c94cd0$39fc14a0$6e00a8c0@desktop2>
References: <027201c94c3c$536422f0$6e00a8c0@desktop2>	<200811220145.mAM1j2fX013202@toasties.srv.cs.cmu.edu>	<F48BB6E07FADAF71DD35AED3@atlantis.pc.cs.cmu.edu>	<49279152.9030701@secure-endpoints.com>	<517F56DD1283DFF10635C66F@atlantis.pc.cs.cmu.edu>	<02e501c94cb7$ae8e5760$6e00a8c0@desktop2>	<49282B50.4020903@secure-endpoints.com>
	<031501c94cd0$39fc14a0$6e00a8c0@desktop2>
Message-ID: <492ACFD4.8040502@anl.gov>



Stephen Ince wrote:
> Thx. Not really possible and has other side effects. We need the 
> application needs to run as lean as possible. One thread consumes a lot 
> of memory and will have to be around for the life of the program. At one 
> point you could have 2000 threads and at another point 10 threads. We 
> basically simulate browsers and their http connections.


As a temporary fix, could you do something like:

char * not_needed_name;
gss_buffer_desc not_needed_buffer;

not_needed_name = NULL;
major_status =gss_krb5_ccache_name(&minor_status,
                                       krb5_ccache_name,
                                       &not_needed_name);
if (not_needed_name) {
    not_needed_buffer.length = strlen(not_needed_name)+1;
    not_needed_buffer.value = not_needed_name;
    gss_release_buffer(&minor_status, &not_needed_buffer);
    not_needed_name = NULL;
}

This would then allow you application to get the string
so it can be freeded, but let the gssapi lib use the free()
function linked with the lib.

> 
> Steve
> ----- Original Message ----- From: "Jeffrey Altman" 
> <jaltman at secure-endpoints.com>
> To: "Stephen Ince" <since at opendemand.com>
> Cc: "Jeffrey Hutzelman" <jhutz at cmu.edu>; "krbdev" <krbdev at mit.edu>
> Sent: Saturday, November 22, 2008 10:54 AM
> Subject: Re: rewrite gss_krb5_ccache_name
> 
> 
>> You do not need to write this function.   That is not the bug you are
>> experiencing.
>> The bug is the library's failure to deallocate memory assigned to Thread
>> Local Storage.
>> You are not using the 'old_name' parameter set to anything other than 
>> NULL.
>>
>> The way to avoid this problem is to redesign your application to use a
>> pool of pre-existing worker threads instead of spinning off a new thread
>> for each connection and letting it die when the application terminates.
>> This solution would also use less CPU.
>>
>> Jeffrey Altman
>>
>> Stephen Ince wrote:
>>> Is there a work around for this? Can I write my own
>>> xgss_krb5_ccache_name? Or can I force a free?
>>>
>>> ----- Original Message ----- From: "Jeffrey Hutzelman" <jhutz at cmu.edu>
>>> To: <jaltman at secure-endpoints.com>
>>> Cc: "Stephen Ince" <since at opendemand.com>; "krbdev" <krbdev at mit.edu>;
>>> <jhutz at cmu.edu>
>>> Sent: Saturday, November 22, 2008 12:13 AM
>>> Subject: Re: rewrite gss_krb5_ccache_name
>>>
>>>
>>>> --On Friday, November 21, 2008 11:57:54 PM -0500 Jeffrey Altman
>>>> <jaltman at secure-endpoints.com> wrote:
>>>>
>>>>> Note that there is a second problem with this api.  When a non-NULL
>>>>> 'old_name' parameter is provided, it must be freed using the same
>>>>> free() as is linked to the gssapi32.dll library.  Unfortunately,
>>>>> there is no gss_krb5_free_ccname() function in the API available
>>>>> to make sure that this is possible.  As a result, passing anything
>>>>> other than NULL as the 'old_name' parameter is dangerous on Windows.
>>>>
>>>> This is indeed a bug in the API.  The old_name parameter should never
>>>> have been a char **; it should have been a gss_buffer_t, which would
>>>> have allowed it to be released using gss_release_buffer().
>>>>
>>>> -- Jeff
>>>>
>>>
>>
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> krbdev mailing list             krbdev at mit.edu
> https://mailman.mit.edu/mailman/listinfo/krbdev

-- 

  Douglas E. Engert  <DEEngert at anl.gov>
  Argonne National Laboratory
  9700 South Cass Avenue
  Argonne, Illinois  60439
  (630) 252-5444

From since at opendemand.com  Mon Nov 24 11:38:39 2008
From: since at opendemand.com (Stephen Ince)
Date: Mon, 24 Nov 2008 11:38:39 -0500
Subject: rewrite gss_krb5_ccache_name
References: <027201c94c3c$536422f0$6e00a8c0@desktop2>	<200811220145.mAM1j2fX013202@toasties.srv.cs.cmu.edu>	<F48BB6E07FADAF71DD35AED3@atlantis.pc.cs.cmu.edu>	<49279152.9030701@secure-endpoints.com>	<517F56DD1283DFF10635C66F@atlantis.pc.cs.cmu.edu>	<02e501c94cb7$ae8e5760$6e00a8c0@desktop2>	<49282B50.4020903@secure-endpoints.com>
	<031501c94cd0$39fc14a0$6e00a8c0@desktop2>
	<492ACFD4.8040502@anl.gov>
Message-ID: <046401c94e53$1b2fa850$6e00a8c0@desktop2>

Douglas,
  Thx for the suggestion but that did not work. I think the old reference is 
for previous cache name. Same number of bytes leaked and purify complained 
that the memory was being freed twice.

Steve
----- Original Message ----- 
From: "Douglas E. Engert" <deengert at anl.gov>
To: "Stephen Ince" <since at opendemand.com>
Cc: <jaltman at secure-endpoints.com>; "krbdev" <krbdev at mit.edu>; "Jeffrey 
Hutzelman" <jhutz at cmu.edu>
Sent: Monday, November 24, 2008 11:01 AM
Subject: Re: rewrite gss_krb5_ccache_name


>
>
> Stephen Ince wrote:
>> Thx. Not really possible and has other side effects. We need the 
>> application needs to run as lean as possible. One thread consumes a lot 
>> of memory and will have to be around for the life of the program. At one 
>> point you could have 2000 threads and at another point 10 threads. We 
>> basically simulate browsers and their http connections.
>
>
> As a temporary fix, could you do something like:
>
> char * not_needed_name;
> gss_buffer_desc not_needed_buffer;
>
> not_needed_name = NULL;
> major_status =gss_krb5_ccache_name(&minor_status,
>                                       krb5_ccache_name,
>                                       &not_needed_name);
> if (not_needed_name) {
>    not_needed_buffer.length = strlen(not_needed_name)+1;
>    not_needed_buffer.value = not_needed_name;
>    gss_release_buffer(&minor_status, &not_needed_buffer);
>    not_needed_name = NULL;
> }
>
> This would then allow you application to get the string
> so it can be freeded, but let the gssapi lib use the free()
> function linked with the lib.
>
>>
>> Steve
>> ----- Original Message ----- From: "Jeffrey Altman" 
>> <jaltman at secure-endpoints.com>
>> To: "Stephen Ince" <since at opendemand.com>
>> Cc: "Jeffrey Hutzelman" <jhutz at cmu.edu>; "krbdev" <krbdev at mit.edu>
>> Sent: Saturday, November 22, 2008 10:54 AM
>> Subject: Re: rewrite gss_krb5_ccache_name
>>
>>
>>> You do not need to write this function.   That is not the bug you are
>>> experiencing.
>>> The bug is the library's failure to deallocate memory assigned to Thread
>>> Local Storage.
>>> You are not using the 'old_name' parameter set to anything other than 
>>> NULL.
>>>
>>> The way to avoid this problem is to redesign your application to use a
>>> pool of pre-existing worker threads instead of spinning off a new thread
>>> for each connection and letting it die when the application terminates.
>>> This solution would also use less CPU.
>>>
>>> Jeffrey Altman
>>>
>>> Stephen Ince wrote:
>>>> Is there a work around for this? Can I write my own
>>>> xgss_krb5_ccache_name? Or can I force a free?
>>>>
>>>> ----- Original Message ----- From: "Jeffrey Hutzelman" <jhutz at cmu.edu>
>>>> To: <jaltman at secure-endpoints.com>
>>>> Cc: "Stephen Ince" <since at opendemand.com>; "krbdev" <krbdev at mit.edu>;
>>>> <jhutz at cmu.edu>
>>>> Sent: Saturday, November 22, 2008 12:13 AM
>>>> Subject: Re: rewrite gss_krb5_ccache_name
>>>>
>>>>
>>>>> --On Friday, November 21, 2008 11:57:54 PM -0500 Jeffrey Altman
>>>>> <jaltman at secure-endpoints.com> wrote:
>>>>>
>>>>>> Note that there is a second problem with this api.  When a non-NULL
>>>>>> 'old_name' parameter is provided, it must be freed using the same
>>>>>> free() as is linked to the gssapi32.dll library.  Unfortunately,
>>>>>> there is no gss_krb5_free_ccname() function in the API available
>>>>>> to make sure that this is possible.  As a result, passing anything
>>>>>> other than NULL as the 'old_name' parameter is dangerous on Windows.
>>>>>
>>>>> This is indeed a bug in the API.  The old_name parameter should never
>>>>> have been a char **; it should have been a gss_buffer_t, which would
>>>>> have allowed it to be released using gss_release_buffer().
>>>>>
>>>>> -- Jeff
>>>>>
>>>>
>>>
>>
>> ------------------------------------------------------------------------
>>
>> _______________________________________________
>> krbdev mailing list             krbdev at mit.edu
>> https://mailman.mit.edu/mailman/listinfo/krbdev
>
> -- 
>
>  Douglas E. Engert  <DEEngert at anl.gov>
>  Argonne National Laboratory
>  9700 South Cass Avenue
>  Argonne, Illinois  60439
>  (630) 252-5444
> 


From jaltman at secure-endpoints.com  Mon Nov 24 12:10:05 2008
From: jaltman at secure-endpoints.com (Jeffrey Altman)
Date: Mon, 24 Nov 2008 12:10:05 -0500
Subject: rewrite gss_krb5_ccache_name
In-Reply-To: <492ACFD4.8040502@anl.gov>
References: <027201c94c3c$536422f0$6e00a8c0@desktop2>	<200811220145.mAM1j2fX013202@toasties.srv.cs.cmu.edu>	<F48BB6E07FADAF71DD35AED3@atlantis.pc.cs.cmu.edu>	<49279152.9030701@secure-endpoints.com>	<517F56DD1283DFF10635C66F@atlantis.pc.cs.cmu.edu>	<02e501c94cb7$ae8e5760$6e00a8c0@desktop2>	<49282B50.4020903@secure-endpoints.com>
	<031501c94cd0$39fc14a0$6e00a8c0@desktop2>
	<492ACFD4.8040502@anl.gov>
Message-ID: <492ADFED.6090507@secure-endpoints.com>

Douglas E. Engert wrote:
>
>
> Stephen Ince wrote:
>> Thx. Not really possible and has other side effects. We need the
>> application needs to run as lean as possible. One thread consumes a
>> lot of memory and will have to be around for the life of the program.
>> At one point you could have 2000 threads and at another point 10
>> threads. We basically simulate browsers and their http connections.
>
>
> As a temporary fix, could you do something like:
>
> char * not_needed_name;
> gss_buffer_desc not_needed_buffer;
>
> not_needed_name = NULL;
> major_status =gss_krb5_ccache_name(&minor_status,
>                                       krb5_ccache_name,
>                                       &not_needed_name);
> if (not_needed_name) {
>    not_needed_buffer.length = strlen(not_needed_name)+1;
>    not_needed_buffer.value = not_needed_name;
>    gss_release_buffer(&minor_status, &not_needed_buffer);
>    not_needed_name = NULL;
> }
>
> This would then allow you application to get the string
> so it can be freeded, but let the gssapi lib use the free()
> function linked with the lib.
Doug:

That could be done byt why do it when passing NULL instead of
&not_needed_name causes gss_krb5_ccache_name() to free the
C string instead of returning it?

Jeffrey Altman

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3355 bytes
Desc: S/MIME Cryptographic Signature
Url : http://mailman.mit.edu/pipermail/krbdev/attachments/20081124/270f1dfa/smime.bin

From since at opendemand.com  Mon Nov 24 12:14:50 2008
From: since at opendemand.com (Stephen Ince)
Date: Mon, 24 Nov 2008 12:14:50 -0500
Subject: rewrite gss_krb5_ccache_name
References: <027201c94c3c$536422f0$6e00a8c0@desktop2>	<200811220145.mAM1j2fX013202@toasties.srv.cs.cmu.edu>	<F48BB6E07FADAF71DD35AED3@atlantis.pc.cs.cmu.edu>	<49279152.9030701@secure-endpoints.com>	<517F56DD1283DFF10635C66F@atlantis.pc.cs.cmu.edu>	<02e501c94cb7$ae8e5760$6e00a8c0@desktop2>	<49282B50.4020903@secure-endpoints.com>
	<031501c94cd0$39fc14a0$6e00a8c0@desktop2>
	<492ACFD4.8040502@anl.gov> <492ADFED.6090507@secure-endpoints.com>
Message-ID: <055f01c94e58$296d3040$6e00a8c0@desktop2>

NULL does not work and "" does not work.

gss_krb5_ccache_name(&minor_status,"", NULL);
gss_krb5_ccache_name(&minor_status,NULL, NULL);
----- Original Message ----- 
From: "Jeffrey Altman" <jaltman at secure-endpoints.com>
To: <deengert at anl.gov>
Cc: "Stephen Ince" <since at opendemand.com>; "krbdev" <krbdev at mit.edu>; 
"Jeffrey Hutzelman" <jhutz at cmu.edu>
Sent: Monday, November 24, 2008 12:10 PM
Subject: Re: rewrite gss_krb5_ccache_name


> Douglas E. Engert wrote:
>>
>>
>> Stephen Ince wrote:
>>> Thx. Not really possible and has other side effects. We need the
>>> application needs to run as lean as possible. One thread consumes a
>>> lot of memory and will have to be around for the life of the program.
>>> At one point you could have 2000 threads and at another point 10
>>> threads. We basically simulate browsers and their http connections.
>>
>>
>> As a temporary fix, could you do something like:
>>
>> char * not_needed_name;
>> gss_buffer_desc not_needed_buffer;
>>
>> not_needed_name = NULL;
>> major_status =gss_krb5_ccache_name(&minor_status,
>>                                       krb5_ccache_name,
>>                                       &not_needed_name);
>> if (not_needed_name) {
>>    not_needed_buffer.length = strlen(not_needed_name)+1;
>>    not_needed_buffer.value = not_needed_name;
>>    gss_release_buffer(&minor_status, &not_needed_buffer);
>>    not_needed_name = NULL;
>> }
>>
>> This would then allow you application to get the string
>> so it can be freeded, but let the gssapi lib use the free()
>> function linked with the lib.
> Doug:
>
> That could be done byt why do it when passing NULL instead of
> &not_needed_name causes gss_krb5_ccache_name() to free the
> C string instead of returning it?
>
> Jeffrey Altman
>
> 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 1880 bytes
Desc: not available
Url : http://mailman.mit.edu/pipermail/krbdev/attachments/20081124/f58230f3/smime.bin

From deengert at anl.gov  Mon Nov 24 12:18:31 2008
From: deengert at anl.gov (Douglas E. Engert)
Date: Mon, 24 Nov 2008 11:18:31 -0600
Subject: rewrite gss_krb5_ccache_name
In-Reply-To: <492ADFED.6090507@secure-endpoints.com>
References: <027201c94c3c$536422f0$6e00a8c0@desktop2>	<200811220145.mAM1j2fX013202@toasties.srv.cs.cmu.edu>	<F48BB6E07FADAF71DD35AED3@atlantis.pc.cs.cmu.edu>	<49279152.9030701@secure-endpoints.com>	<517F56DD1283DFF10635C66F@atlantis.pc.cs.cmu.edu>	<02e501c94cb7$ae8e5760$6e00a8c0@desktop2>	<49282B50.4020903@secure-endpoints.com>	<031501c94cd0$39fc14a0$6e00a8c0@desktop2>	<492ACFD4.8040502@anl.gov>
	<492ADFED.6090507@secure-endpoints.com>
Message-ID: <492AE1E7.1090708@anl.gov>



Jeffrey Altman wrote:
> Douglas E. Engert wrote:
>>
>> Stephen Ince wrote:
>>> Thx. Not really possible and has other side effects. We need the
>>> application needs to run as lean as possible. One thread consumes a
>>> lot of memory and will have to be around for the life of the program.
>>> At one point you could have 2000 threads and at another point 10
>>> threads. We basically simulate browsers and their http connections.
>>
>> As a temporary fix, could you do something like:
>>
>> char * not_needed_name;
>> gss_buffer_desc not_needed_buffer;
>>
>> not_needed_name = NULL;
>> major_status =gss_krb5_ccache_name(&minor_status,
>>                                       krb5_ccache_name,
>>                                       &not_needed_name);
>> if (not_needed_name) {
>>    not_needed_buffer.length = strlen(not_needed_name)+1;
>>    not_needed_buffer.value = not_needed_name;
>>    gss_release_buffer(&minor_status, &not_needed_buffer);
>>    not_needed_name = NULL;
>> }
>>
>> This would then allow you application to get the string
>> so it can be freeded, but let the gssapi lib use the free()
>> function linked with the lib.
> Doug:
> 
> That could be done byt why do it when passing NULL instead of
> &not_needed_name causes gss_krb5_ccache_name() to free the
> C string instead of returning it?

I might have miss understood the problem. I though he was saying the
when he use the NULL there was a leak. But if he passed &not_needed_name
the library would not leak, and he could then free the string using this
trick.

> 
> Jeffrey Altman
> 
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> krbdev mailing list             krbdev at mit.edu
> https://mailman.mit.edu/mailman/listinfo/krbdev

-- 

  Douglas E. Engert  <DEEngert at anl.gov>
  Argonne National Laboratory
  9700 South Cass Avenue
  Argonne, Illinois  60439
  (630) 252-5444

From since at opendemand.com  Mon Nov 24 12:29:03 2008
From: since at opendemand.com (Stephen Ince)
Date: Mon, 24 Nov 2008 12:29:03 -0500
Subject: rewrite gss_krb5_ccache_name
References: <027201c94c3c$536422f0$6e00a8c0@desktop2>	<200811220145.mAM1j2fX013202@toasties.srv.cs.cmu.edu>	<F48BB6E07FADAF71DD35AED3@atlantis.pc.cs.cmu.edu>	<49279152.9030701@secure-endpoints.com>	<517F56DD1283DFF10635C66F@atlantis.pc.cs.cmu.edu>	<02e501c94cb7$ae8e5760$6e00a8c0@desktop2>	<49282B50.4020903@secure-endpoints.com>	<031501c94cd0$39fc14a0$6e00a8c0@desktop2>	<492ACFD4.8040502@anl.gov><492ADFED.6090507@secure-endpoints.com>
	<492AE1E7.1090708@anl.gov>
Message-ID: <058001c94e5a$26058950$6e00a8c0@desktop2>

Sorry let me clear it up.
1) not_needed_name buffer has a memory leak.
2) NULL has a memory leak.
3) "" has a memory leak.
Actually all three have the same number of bytes leaked.
In case 1 purify complains that the memory is being freed twice.

----- Original Message ----- 
From: "Douglas E. Engert" <deengert at anl.gov>
To: <jaltman at secure-endpoints.com>
Cc: "krbdev" <krbdev at mit.edu>; "Jeffrey Hutzelman" <jhutz at cmu.edu>
Sent: Monday, November 24, 2008 12:18 PM
Subject: Re: rewrite gss_krb5_ccache_name


> 
> 
> Jeffrey Altman wrote:
>> Douglas E. Engert wrote:
>>>
>>> Stephen Ince wrote:
>>>> Thx. Not really possible and has other side effects. We need the
>>>> application needs to run as lean as possible. One thread consumes a
>>>> lot of memory and will have to be around for the life of the program.
>>>> At one point you could have 2000 threads and at another point 10
>>>> threads. We basically simulate browsers and their http connections.
>>>
>>> As a temporary fix, could you do something like:
>>>
>>> char * not_needed_name;
>>> gss_buffer_desc not_needed_buffer;
>>>
>>> not_needed_name = NULL;
>>> major_status =gss_krb5_ccache_name(&minor_status,
>>>                                       krb5_ccache_name,
>>>                                       &not_needed_name);
>>> if (not_needed_name) {
>>>    not_needed_buffer.length = strlen(not_needed_name)+1;
>>>    not_needed_buffer.value = not_needed_name;
>>>    gss_release_buffer(&minor_status, &not_needed_buffer);
>>>    not_needed_name = NULL;
>>> }
>>>
>>> This would then allow you application to get the string
>>> so it can be freeded, but let the gssapi lib use the free()
>>> function linked with the lib.
>> Doug:
>> 
>> That could be done byt why do it when passing NULL instead of
>> &not_needed_name causes gss_krb5_ccache_name() to free the
>> C string instead of returning it?
> 
> I might have miss understood the problem. I though he was saying the
> when he use the NULL there was a leak. But if he passed &not_needed_name
> the library would not leak, and he could then free the string using this
> trick.
> 
>> 
>> Jeffrey Altman
>> 
>> 
>> 
>> ------------------------------------------------------------------------
>> 
>> _______________________________________________
>> krbdev mailing list             krbdev at mit.edu
>> https://mailman.mit.edu/mailman/listinfo/krbdev
> 
> -- 
> 
>  Douglas E. Engert  <DEEngert at anl.gov>
>  Argonne National Laboratory
>  9700 South Cass Avenue
>  Argonne, Illinois  60439
>  (630) 252-5444
> _______________________________________________
> krbdev mailing list             krbdev at mit.edu
> https://mailman.mit.edu/mailman/listinfo/krbdev
>

From hartmans at MIT.EDU  Mon Nov 24 14:28:12 2008
From: hartmans at MIT.EDU (Sam Hartman)
Date: Mon, 24 Nov 2008 14:28:12 -0500
Subject: Review of AEAD Encryption API Project; concluding December 5, 2008
Message-ID: <tsl4p1wc4ab.fsf@mit.edu>

Folks, I'm calling for a review of
http://k5wiki.kerberos.org/wiki/Projects/AEAD_encryption_API                              .

   The Microsoft SSPI provides an interface for in-place encryption of messages (see
      MS-KILE section 3.4.5.4ff). This interface also permits additional data to be included
         in the checksum generated to protect integrity. Such a facility is called authenticated
            encryption with additional data (AEAD). The SSPI works at the GSS-API layer, rather than
               the raw Kerberos layer.

                  This project proposes to extend the raw Kerberos cryptographic API (krb5_c_*) in order
                     to make it possible to implement these SSPI facilities in an extension to the GSS-API.
                        The ultimate consumer of these applications is typically DCE-style RPC, although the
                           facilities could be used by other applications.
                           

From lha at kth.se  Mon Nov 24 14:43:39 2008
From: lha at kth.se (=?iso-8859-1?Q?Love_H=F6rnquist_=C5strand?=)
Date: Mon, 24 Nov 2008 11:43:39 -0800
Subject: Review of AEAD Encryption API Project; concluding December 5, 2008
In-Reply-To: <tsl4p1wc4ab.fsf@mit.edu>
References: <tsl4p1wc4ab.fsf@mit.edu>
Message-ID: <3BFAFA6F-56AF-499D-8D6B-FDD7C09A8CC7@kth.se>

I find this very un-important since what matters is the gss-api  
interface.

Also, changing the API have reprocusions for Heimdal that have the  
same API (in abstract).

Love

24 nov 2008 kl. 20:28 skrev Sam Hartman:

> Folks, I'm calling for a review of
> http://k5wiki.kerberos.org/wiki/Projects/ 
> AEAD_encryption_API                              .
>
>   The Microsoft SSPI provides an interface for in-place encryption  
> of messages (see
>      MS-KILE section 3.4.5.4ff). This interface also permits  
> additional data to be included
>         in the checksum generated to protect integrity. Such a  
> facility is called authenticated
>            encryption with additional data (AEAD). The SSPI works at  
> the GSS-API layer, rather than
>               the raw Kerberos layer.
>
>                  This project proposes to extend the raw Kerberos  
> cryptographic API (krb5_c_*) in order
>                     to make it possible to implement these SSPI  
> facilities in an extension to the GSS-API.
>                        The ultimate consumer of these applications  
> is typically DCE-style RPC, although the
>                           facilities could be used by other  
> applications.
>
> _______________________________________________
> krbdev mailing list             krbdev at mit.edu
> https://mailman.mit.edu/mailman/listinfo/krbdev


From hartmans at MIT.EDU  Mon Nov 24 15:17:32 2008
From: hartmans at MIT.EDU (Sam Hartman)
Date: Mon, 24 Nov 2008 15:17:32 -0500
Subject: Review of AEAD Encryption API Project; concluding December 5, 2008
In-Reply-To: <3BFAFA6F-56AF-499D-8D6B-FDD7C09A8CC7@kth.se> (Love
	=?iso-8859-1?Q?H=F6rnquist=09=C5strand's?= message of "Mon, 24 Nov 2008
	11:43:39 -0800")
References: <tsl4p1wc4ab.fsf@mit.edu>
	<3BFAFA6F-56AF-499D-8D6B-FDD7C09A8CC7@kth.se>
Message-ID: <tslhc5wanfn.fsf@mit.edu>

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

    Love> I find this very un-important since what matters is the
    Love> gss-api interface.

Well, if we're going to have any hope of doing the gss-api interface,
we need a krb5 layer interface for the gss-api library to call.

I split these into two projects because the krb5 layer code reached
stability faster than the gss-layer code.
The gss project has not been sent out for review yet because the write-up is not quite ready.


    Love> Also, changing the API have reprocusions for Heimdal that
    Love> have the same API (in abstract).

I don't understand this comment.

From Nicolas.Williams at sun.com  Mon Nov 24 14:51:10 2008
From: Nicolas.Williams at sun.com (Nicolas Williams)
Date: Mon, 24 Nov 2008 13:51:10 -0600
Subject: Review of AEAD Encryption API Project; concluding December 5, 2008
In-Reply-To: <3BFAFA6F-56AF-499D-8D6B-FDD7C09A8CC7@kth.se>
References: <tsl4p1wc4ab.fsf@mit.edu>
	<3BFAFA6F-56AF-499D-8D6B-FDD7C09A8CC7@kth.se>
Message-ID: <20081124195110.GA17886@Sun.COM>

On Mon, Nov 24, 2008 at 11:43:39AM -0800, Love H?rnquist ?strand wrote:
> I find this very un-important since what matters is the gss-api  
> interface.

I agree that we should start with a GSS-API extension design.  Since
this is for DCE-style stuff, why not start with a set of requirements
for that first, then the GSS-API extensions, finally the krb5 API
extensions?

Otherwise it's hard to tell whether this krb5 API design will meet the
requirements of the GSS-API mechanism.

From hartmans at MIT.EDU  Mon Nov 24 15:39:15 2008
From: hartmans at MIT.EDU (Sam Hartman)
Date: Mon, 24 Nov 2008 15:39:15 -0500
Subject: Review of AEAD Encryption API Project; concluding December 5, 2008
In-Reply-To: <20081124195110.GA17886@Sun.COM> (Nicolas Williams's message of
	"Mon, 24 Nov 2008 13:51:10 -0600")
References: <tsl4p1wc4ab.fsf@mit.edu>
	<3BFAFA6F-56AF-499D-8D6B-FDD7C09A8CC7@kth.se>
	<20081124195110.GA17886@Sun.COM>
Message-ID: <tsl8wr8amfg.fsf@mit.edu>

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

    Nicolas> On Mon, Nov 24, 2008 at 11:43:39AM -0800, Love
    Nicolas> H?rnquist ?strand wrote:
    >> I find this very un-important since what matters is the gss-api
    >> interface.

    Nicolas> I agree that we should start with a GSS-API extension
    Nicolas> design.  Since this is for DCE-style stuff, why not start
    Nicolas> with a set of requirements for that first, then the
    Nicolas> GSS-API extensions, finally the krb5 API extensions?

Because we're doing design after implementation.  Or rather we're
writing up a proposed design after implementation; obviously that can
change based on feedback.


Luke Howard has been writing code on the mskrb-integ branch; Luke and I have been workingthrough some of the issues.

I think we're reasonably certain that this API will work for GSS-API.
This project came forward first because it was ready first; you can
take a look at the GSSAPI project, but it's not really documented
enough to bring forward for review.

From Nicolas.Williams at sun.com  Mon Nov 24 15:26:29 2008
From: Nicolas.Williams at sun.com (Nicolas Williams)
Date: Mon, 24 Nov 2008 14:26:29 -0600
Subject: Review of AEAD Encryption API Project; concluding December 5, 2008
In-Reply-To: <tslhc5wanfn.fsf@mit.edu>
References: <tsl4p1wc4ab.fsf@mit.edu>
	<3BFAFA6F-56AF-499D-8D6B-FDD7C09A8CC7@kth.se>
	<tslhc5wanfn.fsf@mit.edu>
Message-ID: <20081124202629.GD17886@Sun.COM>

On Mon, Nov 24, 2008 at 03:17:32PM -0500, Sam Hartman wrote:
> >>>>> "Love" == Love H?rnquist ?strand <lha at kth.se> writes:
> 
>     Love> I find this very un-important since what matters is the
>     Love> gss-api interface.
> 
> Well, if we're going to have any hope of doing the gss-api interface,
> we need a krb5 layer interface for the gss-api library to call.
> 
> I split these into two projects because the krb5 layer code reached
> stability faster than the gss-layer code.
> The gss project has not been sent out for review yet because the write-up is not quite ready.

Understood, but it will not be possible to complete a review of the krb5
API until the details of the GSS-API in-place crypto extensions are
published.

Nico
-- 

From hartmans at MIT.EDU  Mon Nov 24 16:53:32 2008
From: hartmans at MIT.EDU (Sam Hartman)
Date: Mon, 24 Nov 2008 16:53:32 -0500
Subject: Review of AEAD Encryption API Project; concluding December 5, 2008
In-Reply-To: <20081124202629.GD17886@Sun.COM> (Nicolas Williams's message of
	"Mon, 24 Nov 2008 14:26:29 -0600")
References: <tsl4p1wc4ab.fsf@mit.edu>
	<3BFAFA6F-56AF-499D-8D6B-FDD7C09A8CC7@kth.se>
	<tslhc5wanfn.fsf@mit.edu> <20081124202629.GD17886@Sun.COM>
Message-ID: <tslprkk94f7.fsf@mit.edu>

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

    Nicolas> On Mon, Nov 24, 2008 at 03:17:32PM -0500, Sam Hartman
    Nicolas> wrote:
    >> >>>>> "Love" == Love H?rnquist ?strand <lha at kth.se>
    >> writes:
    >> 
    Love> I find this very un-important since what matters is the
    Love> gss-api interface.
    >>  Well, if we're going to have any hope of doing the gss-api
    >> interface, we need a krb5 layer interface for the gss-api
    >> library to call.
    >> 
    >> I split these into two projects because the krb5 layer code
    >> reached stability faster than the gss-layer code.  The gss
    >> project has not been sent out for review yet because the
    >> write-up is not quite ready.

    Nicolas> Understood, but it will not be possible to complete a
    Nicolas> review of the krb5 API until the details of the GSS-API
    Nicolas> in-place crypto extensions are published.

O, I completely understand.  Much of the information is available in
the Projects/GSSAPI DCE project.  I expect that project will be ready
for review tomorrow once I get the API details there.  Actually,
testing plan may hold us up, but I definitely expect to have a
complete API there tomorrow.


From lha at kth.se  Mon Nov 24 17:56:13 2008
From: lha at kth.se (=?ISO-8859-1?Q?Love_H=F6rnquist_=C5strand?=)
Date: Mon, 24 Nov 2008 14:56:13 -0800
Subject: Review of AEAD Encryption API Project; concluding December 5, 2008
In-Reply-To: <tslhc5wanfn.fsf@mit.edu>
References: <tsl4p1wc4ab.fsf@mit.edu>
	<3BFAFA6F-56AF-499D-8D6B-FDD7C09A8CC7@kth.se>
	<tslhc5wanfn.fsf@mit.edu>
Message-ID: <F697E499-FDFD-48C7-96F9-006A8E4B44C2@kth.se>


> I split these into two projects because the krb5 layer code reached
> stability faster than the gss-layer code.
> The gss project has not been sent out for review yet because the  
> write-up is not quite ready.

But if the gss api needs to change, so does probably the krb5 api ?

>    Love> Also, changing the API have reprocusions for Heimdal that
>    Love> have the same API (in abstract).
>
> I don't understand this comment.

Luke used Heimdal api as a base for this, so if you change the meaning  
of stuff I want to know.

Love




From hartmans at MIT.EDU  Mon Nov 24 18:43:44 2008
From: hartmans at MIT.EDU (Sam Hartman)
Date: Mon, 24 Nov 2008 18:43:44 -0500
Subject: Review of AEAD Encryption API Project; concluding December 5, 2008
In-Reply-To: <F697E499-FDFD-48C7-96F9-006A8E4B44C2@kth.se> (Love
	=?iso-8859-1?Q?H=F6rnquist=09=C5strand's?= message of "Mon, 24 Nov 2008
	14:56:13 -0800")
References: <tsl4p1wc4ab.fsf@mit.edu>
	<3BFAFA6F-56AF-499D-8D6B-FDD7C09A8CC7@kth.se>
	<tslhc5wanfn.fsf@mit.edu>
	<F697E499-FDFD-48C7-96F9-006A8E4B44C2@kth.se>
Message-ID: <tsl7i6s8zbj.fsf@mit.edu>

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

    >> I split these into two projects because the krb5 layer code
    >> reached stability faster than the gss-layer code.  The gss
    >> project has not been sent out for review yet because the
    >> write-up is not quite ready.

    Love> But if the gss api needs to change, so does probably the
    Love> krb5 api ?


I'll get the GSS stuff out tomorrow.  I think we have enough of an
implementation that we believe the krb5 API will not change.
Obviously review comments may cause us to change both.

--Sam


From lukeh at padl.com  Tue Nov 25 06:08:37 2008
From: lukeh at padl.com (Luke Howard)
Date: Tue, 25 Nov 2008 22:08:37 +1100
Subject: Review of AEAD Encryption API Project; concluding December 5, 2008
In-Reply-To: <F697E499-FDFD-48C7-96F9-006A8E4B44C2@kth.se>
References: <tsl4p1wc4ab.fsf@mit.edu>
	<3BFAFA6F-56AF-499D-8D6B-FDD7C09A8CC7@kth.se>
	<tslhc5wanfn.fsf@mit.edu>
	<F697E499-FDFD-48C7-96F9-006A8E4B44C2@kth.se>
Message-ID: <79303913-2862-429D-9E81-63CDC9B6D0AD@padl.com>


On 25/11/2008, at 9:56 AM, Love H?rnquist ?strand wrote:

>
>> I split these into two projects because the krb5 layer code reached
>> stability faster than the gss-layer code.
>> The gss project has not been sent out for review yet because the
>> write-up is not quite ready.
>
> But if the gss api needs to change, so does probably the krb5 api ?

Possibly. The GSS stuff is implemented but untested.

>
>>   Love> Also, changing the API have reprocusions for Heimdal that
>>   Love> have the same API (in abstract).
>>
>> I don't understand this comment.
>
> Luke used Heimdal api as a base for this, so if you change the meaning
> of stuff I want to know.


One difference is that the MIT APIs support KRB5_CRYPTO_TYPE_STREAM on  
calls to krb5_c_decrypt_iov().

The behaviour of this is similar to SSPI: the caller passes in two  
buffers, STREAM and DATA (where STREAM consists of HEADER | DATA |  
PADDING | TRAILER, ie. what krb5_c_encrypt() would return). On  
successful return DATA has a pointer to the decrypted data. (The  
caller can also pass in additional SIGN_ONLY buffers.)

-- Luke

From lukeh at padl.com  Tue Nov 25 06:10:04 2008
From: lukeh at padl.com (Luke Howard)
Date: Tue, 25 Nov 2008 22:10:04 +1100
Subject: Review of AEAD Encryption API Project; concluding December 5, 2008
In-Reply-To: <tslprkk94f7.fsf@mit.edu>
References: <tsl4p1wc4ab.fsf@mit.edu>
	<3BFAFA6F-56AF-499D-8D6B-FDD7C09A8CC7@kth.se>
	<tslhc5wanfn.fsf@mit.edu> <20081124202629.GD17886@Sun.COM>
	<tslprkk94f7.fsf@mit.edu>
Message-ID: <EA47B161-7933-4058-9F4F-A6E73AA80F3C@padl.com>

> O, I completely understand.  Much of the information is available in
> the Projects/GSSAPI DCE project.  I expect that project will be ready
> for review tomorrow once I get the API details there.  Actually,
> testing plan may hold us up, but I definitely expect to have a
> complete API there tomorrow.

Also, I think we were planning to define a more limited  
gss_wrap_aead() API for general purpose use, to be implemented on top  
of gss_wrap_iov() (some semantics of which are needed for DCE  
compatibility).

-- Luke


From hartmans at MIT.EDU  Tue Nov 25 16:00:17 2008
From: hartmans at MIT.EDU (Sam Hartman)
Date: Tue, 25 Nov 2008 16:00:17 -0500
Subject: Review of AEAD Encryption API Project; concluding December 5, 2008
In-Reply-To: <tsl7i6s8zbj.fsf@mit.edu> (Sam Hartman's message of "Mon, 24 Nov
	2008 18:43:44 -0500")
References: <tsl4p1wc4ab.fsf@mit.edu>
	<3BFAFA6F-56AF-499D-8D6B-FDD7C09A8CC7@kth.se>
	<tslhc5wanfn.fsf@mit.edu>
	<F697E499-FDFD-48C7-96F9-006A8E4B44C2@kth.se>
	<tsl7i6s8zbj.fsf@mit.edu>
Message-ID: <tsl4p1v5xni.fsf@mit.edu>

Love, take a look at the Projects/GSSAPI DCE                                                                               page.

I believe it now includes enough of the GSS side API for comments.

From since at opendemand.com  Wed Nov 26 15:53:04 2008
From: since at opendemand.com (Stephen Ince)
Date: Wed, 26 Nov 2008 15:53:04 -0500
Subject: rewrite gss_krb5_ccache_name
References: <027201c94c3c$536422f0$6e00a8c0@desktop2>	<200811220145.mAM1j2fX013202@toasties.srv.cs.cmu.edu><F48BB6E07FADAF71DD35AED3@atlantis.pc.cs.cmu.edu><49279152.9030701@secure-endpoints.com>
	<CA23B028-E87E-493F-BB6F-E9911FAF8690@mit.edu>
Message-ID: <0dad01c95008$fb641350$6e00a8c0@desktop2>

Is there a bug tracking form I can fill out. I do not have the expertise to 
fix this issue in a timely manner but I will gladly test any fix.

Steve
----- Original Message ----- 
From: "Ken Raeburn" <raeburn at mit.edu>
To: <jaltman at secure-endpoints.com>
Cc: "krbdev" <krbdev at mit.edu>; "Jeffrey Hutzelman" <jhutz at cmu.edu>
Sent: Saturday, November 22, 2008 12:08 PM
Subject: Re: rewrite gss_krb5_ccache_name


> On Nov 21, 2008, at 23:57, Jeffrey Altman wrote:
>>>> If that is the case, the real bug here is that the gssapi32.dll
>>>> does not implement a DLL_THREAD_DETACH routine which would free
>>>> any allocated memory stored under the registered TLS keys.
>>>
>>> Well, if you're not doing that, you certainly should...
>>
>> Indeed, this should be fixed.
>
> Looks to me like krb5int_thread_detach_hook should mostly be doing
> that.  It's the handler in the support library, but all our TSD use is
> funneled through some bookkeeping in the support library, to improve
> things on platforms where OS handles (TLS indices, pthread keys) on
> TSD may be a limited resource.  It ought to be deallocating any
> registered per-thread data, though it looks like maybe the bookkeeping
> data itself isn't properly freed.
>
> Ken
> _______________________________________________
> krbdev mailing list             krbdev at mit.edu
> https://mailman.mit.edu/mailman/listinfo/krbdev
> 


From jaltman at secure-endpoints.com  Wed Nov 26 16:44:07 2008
From: jaltman at secure-endpoints.com (Jeffrey Altman)
Date: Wed, 26 Nov 2008 16:44:07 -0500
Subject: rewrite gss_krb5_ccache_name
In-Reply-To: <0dad01c95008$fb641350$6e00a8c0@desktop2>
References: <027201c94c3c$536422f0$6e00a8c0@desktop2>	<200811220145.mAM1j2fX013202@toasties.srv.cs.cmu.edu><F48BB6E07FADAF71DD35AED3@atlantis.pc.cs.cmu.edu><49279152.9030701@secure-endpoints.com>	<CA23B028-E87E-493F-BB6F-E9911FAF8690@mit.edu>
	<0dad01c95008$fb641350$6e00a8c0@desktop2>
Message-ID: <492DC327.9000803@secure-endpoints.com>

Stephen Ince wrote:
> Is there a bug tracking form I can fill out. I do not have the expertise to 
> fix this issue in a timely manner but I will gladly test any fix.

Send e-mail to krb5-bugs at mit.edu

Jeffrey Altman