From tlyu at MIT.EDU Tue Jun 2 11:24:59 2009 From: tlyu at MIT.EDU (Tom Yu) Date: Tue, 02 Jun 2009 11:24:59 -0400 Subject: krb5-1.7 is released Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The MIT Kerberos Team announces the availability of MIT Kerberos 5 Release 1.7. Please see below for a list of some major changes included, or consult the README file in the source tree for a more detailed list of significant changes. RETRIEVING KERBEROS 5 RELEASE 1.7 ================================= You may retrieve the Kerberos 5 Release 1.7 source from the following URL: http://web.mit.edu/kerberos/dist/ The homepage for the krb5-1.7 release is: http://web.mit.edu/kerberos/krb5-1.7/ Further information about Kerberos 5 may be found at the following URL: http://web.mit.edu/kerberos/ and at the MIT Kerberos Consortium web site: http://www.kerberos.org/ DES transition ============== The Data Encryption Standard (DES) is widely recognized as weak. The krb5-1.7 release will contain measures to encourage sites to migrate away from using single-DES cryptosystems. Among these is a configuration variable that enables "weak" enctypes, but will default to "false" in the future. Additional migration aids are planned for future releases. Major changes in 1.7 ==================== The krb5-1.7 release contains a large number of changes, featuring improvements in the following broad areas: * Compatibility with Microsoft Windows * Administrator experience * User experience * Code quality * Protocol evolution Compatibility with Microsoft Windows: * Follow client principal referrals in the client library when obtaining initial tickets. * KDC can issue realm referrals for service principals based on domain names. * Extensions supporting DCE RPC, including three-leg GSS context setup and unencapsulated GSS tokens inside SPNEGO. * Microsoft GSS_WrapEX, implemented using the gss_iov API, which is similar to the equivalent SSPI functionality. This is needed to support some instances of DCE RPC. * NTLM recognition support in GSS-API, to facilitate dropping in an NTLM implementation for improved compatibility with older releases of Microsoft Windows. * KDC support for principal aliases, if the back end supports them. Currently, only the LDAP back end supports aliases. * Support Microsoft set/change password (RFC 3244) protocol in kadmind. * Implement client and KDC support for GSS_C_DELEG_POLICY_FLAG, which allows a GSS application to request credential delegation only if permitted by KDC policy. Administrator experience: * Install header files for the administration API, allowing third-party software to manipulate the KDC database. * Incremental propagation support for the KDC database. * Master key rollover support, making it easier to change master key passwords or encryption types. * New libdefaults configuration variable "allow_weak_crypto". NOTE: Currently defaults to "true", but may default to "false" in a future release. Setting this variable to "false" will have the effect of removing weak enctypes (currently defined to be all single-DES enctypes) from permitted_enctypes, default_tkt_enctypes, and default_tgs_enctypes. User experience: * Provide enhanced GSS-API error message including supplementary details about error conditions. * In the replay cache, use a hash over the complete ciphertext to avoid false-positive replay indications. Code quality: * Replace many uses of "unsafe" string functions. While most of these instances were innocuous, they impeded efficient automatic and manual static code analysis. * Fix many instances of resource leaks and similar bugs identified by static analysis tools. * Fix CVE-2009-0844, CVE-2009-0845, CVE-2009-0846, CVE-2009-0847 -- various vulnerabilities in SPNEGO and ASN.1 code. Protocol evolution: * Remove support for version 4 of the Kerberos protocol (krb4). * Encryption algorithm negotiation (RFC 4537), allowing clients and application services to negotiate stronger encryption than their KDC supports. * Flexible Authentication Secure Tunneling (FAST), a preauthentiation framework that can protect the AS exchange from dictionary attacks on weak user passwords. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (SunOS) iEYEARECAAYFAkolRFIACgkQSO8fWy4vZo51VwCg2KSwpAhTACsyFSNES1YBdf+P K9YAnj1UfrA/n/mv2Ejl+813aZcjluPT =YKGy -----END PGP SIGNATURE----- _______________________________________________ kerberos-announce mailing list kerberos-announce at mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos-announce From ghudson at MIT.EDU Wed Jun 3 12:24:12 2009 From: ghudson at MIT.EDU (ghudson@MIT.EDU) Date: Wed, 3 Jun 2009 12:24:12 -0400 (EDT) Subject: appl/{bsd,ftp,telnet} unbundling plan Message-ID: <200906031624.n53GOC7q002224@outgoing.mit.edu> With the release of 1.7 out the door, the window reopens to look into structural changes to the trunk. One of our long-standing wishlist items has been the unbundling of appl/bsd, appl/ftp, and appl/telnet, for several reasons which I won't reiterate. Russ Allbery has volunteered to put a minimal amount of time into maintaining appl/bsd. Ken Hornstein has indicated an interest in telnet and FTP, although I'm not sure how much of a time commitment. Both already have MIT accounts and thus can be given access to our infrastructure. It doesn't appear that anyone is interested in putting in the time to be a primary maintainer of any of the three pieces of code (e.g. adding new features, improving its portability by using PAM instead of login.krb5, etc.). My sense is that we (MIT) are willing to put in some one-time effort to get the code out of our main tree, but are not interested in raising our long-term commitment level to it beyond "the minimum necessary". Here is what I would like to do: 1. I will get a krb5-appl Subversion repository created using the same infrastructure used for the krb5 repository, with the same access list as the krb5 repository. 2. I will do the work to import the appl/{bsd,ftp,telnet} trunk version control history into krb5-appl (this is pretty easy with svndumpfilter). 3. I will do the work to make the build system for appl/{bsd,ftp,telnet} standalone and create basic documentation for building and installing them. 4. We already have a krb5-appl queue in RT, although I'm not sure all appl bug reports are in there. I will leave any desired cleanup in that department to Tom. 5. I will package up a 1.0 release to be hosted at . 6. The expectation is that further releases will happen on an as-needed basis only (which may mean years between releases) and will have 1.0.x version numbers. We are, of course, open to other people moving the applications forward in more meaningful ways as long as it doesn't increase our periodic resource commitment, but we currently don't expect that to happen based on the feedback received to date. 7. If I have completed up through step 5 before we are ramping up for 1.8, we will remove src/appl/{bsd,ftp,telnet} from the trunk and they will not be part of the 1.8 release. If I am sidetracked and have not completed the work by then, then we will continue on as we are and this will get raised again in another 1-3 years as usual. Comments appreciated. Previous threads on this issue, for reference: http://mailman.mit.edu/pipermail/krbdev/2002-July/000518.html http://mailman.mit.edu/pipermail/krbdev/2002-July/000538.html http://mailman.mit.edu/pipermail/krbdev/2005-July/003538.html http://mailman.mit.edu/pipermail/krbdev/2006-August/004889.html http://mailman.mit.edu/pipermail/krbdev/2007-November/006331.html http://mailman.mit.edu/pipermail/krbdev/2008-September/006895.html From rra at stanford.edu Wed Jun 3 12:39:58 2009 From: rra at stanford.edu (Russ Allbery) Date: Wed, 03 Jun 2009 09:39:58 -0700 Subject: appl/{bsd,ftp,telnet} unbundling plan In-Reply-To: <200906031624.n53GOC7q002224@outgoing.mit.edu> (ghudson@mit.edu's message of "Wed\, 3 Jun 2009 12\:24\:12 -0400 \(EDT\)") References: <200906031624.n53GOC7q002224@outgoing.mit.edu> Message-ID: <87iqjd9spt.fsf@windlord.stanford.edu> ghudson at MIT.EDU writes: > Russ Allbery has volunteered to put a minimal amount of time into > maintaining appl/bsd. Ken Hornstein has indicated an interest in > telnet and FTP, although I'm not sure how much of a time commitment. > Both already have MIT accounts and thus can be given access to our > infrastructure. It doesn't appear that anyone is interested in > putting in the time to be a primary maintainer of any of the three > pieces of code (e.g. adding new features, improving its portability by > using PAM instead of login.krb5, etc.). My sense is that we (MIT) are > willing to put in some one-time effort to get the code out of our main > tree, but are not interested in raising our long-term commitment level > to it beyond "the minimum necessary". I may be able to find some time to work on the PAM support, or find a different solution to that problem at least for Kerberos rlogin and rsh. The plan sounds good to me. -- Russ Allbery (rra at stanford.edu) From hartmans at MIT.EDU Wed Jun 3 13:46:04 2009 From: hartmans at MIT.EDU (Sam Hartman) Date: Wed, 03 Jun 2009 13:46:04 -0400 Subject: appl/{bsd,ftp,telnet} unbundling plan In-Reply-To: <87iqjd9spt.fsf@windlord.stanford.edu> (Russ Allbery's message of "Wed\, 03 Jun 2009 09\:39\:58 -0700") References: <200906031624.n53GOC7q002224@outgoing.mit.edu> <87iqjd9spt.fsf@windlord.stanford.edu> Message-ID: I suspect that Russ and I will end up maintaining these for Debian and so I'll probably end up spending some cycles on this, but again my hope is to minimize my commitment. You probably need to eject the pty library along with appl/*. Currently appl/* depends on k5-int.h. You will presumably need to deal with that somehow. I assume that the dejagnu tests will require that 1) you've run make install in a krb5-appl release into your prefix and 2) that's built in such a way that setting LD_LIBRARY_PATH will cause the kerberos libs out of the tree to be used? --Sam From mike.patnode at centrify.com Wed Jun 3 13:48:06 2009 From: mike.patnode at centrify.com (Mike Patnode) Date: Wed, 3 Jun 2009 10:48:06 -0700 Subject: appl/{bsd,ftp,telnet} unbundling plan In-Reply-To: <87iqjd9spt.fsf@windlord.stanford.edu> References: <200906031624.n53GOC7q002224@outgoing.mit.edu> <87iqjd9spt.fsf@windlord.stanford.edu> Message-ID: We have both a PAM & LAM implementation we'd be willing to submit. We're just finishing the 1.7 integration now and from there just need to find time to submit the changes back. mp -----Original Message----- From: krbdev-bounces at mit.edu [mailto:krbdev-bounces at mit.edu] On Behalf Of Russ Allbery Sent: Wednesday, June 03, 2009 9:40 AM To: krbdev at mit.edu Subject: Re: appl/{bsd,ftp,telnet} unbundling plan ghudson at MIT.EDU writes: > Russ Allbery has volunteered to put a minimal amount of time into > maintaining appl/bsd. Ken Hornstein has indicated an interest in > telnet and FTP, although I'm not sure how much of a time commitment. > Both already have MIT accounts and thus can be given access to our > infrastructure. It doesn't appear that anyone is interested in > putting in the time to be a primary maintainer of any of the three > pieces of code (e.g. adding new features, improving its portability by > using PAM instead of login.krb5, etc.). My sense is that we (MIT) are > willing to put in some one-time effort to get the code out of our main > tree, but are not interested in raising our long-term commitment level > to it beyond "the minimum necessary". I may be able to find some time to work on the PAM support, or find a different solution to that problem at least for Kerberos rlogin and rsh. The plan sounds good to me. -- Russ Allbery (rra at stanford.edu) _______________________________________________ krbdev mailing list krbdev at mit.edu https://mailman.mit.edu/mailman/listinfo/krbdev From rra at stanford.edu Wed Jun 3 13:57:07 2009 From: rra at stanford.edu (Russ Allbery) Date: Wed, 03 Jun 2009 10:57:07 -0700 Subject: appl/{bsd,ftp,telnet} unbundling plan In-Reply-To: (Mike Patnode's message of "Wed\, 3 Jun 2009 10\:48\:06 -0700") References: <200906031624.n53GOC7q002224@outgoing.mit.edu> <87iqjd9spt.fsf@windlord.stanford.edu> Message-ID: <87ab4p9p58.fsf@windlord.stanford.edu> "Mike Patnode" writes: > We have both a PAM & LAM implementation we'd be willing to submit. > We're just finishing the 1.7 integration now and from there just need to > find time to submit the changes back. Red Hat likewise has a PAM implementation that's filed in RT. We'll need to figure out how to merge the features of both. -- Russ Allbery (rra at stanford.edu) From ghudson at MIT.EDU Wed Jun 3 14:25:28 2009 From: ghudson at MIT.EDU (Greg Hudson) Date: Wed, 03 Jun 2009 14:25:28 -0400 Subject: appl/{bsd,ftp,telnet} unbundling plan In-Reply-To: References: <200906031624.n53GOC7q002224@outgoing.mit.edu> <87iqjd9spt.fsf@windlord.stanford.edu> Message-ID: <1244053528.20017.31.camel@ray> On Wed, 2009-06-03 at 13:46 -0400, Sam Hartman wrote: > Currently appl/* depends on k5-int.h. You will presumably need to > deal with that somehow. In general, my plan is to duplicate and strip down k5-platform.h, and include k5-platform.h and krb5.h instead of k5-int.h. There are some other entanglements to deal with: * krb5_read_message, krb5_write_message, and krb5_net_read are used in various places and are not part of the API. Simplest (though perhaps not best) is to make them part of the API. * krcp uses krb5_set_config_files in some compatibility code; not sure what that's about. * login.c dereferences the context to get the profile instead of using krb5_get_profile. * kcmd.c uses data_eq_string. > I assume that the dejagnu tests will require that > 1) you've run make install in a krb5-appl release into your prefix > and > 2) that's built in such a way that setting LD_LIBRARY_PATH will cause the kerberos libs out of the tree to be used? Ideally I'd like to migrate the application tests to krb5-appl. I assume that would result in some amount of decreased code coverage from the test suite, but I'm not sure how much. Requiring a crazy build of krb5-appl to productively run the krb5 test suite would not be a good end state. If this turns into too much of a blocker, I will just decide that "expand the code coverage of the krb5 test suite independent of the application tests" is a prerequisite for unbundling the applications, which probably means pushing off unbundingling until after 1.8. From kenh at cmf.nrl.navy.mil Wed Jun 3 14:27:51 2009 From: kenh at cmf.nrl.navy.mil (Ken Hornstein) Date: Wed, 03 Jun 2009 14:27:51 -0400 Subject: appl/{bsd,ftp,telnet} unbundling plan In-Reply-To: <200906031624.n53GOC7q002224@outgoing.mit.edu> Message-ID: <200906031827.n53IRpaW010514@hedwig.cmf.nrl.navy.mil> >Russ Allbery has volunteered to put a minimal amount of time into >maintaining appl/bsd. Ken Hornstein has indicated an interest in >telnet and FTP, although I'm not sure how much of a time commitment. Sadly, I don't think I have any free time to work on this. But I suspect others in the DoD HPC program would be interested in doing this. I'll contact them and let them know about this (if they don't know already). --Ken From epeisach at MIT.EDU Wed Jun 3 14:32:54 2009 From: epeisach at MIT.EDU (Ezra Peisach) Date: Wed, 03 Jun 2009 14:32:54 -0400 Subject: appl/{bsd,ftp,telnet} unbundling plan In-Reply-To: References: <200906031624.n53GOC7q002224@outgoing.mit.edu> <87iqjd9spt.fsf@windlord.stanford.edu> Message-ID: <4A26C1D6.2020504@mit.edu> It might be useful to leave gss-sample, sample, simple as they test basic functionality, they are not installed, and dejagnu currently uses them... I do not believe that dejagnu tests need to have krb5-appl installed... Instead krb5-appl should have their own test suite... If there is a bug in krb5-appl - it should not hold up a release... Ezra Sam Hartman wrote: > I suspect that Russ and I will end up maintaining these for Debian and > so I'll probably end up spending some cycles on this, but again my > hope is to minimize my commitment. > > You probably need to eject the pty library along with appl/*. > > Currently appl/* depends on k5-int.h. You will presumably need to > deal with that somehow. > > I assume that the dejagnu tests will require that > 1) you've run make install in a krb5-appl release into your prefix > and > 2) that's built in such a way that setting LD_LIBRARY_PATH will cause the kerberos libs out of the tree to be used? > > --Sam > _______________________________________________ > krbdev mailing list krbdev at mit.edu > https://mailman.mit.edu/mailman/listinfo/krbdev > From raeburn at MIT.EDU Wed Jun 3 17:10:54 2009 From: raeburn at MIT.EDU (Ken Raeburn) Date: Wed, 3 Jun 2009 17:10:54 -0400 Subject: appl/{bsd,ftp,telnet} unbundling plan In-Reply-To: <1244053528.20017.31.camel@ray> References: <200906031624.n53GOC7q002224@outgoing.mit.edu> <87iqjd9spt.fsf@windlord.stanford.edu> <1244053528.20017.31.camel@ray> Message-ID: <39E9F13D-91CF-4CA3-A513-C4337B0901F0@mit.edu> On Jun 3, 2009, at 14:25, Greg Hudson wrote: > On Wed, 2009-06-03 at 13:46 -0400, Sam Hartman wrote: >> Currently appl/* depends on k5-int.h. You will presumably need to >> deal with that somehow. > > In general, my plan is to duplicate and strip down k5-platform.h, and > include k5-platform.h and krb5.h instead of k5-int.h. There are some > other entanglements to deal with: > > * krb5_read_message, krb5_write_message, and krb5_net_read are used > in > various places and are not part of the API. Simplest (though perhaps > not best) is to make them part of the API. I *think* it's on the bug list already, but any APIs taking socket handles (file descriptors, on UNIX) should not assume they're integers, if we want them to work on Windows. > Requiring a crazy build of krb5-appl to productively run the krb5 test > suite would not be a good end state. If this turns into too much of a > blocker, I will just decide that "expand the code coverage of the krb5 > test suite independent of the application tests" is a prerequisite for > unbundling the applications, which probably means pushing off > unbundingling until after 1.8. Sounds like a good plan. -- Ken Raeburn / raeburn at mit.edu / no longer at MIT Kerberos Consortium From ghudson at MIT.EDU Thu Jun 4 13:35:52 2009 From: ghudson at MIT.EDU (ghudson@MIT.EDU) Date: Thu, 4 Jun 2009 13:35:52 -0400 (EDT) Subject: Code quality news Message-ID: <200906041735.n54HZqKa025960@outgoing.mit.edu> With the krb5 1.7 release out, we have the opportunity to spend a little time on general code quality before getting back into the press of new features and new release-critical bugs. Here is some stuff we've been thinking about in meetings and/or working on: 1. Stylistic consistency We have a reasonably complete set of coding guidelines at http://k5wiki.kerberos.org/wiki/Coding_style, but the conformance of our existing code to those standards is not great. Because stylistic code modifications create barriers to automatic merges, it's wise to condense such modifications into small numbers of events. We have been talking about doing a "great reindent" some time in the near future to eliminate tabs, remove trailing whitespace, and possibly regularize some other aspects of formatting (function definition headers come to mind). Taking this measure shortly after a release will make it harder to automatically backport changes to the 1.7 branch, but is less likely to get in the way of feature work taking place afterwards. 2. Splitting up big source files Some of the specialized applications of krb5 involve subsets of the libraries--a well-known example is the kernel krb5 code necessary to support the NFS client and server. Although it's hard to structure the source code to handle every possible subset, it's generally easier to build subsets out of smaller pieces. So, in the near future, perhaps just after the great reindent, we might move code around to minimize undesirable combinations of functions in the same library source file. Some principles which might apply are: * Code for different instances of a framework should not live in the same file. (Example: we shouldn't have all of our client preauth mechanisms living together in preauth.c and preauth2.c.) * Helper functions used by several different API functions should not live in the same source file as one of the API functions. * Code used only by clients, application servers, or the KDC should not be mixed with code used by other categories. 3. Smaller functions We have not made a cultural practice of using helper functions to cut down on the size of complicated operations; as a result, we have a lot of functions which are slightly beyond the ability of most programmers to comprehend all at once, and a few monsters which are off the chart (like krb5_get_cred_from_kdc_opt after referrals support). Although it's too much work to do it all in one fell swoop, we would ideally like to refactor these into smaller component pieces. For new changes, please favor the use of helper functions over embedding too much logic into an already large function. r22272 (ok-as-delegate stripping) is an example: the question "is this TGT for a local realm" was farmed out to a helper function, while the core logic of stripping the ok-as-delegate flag was kept in krb5_get_cred_via_tkt where it could be expressed clearly with a minimum of clauses. 4. Function documentation We are thinking about adding doxygen markup before every function in our libraries, starting with placeholders. This is a departure from a previous plan to add doxygen markup to our header files. Non-API functions would be marked as such using the @internal special command. There are a few goals here: * Allow the generation of API documentation (suppressing internal function documentation) while still using the same mechanism to document internal and external library functions. * Encourage developers modifying a function to document it if it is not already documented. * As a specialized use, make it easier to automatically find functions within library source files. It is not clear if this will turn out to be a good goal because there are other ways to do it (such as looking for left braces at the beginnings of lines) and because we may want to use Doxygen markup to document data structures as well as functions. 5. Test suite quality We have a pretty big test suite, but it has some notable gaps in coverage; examples include no testing of preauth (including PKINIT) and no testing of the LDAP back end. We have some unit tests written in C with a very loose set of conventions, and some functional tests written using dejagnu. I am a bit dissatisfied with the dejagnu part of the test suite, particularly in the difficulty of going from a test failure to an analysis of the failing code path. Recently we've added some tests using Python (although I don't think they're integrated into make check), and we may do more of that in the future. We don't have any specific plans for creating a strong framework for unit and functional tests, but this is a recognized problem area. We also don't have a good way of computing the code coverage of our test suite. In the past couple of days I've experimented with gcov, which seems really cool but doesn't support shared libraries. It would be "a simple matter of programming" to do code coverage with valgrind, but it doesn't look like the programming has been done in a suitable form yet. One option here is to bring back static linking support in the build system, and modify the plugin layers to allow static linking of plugin back ends instead of dynamic loading. Then a testing could be done in a fashion more compatible with instrumentation tools. In the long run, I would also like to make more of the krb5 code base unit-testable, because it's often cumbersome or impossible to get good branch coverage with functional tests. Right now you can't unit-test any code which talks to the network; I'm thinking of adding some testing hooks which would allow that. 6. Static analysis We've recently renewed our license for Coverity Prevent. I've been focusing on defects found in libkrb5 over the past few months, and the number there has declined from an initial 232 to 12 (all of which are believed to be pretty harmless). Of course, we have other important libraries like gssapi and crypto, but I'm still pleased with the progress on that front. From raeburn at MIT.EDU Fri Jun 5 02:19:05 2009 From: raeburn at MIT.EDU (Ken Raeburn) Date: Fri, 5 Jun 2009 02:19:05 -0400 Subject: Code quality news In-Reply-To: <200906041735.n54HZqKa025960@outgoing.mit.edu> References: <200906041735.n54HZqKa025960@outgoing.mit.edu> Message-ID: <47720A71-95A0-41BE-9FC3-5C6E8655205E@mit.edu> On Jun 4, 2009, at 13:35, ghudson at MIT.EDU wrote: > With the krb5 1.7 release out, we have the opportunity to spend a > little time on general code quality before getting back into the press > of new features and new release-critical bugs. Here is some stuff > we've been thinking about in meetings and/or working on: Overall this looks very good! > 2. Splitting up big source files I think this is good to a point. I don't really subscribe to the "one function per file" methodology that was so important in the days of static-only linking, expensive disks, and every admin having to compile and install Kerberos himself if he wanted the three or four existing Kerberos applications; now shared libraries are the norm, the linker can't selectively discard functions not in use by one particular application, and unless the functionalities are really distinct it's often helpful to see multiple functions together instead of in separate files. As long as you're not taking it to an extreme, yes, splitting up source files with not-terribly-closely-related functionality is probably a good thing. If it is closely related, I'd keep them together. I also think it can be reasonable to use preprocessor directives for some subsetting. Not in all cases, but maybe if you want a subset of very closely related functions. (E.g., for cases like ccaches or keytabs where we use function-pointer tables, I'd probably keep the individual implementations collected together in one file each, and use #ifdef to eliminate certain operations not needed in a certain subset. That is, unless you want to factor out some common code or algorithms used in multiple of these implementations as separate helper functions.) I think I'd like to see k5-int.h broken up a lot. Having one or two headers where you can get all the widely-used internal stuff is probably good, but it can include sub-headers with different types of functionality, and it can omit things that really could be localized to one directory or so. The installed krb5.h, eh, maybe... it might encourage some developers to include only and unless you take steps to make doing so difficult, and then you can never get rid of those headers if you want to reorganize again. The glibc folks have done it well, I think -- if you try to include the wrong header directly, certain cpp symbols don't get defined and it yells at you and your code doesn't compile. > Some of the specialized applications of krb5 involve subsets of the > libraries--a well-known example is the kernel krb5 code necessary to > support the NFS client and server. Although it's hard to structure > the source code to handle every possible subset, it's generally easier > to build subsets out of smaller pieces. True, though a "piece" could be a function instead of a file. > * Helper functions used by several different API functions should > not live in the same source file as one of the API functions. If the API functions have similar functionality, I think it makes sense to put them (and the support functions) all together in one file. Unless you're going for the smallest-static-link goal. Subsetting by selecting certain files makes this trickier when you only want some of these API functions; but I think all of the solutions are kind of ugly in that case. (I'm picturing something like get_creds here -- big "helper" functions with all the functionality, maybe broken into manageable pieces, wrapped with little API functions presenting nicer interfaces for the common use cases. If the helper functions are common to various unrelated API functions, or the API functions involve a lot of non-common code, yeah, make them separate instead of treating them like they're closely tied to one use and not another.) > 3. Smaller functions I don't mind big functions for one big integrated piece of functionality with non-trivial logic, but that's usually not what we've got. Breaking the bigger functions up into logically separate helpers would improve things a lot! > 4. Function documentation > > We are thinking about adding doxygen markup before every function in > our libraries, starting with placeholders. This is a departure from a > previous plan to add doxygen markup to our header files. Non-API > functions would be marked as such using the @internal special command. I'm a little concerned about this. Does doxygen let you specify "this part of the documentation for this function is internal"? I could imagine some of the internal documentation including notes about details of the current implementation, and wanting to make such notes about functions that are exported, but not wanting to make them part of the API contract that application programmers will expect us to adhere to going forward. Such notes shouldn't show up in the official API documentation. -- Ken Raeburn / raeburn at mit.edu / no longer at MIT Kerberos Consortium From ghudson at MIT.EDU Fri Jun 5 11:39:35 2009 From: ghudson at MIT.EDU (Greg Hudson) Date: Fri, 05 Jun 2009 11:39:35 -0400 Subject: Code quality news In-Reply-To: <47720A71-95A0-41BE-9FC3-5C6E8655205E@mit.edu> References: <200906041735.n54HZqKa025960@outgoing.mit.edu> <47720A71-95A0-41BE-9FC3-5C6E8655205E@mit.edu> Message-ID: <1244216375.20017.37.camel@ray> On Fri, 2009-06-05 at 02:19 -0400, Ken Raeburn wrote: > I'm a little concerned about this. Does doxygen let you specify "this > part of the documentation for this function is internal"? No, and Sam raised a similar point elsewhere, but my view is that implementation documentation doesn't belong in the front of the function in the first place; it belongs in regular comments inside the function body. It remains to be seen how well that can be enforced. Sam observed that putting the doxygen markup in the krb5.hin makes it more natural to document only the API contract. I still favor putting doxygen markup in the implementation (for the reasons I gave before), but it's a valid concern. From hartmans at MIT.EDU Fri Jun 5 11:50:38 2009 From: hartmans at MIT.EDU (Sam Hartman) Date: Fri, 05 Jun 2009 11:50:38 -0400 Subject: Code quality news In-Reply-To: <1244216375.20017.37.camel@ray> (Greg Hudson's message of "Fri\, 05 Jun 2009 11\:39\:35 -0400") References: <200906041735.n54HZqKa025960@outgoing.mit.edu> <47720A71-95A0-41BE-9FC3-5C6E8655205E@mit.edu> <1244216375.20017.37.camel@ray> Message-ID: >>>>> "Greg" == Greg Hudson writes: Greg> It remains to be seen how well that can be enforced. Sam Greg> observed that putting the doxygen markup in the krb5.hin Greg> makes it more natural to document only the API contract. I Greg> still favor putting doxygen markup in the implementation Greg> (for the reasons I gave before), but it's a valid concern. You confirmed that we can easily build API docs excluding all references to the internal functions? Also, what will the default be? I think it would be bad if a bunch of functions started showing up in api docs with empty documentation because the @internal marker was absent. From ghudson at MIT.EDU Fri Jun 5 12:07:57 2009 From: ghudson at MIT.EDU (Greg Hudson) Date: Fri, 05 Jun 2009 12:07:57 -0400 Subject: Code quality news In-Reply-To: References: <200906041735.n54HZqKa025960@outgoing.mit.edu> <47720A71-95A0-41BE-9FC3-5C6E8655205E@mit.edu> <1244216375.20017.37.camel@ray> Message-ID: <1244218077.20017.39.camel@ray> On Fri, 2009-06-05 at 11:50 -0400, Sam Hartman wrote: > You confirmed that we can easily build API docs excluding all > references to the internal functions? http://www.stack.nl/~dimitri/doxygen/config.html#cfg_internal_docs > Also, what will the default be? I think it would be bad if a bunch of > functions started showing up in api docs with empty documentation > because the @internal marker was absent. It would be better for us if Doxygen had something like @api instead of @internal, but I think this concern is marginal. From hartmans at MIT.EDU Fri Jun 5 12:12:26 2009 From: hartmans at MIT.EDU (Sam Hartman) Date: Fri, 05 Jun 2009 12:12:26 -0400 Subject: Code quality news In-Reply-To: <1244218077.20017.39.camel@ray> (Greg Hudson's message of "Fri\, 05 Jun 2009 12\:07\:57 -0400") References: <200906041735.n54HZqKa025960@outgoing.mit.edu> <47720A71-95A0-41BE-9FC3-5C6E8655205E@mit.edu> <1244216375.20017.37.camel@ray> <1244218077.20017.39.camel@ray> Message-ID: >>>>> "Greg" == Greg Hudson writes: Greg> It would be better for us if Doxygen had something like @api Greg> instead of @internal, but I think this concern is marginal. I do not. Most of the doxygen documented projects I've run across expose a lot more internals in their docs than I think would be appropriate for Kerberos. I'm concerned that the style decisions you're making are a significant contributor to that. From hartmans at MIT.EDU Fri Jun 5 12:25:19 2009 From: hartmans at MIT.EDU (Sam Hartman) Date: Fri, 05 Jun 2009 12:25:19 -0400 Subject: Code quality news In-Reply-To: (Sam Hartman's message of "Fri\, 05 Jun 2009 11\:50\:38 -0400") References: <200906041735.n54HZqKa025960@outgoing.mit.edu> <47720A71-95A0-41BE-9FC3-5C6E8655205E@mit.edu> <1244216375.20017.37.camel@ray> Message-ID: To clarify, while I'm concerned I'm willing to compromise on adding markup and @internal tags to things at the beginning. I do think that the @internal tags are essential when the initial markup is added. That said, I'm definitely uncomfortable with this approach. --Sam From Nicolas.Williams at sun.com Fri Jun 5 12:17:15 2009 From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Fri, 5 Jun 2009 11:17:15 -0500 Subject: Code quality news In-Reply-To: <47720A71-95A0-41BE-9FC3-5C6E8655205E@mit.edu> References: <200906041735.n54HZqKa025960@outgoing.mit.edu> <47720A71-95A0-41BE-9FC3-5C6E8655205E@mit.edu> Message-ID: <20090605161715.GW1049@Sun.COM> On Fri, Jun 05, 2009 at 02:19:05AM -0400, Ken Raeburn wrote: > On Jun 4, 2009, at 13:35, ghudson at MIT.EDU wrote: > > With the krb5 1.7 release out, we have the opportunity to spend a > > little time on general code quality before getting back into the press > > of new features and new release-critical bugs. Here is some stuff > > we've been thinking about in meetings and/or working on: > > Overall this looks very good! Agreed. > > 2. Splitting up big source files > > I think this is good to a point. [...] > > I also think it can be reasonable to use preprocessor directives for > some subsetting. [...] Certainly. > > Some of the specialized applications of krb5 involve subsets of the > > libraries--a well-known example is the kernel krb5 code necessary to > > support the NFS client and server. Although it's hard to structure > > the source code to handle every possible subset, it's generally easier > > to build subsets out of smaller pieces. > > True, though a "piece" could be a function instead of a file. We've managed this at the file level. Using #ifdefs to achieve the same effect would be fine too, I think. Nico -- From tsitkova at MIT.EDU Wed Jun 10 11:09:31 2009 From: tsitkova at MIT.EDU (Zhanna Tsitkova) Date: Wed, 10 Jun 2009 11:09:31 -0400 Subject: Crypto lib Message-ID: <12BBDEDE-D4E9-4F41-9472-FDB89EAFCC92@mit.edu> Hello! This msg is a proposal for the crypto directory modification. It is the fact that many of MIT KRB consumers are replacing our crypto library with their own implementations. To simplify this transition we propose the following: 1. Divide crypto library into two directories: - "krb" - Kerberos specific functionality. Provides front-end into crypto routines. Files: checksum, dk, aead, enc_provider, hash_provider, keyhash_provider, nfold, key ops, etype ops, prf, raw, crc32, old - "commom-mit" - MIT implementations. Provides back-end of the crypto routines. Files: md*, des*, aes, hmac,prng, yarrow,sha1, pbkdf2 2. Add a new directory "common-openssl" to hold OpenSSL crypto implementation. It is our understanding that many vendors either are using OSSL directly, or having their native libs "ported" to OSSL, i.e. fed OSSL API's with own cryptography. Simplifies FIPS approval as OSSL is FIPS certified. 3. Potentially we can accept additional adaptations of krb crypto lib ("common-bsafe" ?). 4. Build process will be controlled on the configure level Thanks, Zhanna From hartmans at MIT.EDU Wed Jun 10 11:46:58 2009 From: hartmans at MIT.EDU (Sam Hartman) Date: Wed, 10 Jun 2009 11:46:58 -0400 Subject: Crypto lib In-Reply-To: <12BBDEDE-D4E9-4F41-9472-FDB89EAFCC92@mit.edu> (Zhanna Tsitkova's message of "Wed\, 10 Jun 2009 11\:09\:31 -0400") References: <12BBDEDE-D4E9-4F41-9472-FDB89EAFCC92@mit.edu> Message-ID: First, I'm assuming that you are starting a discussion here and that you plan to write up a project proposal and send this through the approval process. I'm not sure that yarrow should be over the fense. How strong of a cryptographic PRNG are people likely to have available in their libs? The last time I looked at openssl (a long time ago) it's PRNG was kind of minimalist. Why OpenSSL? I would have thought that NSS would be more attractive to your consumers. I'm reasonably sure that's true for me with my Debian hat on. I would have guessed that would be true for your other major consumers I can think of. Can we get people who plan to use OpenSSL with this to step forward? From tsitkova at MIT.EDU Wed Jun 10 12:12:35 2009 From: tsitkova at MIT.EDU (Zhanna Tsitkova) Date: Wed, 10 Jun 2009 12:12:35 -0400 Subject: Crypto lib In-Reply-To: References: <12BBDEDE-D4E9-4F41-9472-FDB89EAFCC92@mit.edu> Message-ID: <6B50C8F1-7704-4E4E-BE57-EF679144EE86@mit.edu> On Jun 10, 2009, at 11:46 AM, Sam Hartman wrote: > First, I'm assuming that you are starting a discussion here and that > you plan to write up a project proposal and send this through the > approval process. > > > I'm not sure that yarrow should be over the fense. How strong of a > cryptographic PRNG are people likely to have available in their libs? > The last time I looked at openssl (a long time ago) it's PRNG was > kind of minimalist. it was thought as a rand generator placeholder. > > > Why OpenSSL? I would have thought that NSS would be more attractive > to your consumers. I'm reasonably sure that's true for me with my > Debian hat on. This is a whole idea. One can consider "common-nss" as an additional implementation. > I would have guessed that would be true for your other > major consumers I can think of. Can we get people who plan to use > OpenSSL with this to step forward? From hartmans at MIT.EDU Wed Jun 10 12:34:18 2009 From: hartmans at MIT.EDU (Sam Hartman) Date: Wed, 10 Jun 2009 12:34:18 -0400 Subject: Crypto lib In-Reply-To: <6B50C8F1-7704-4E4E-BE57-EF679144EE86@mit.edu> (Zhanna Tsitkova's message of "Wed\, 10 Jun 2009 12\:12\:35 -0400") References: <12BBDEDE-D4E9-4F41-9472-FDB89EAFCC92@mit.edu> <6B50C8F1-7704-4E4E-BE57-EF679144EE86@mit.edu> Message-ID: To make it clear, I certainly don't object to their being an openssl implementation, and obviously you can spend your money developing whatever makes sense. I'd just make sure people are going to use the openssl implementation before spending money on it. --Sam From ghudson at MIT.EDU Wed Jun 10 12:40:31 2009 From: ghudson at MIT.EDU (Greg Hudson) Date: Wed, 10 Jun 2009 12:40:31 -0400 Subject: Crypto lib In-Reply-To: <12BBDEDE-D4E9-4F41-9472-FDB89EAFCC92@mit.edu> References: <12BBDEDE-D4E9-4F41-9472-FDB89EAFCC92@mit.edu> Message-ID: <1244652031.20017.66.camel@ray> A discussion of directory naming (a topic which I know is more interesting to me than many other people): The names "common-mit", "common-openssl", and "krb" came from me, and I'm not fond of any of them; I've been trying to think of better ones. A little more background on the distinction we're trying to draw: libk5crypto contains three basic kinds of stuff: 1. Generic, externally defined crypto algorithms like AES 2. Kerberos-specific algorithms like CF2 3. Kerberos-specific bookkeeping routines defining the API (enctypes etc.) The idea is to make category 1 pluggable at compile time, recognizing that any particular back end (OpenSSL, NSS, BSafe, PKCS11) may only provide a subset of the algorithms. So "krb" is my dummy name to hold the Kerberos-specific stuff (category 2 and 3) and "common-mit" and "common-openssl" are my dummy names for the direct implementations of (1) and the indirect implementations via OpenSSL. I don't like the prefix "common" because it is often used to mean "common across all architectures" (or across all something else), and what it means here is something else. I don't like the name "common-mit" in particular because it suggests that MIT is the original author of the code contained therein, which is not true in some (most?) cases. I don't like the name "krb" on principal (the name of the project is usually meaningless as a subdirectory name within that project) but it's the most reasonable. After a few more minutes of thought, I tentatively like the names "generic-direct", "generic-openssl", and "krb" better than the set of names I initially picked. The idea, incidentally, is for the build to descend into all subdirectories, and inside each subdirectory to pick which objects to build based on configure-time options. For example, a build with the OpenSSL back end would build all objects inside generic-openssl, and some of the objects inside generic-direct corresponding to the algorithms not implemented by OpenSSL. (I'm aware that Sam thinks that NSS is a better initial back end than OpenSSL. I continued using OpenSSL in my discussion above for the sake of example, but that doesn't mean I have any particular opinion on that issue.) From ghudson at MIT.EDU Wed Jun 10 15:26:21 2009 From: ghudson at MIT.EDU (ghudson@MIT.EDU) Date: Wed, 10 Jun 2009 15:26:21 -0400 (EDT) Subject: Test suite code coverage loss with removal of application tests Message-ID: <200906101926.n5AJQLIL027931@outgoing.mit.edu> If the application tests are removed from the suite, the following functions drop to 0% coverage or drop below 50% coverage: cvtaddr 38% -> 0% decrypt_credencdata 80% -> 0% encrypt_credencpart 47% -> 0% extend_file_to 70% -> 30% krb5_auth_con_genaddrs 76% -> 0% krb5_auth_con_getkey 60% -> 0% krb5_fwd_tgt_creds 51% -> 0% krb5_get_cred_via_tkt 63% -> 45% krb5_get_credentials_core 72% -> 47% krb5_init_secure_context 100% -> 0% krb5_kuserok 22% -> 0% krb5_mk_1cred 88% -> 0% krb5_mk_ncred 51% -> 0% krb5_mk_ncred_basic 78% -> 0% krb5_rd_cred 54% -> 0% krb5_rd_cred_basic 75% -> 0% krb5_rd_req_decrypt_tkt_part 90% -> 86% krb5_recvauth_version 100% -> 0% krb5_verify_checksum 80% -> 0% recvauth_common 51% -> 49% To a first approximation, we need standalone tests for ticket forwarding and kuserok. I will work on those before proceeding with the unbundling plan, and also improve my comparisons a bit to see where there is serious damage that doesn't happen to cross the 50% or 0% thresholds. I used gcov to do these measurements. I'll add some notes to the debugging tips section of the wiki about how to use gcov on the krb5 tree. From hartmans at MIT.EDU Wed Jun 10 15:59:09 2009 From: hartmans at MIT.EDU (Sam Hartman) Date: Wed, 10 Jun 2009 15:59:09 -0400 Subject: Test suite code coverage loss with removal of application tests In-Reply-To: <200906101926.n5AJQLIL027931@outgoing.mit.edu> (ghudson@mit.edu's message of "Wed\, 10 Jun 2009 15\:26\:21 -0400 \(EDT\)") References: <200906101926.n5AJQLIL027931@outgoing.mit.edu> Message-ID: Greg, adding stand-alone ticket forwarding may be as simple as using the -d (delegate) option to gss-client tests if we're going to keep that. From hartmans at MIT.EDU Wed Jun 10 16:01:47 2009 From: hartmans at MIT.EDU (Sam Hartman) Date: Wed, 10 Jun 2009 16:01:47 -0400 Subject: Crypto lib In-Reply-To: <1244652031.20017.66.camel@ray> (Greg Hudson's message of "Wed\, 10 Jun 2009 12\:40\:31 -0400") References: <12BBDEDE-D4E9-4F41-9472-FDB89EAFCC92@mit.edu> <1244652031.20017.66.camel@ray> Message-ID: How about backend-direct or backend-openssl or direct and glue-openssl or impl-direct and impl-openssl. From ssorce at redhat.com Thu Jun 11 09:17:30 2009 From: ssorce at redhat.com (Simo Sorce) Date: Thu, 11 Jun 2009 09:17:30 -0400 Subject: Crypto lib In-Reply-To: References: <12BBDEDE-D4E9-4F41-9472-FDB89EAFCC92@mit.edu> <1244652031.20017.66.camel@ray> Message-ID: <1244726250.25513.26.camel@localhost.localdomain> On Wed, 2009-06-10 at 16:01 -0400, Sam Hartman wrote: > How about backend-direct or backend-openssl > or direct and glue-openssl > or impl-direct and impl-openssl. if this is about crypto, why not: crypto (generic stuff) |-custom (custom crypto) |-nss (nss crypto) \-openssl (openssl crypto) Simo. -- Simo Sorce * Red Hat, Inc * New York From tlyu at MIT.EDU Thu Jun 11 10:34:16 2009 From: tlyu at MIT.EDU (Tom Yu) Date: Thu, 11 Jun 2009 10:34:16 -0400 Subject: Crypto lib In-Reply-To: <1244726250.25513.26.camel@localhost.localdomain> (Simo Sorce's message of "Thu, 11 Jun 2009 09:17:30 -0400") References: <12BBDEDE-D4E9-4F41-9472-FDB89EAFCC92@mit.edu> <1244652031.20017.66.camel@ray> <1244726250.25513.26.camel@localhost.localdomain> Message-ID: I think it would be best to use some name including "builtin" for direct implementations of crypto primitives such as block ciphers, hash functions, etc. From ghudson at MIT.EDU Thu Jun 11 12:37:04 2009 From: ghudson at MIT.EDU (Greg Hudson) Date: Thu, 11 Jun 2009 12:37:04 -0400 Subject: Crypto lib In-Reply-To: References: <12BBDEDE-D4E9-4F41-9472-FDB89EAFCC92@mit.edu> <1244652031.20017.66.camel@ray> <1244726250.25513.26.camel@localhost.localdomain> Message-ID: <1244738224.20590.22.camel@ray> I like Sam's idea of omitting the prefix ("generic" or "common" or whatever) if there's no good word for it, and Tom's idea of using "builtin" to refer to the direct implementations. So, my current layout preference is for: lib/crypto/krb -- Kerberos-specific algorithms and API glue lib/crypto/builtin -- Direct back-end implementations lib/crypto/openssl -- Back-end implementations using OpenSSL lib/crypto/nss -- Back-end implementations using NSS lib/crpyto/bsafe -- Back-end implementations using BSafe etc. (Back ends chosen for the sake of example; not trying to say which back-end implementations we should do.) It occurs to me that we don't have to descend into every directory in every build; lib/crypto/Makefile.in can descend into krb, builtin, and at most one of the backend-specific directories. builtin/Makefile.in would need all the complexity of knowing what direct implementations to build based on which back end is in use, but openssl/Makefile.in and nss/Makefile.in and bsafe/Makefile.in could just build everything, under the assumption that the directory will only be used if that back end was selected at configure time. On Thu, 2009-06-11 at 10:34 -0400, Tom Yu wrote: > I think it would be best to use some name including "builtin" for > direct implementations of crypto primitives such as block ciphers, > hash functions, etc. > _______________________________________________ > krbdev mailing list krbdev at mit.edu > https://mailman.mit.edu/mailman/listinfo/krbdev From ghudson at MIT.EDU Thu Jun 18 00:48:28 2009 From: ghudson at MIT.EDU (ghudson@MIT.EDU) Date: Thu, 18 Jun 2009 00:48:28 -0400 (EDT) Subject: /dev/random vs. /dev/urandom and the krb5 test suite Message-ID: <200906180448.n5I4mScF026930@outgoing.mit.edu> The krb5 test suite generates a lot of random keying material. Under the assumption that cryptographic keys require "strong" randomness, most of that material comes from /dev/random. This can create stalls in some environments; for instance, my Linux box spends a few extra minutes per testing run if I don't use a local hack to make lib/crypto use /dev/urandom instead. Some other developers have run into this recently as well, so we may do something about it. An obvious choice is to add a context flag and krb5.conf setting to always use /dev/urandom in favor of /dev/random. My question is whether to put big red flashing lights around the option name or not. It's possible that some high-load production environments are seeing /dev/random stalls as well, although I have no particular reason to believe this is so. If we use a relatively innocuous name, people might legitimately find the option useful for such cases--or people might set it out of ignorance when it's not needed and could cause harm. If the system PRNG is weak, or if it has been seeded with very little true random data (say, 64 bits or less), then using /dev/urandom would be disastrous for a system's security. However, both cases are a bit far-fetched today in my opinion. What I'd like input on is whether there are practical risks in the expected cases of using /dev/urandom for keys. For example, say you generate a hundred 128-bit keys with your system's /dev/urandom when there are 600 bits of true randomness in your system's pool, instead of using 12800 bits of "true" randomness from /dev/random as one might like. An attacker can compromise all 12800 bits of keying material with a 2^600 workload, at least in theory, but this is not a very interesting attack, especially since one of those 128-bit keys is probably of higher value (like your TGS long-term key) and would be more interesting to break in isolation. Are there other attacks of interest in this scenario? Sorry if this is a little long-winded; I'm just trying to choose between a judgemental name like "insecure_random" or something more bland like "always_use_urandom" for the override. The default will certainly remain the way it is. From dodavis at redhat.com Thu Jun 18 08:37:04 2009 From: dodavis at redhat.com (Don Davis) Date: Thu, 18 Jun 2009 08:37:04 -0400 Subject: /dev/random vs. /dev/urandom and the krb5 test suite In-Reply-To: <200906180448.n5I4mScF026930@outgoing.mit.edu> References: <200906180448.n5I4mScF026930@outgoing.mit.edu> Message-ID: <4A3A34F0.1070703@redhat.com> hi, greg -- have you tried just adding entropy to the pool during your tests, so that /dev/random won't stall? running "find / -name foo" on a spare disk ought to suffice for this. - don davis, red hat On 06/18/2009 12:48 AM, ghudson at MIT.EDU wrote: > The krb5 test suite generates a lot of random keying material. Under > the assumption that cryptographic keys require "strong" randomness, > most of that material comes from /dev/random. This can create stalls > in some environments; for instance, my Linux box spends a few extra > minutes per testing run if I don't use a local hack to make lib/crypto > use /dev/urandom instead. > > Some other developers have run into this recently as well, so we may > do something about it. An obvious choice is to add a context flag and > krb5.conf setting to always use /dev/urandom in favor of /dev/random. > > My question is whether to put big red flashing lights around the > option name or not. It's possible that some high-load production > environments are seeing /dev/random stalls as well, although I have no > particular reason to believe this is so. If we use a relatively > innocuous name, people might legitimately find the option useful for > such cases--or people might set it out of ignorance when it's not > needed and could cause harm. > > If the system PRNG is weak, or if it has been seeded with very little > true random data (say, 64 bits or less), then using /dev/urandom would > be disastrous for a system's security. However, both cases are a bit > far-fetched today in my opinion. What I'd like input on is whether > there are practical risks in the expected cases of using /dev/urandom > for keys. For example, say you generate a hundred 128-bit keys with > your system's /dev/urandom when there are 600 bits of true randomness > in your system's pool, instead of using 12800 bits of "true" > randomness from /dev/random as one might like. An attacker can > compromise all 12800 bits of keying material with a 2^600 workload, at > least in theory, but this is not a very interesting attack, especially > since one of those 128-bit keys is probably of higher value (like your > TGS long-term key) and would be more interesting to break in > isolation. Are there other attacks of interest in this scenario? > > Sorry if this is a little long-winded; I'm just trying to choose > between a judgemental name like "insecure_random" or something more > bland like "always_use_urandom" for the override. The default will > certainly remain the way it is. > _______________________________________________ > krbdev mailing list krbdev at mit.edu > https://mailman.mit.edu/mailman/listinfo/krbdev > From jhutz at cmu.edu Thu Jun 18 11:55:55 2009 From: jhutz at cmu.edu (Jeffrey Hutzelman) Date: Thu, 18 Jun 2009 11:55:55 -0400 Subject: /dev/random vs. /dev/urandom and the krb5 test suite In-Reply-To: <20577_1245328682_n5ICc1Ec002450_4A3A34F0.1070703@redhat.com> References: <200906180448.n5I4mScF026930@outgoing.mit.edu> <20577_1245328682_n5ICc1Ec002450_4A3A34F0.1070703@redhat.com> Message-ID: <57CAFA9A996923606122F88C@MINBAR.FAC.CS.CMU.EDU> --On Thursday, June 18, 2009 08:37:04 AM -0400 Don Davis wrote: > hi, greg -- > > have you tried just adding entropy to the pool > during your tests, so that /dev/random won't stall? > running "find / -name foo" on a spare disk ought to > suffice for this. Or it might cause all sorts of problems as the machine grinds to a halt trying to traverse all of /afs. A trick like that might be appropriate for one individual working around a problem, but it's not something that the tests can safely do automatically, and the tests should Just Work(tm), so that anyone building Kerberos can run the tests and not have to know special tricks to get them working. Greg, I'm not sure where I stand on making it easy for people to configure Kerberos to use /dev/urandom. In a lot of cases, /dev/urandom is going to be "good enough", since while it doesn't directly derive every bit of output from an independent random physical event, it is supposed to at least be the output of a cryptographically-strong PRNG. IMHO /dev/random tends to get overused just a little. If you don't want to create too tempting a knob, you could call the option something like debug_test_random_data_source and set it to a path. This would have the added benefit of allowing one to provide a fixed, reproducible set of "random" data if needed for tests or debugging. -- Jeff From hartmans at MIT.EDU Thu Jun 18 14:21:10 2009 From: hartmans at MIT.EDU (Sam Hartman) Date: Thu, 18 Jun 2009 14:21:10 -0400 Subject: /dev/random vs. /dev/urandom and the krb5 test suite In-Reply-To: <200906180448.n5I4mScF026930@outgoing.mit.edu> (ghudson@mit.edu's message of "Thu\, 18 Jun 2009 00\:48\:28 -0400 \(EDT\)") References: <200906180448.n5I4mScF026930@outgoing.mit.edu> Message-ID: So, during normal operation I would not expect Kerberos to use /dev/random much. I'd expect it to get used at * kadmind startup * kdb5_util usage * possibly (but probably not) krb5kdc The idea is that long-term cryptographic keys such as TGT keys and service keys should use /dev/random to initialize the PRNG. I would not expect the KDC or clients to use /dev/random during normal operation nor would I expect startup of KDC and kadmind to use non-constant data from /dev/random. So, if you do create a krb5.conf option, I think having big warning flags would be entirely appropriate. I don't think you should ever need that option in a production environment. From tlyu at MIT.EDU Thu Jun 18 14:35:52 2009 From: tlyu at MIT.EDU (Tom Yu) Date: Thu, 18 Jun 2009 14:35:52 -0400 Subject: /dev/random vs. /dev/urandom and the krb5 test suite In-Reply-To: (Sam Hartman's message of "Thu, 18 Jun 2009 14:21:10 -0400") References: <200906180448.n5I4mScF026930@outgoing.mit.edu> Message-ID: Sam Hartman writes: > So, during normal operation I would not expect Kerberos to use > /dev/random much. > I'd expect it to get used at > > * kadmind startup > * kdb5_util usage > * possibly (but probably not) krb5kdc By inspection, only these files contain calls to krb5_c_random_os_entropy with the "strong" argument set to 1: kadmin/dbutil/kdb5_create.c kadmin/server/ovsec_kadmd.c > The idea is that long-term cryptographic keys such as TGT keys and > service keys should use /dev/random to initialize the PRNG. I would > not expect the KDC or clients to use /dev/random during normal > operation nor would I expect startup of KDC and kadmind to use > non-constant data from /dev/random. > > So, if you do create a krb5.conf option, I think having big warning > flags would be entirely appropriate. I don't think you should ever > need that option in a production environment. I agree. From ssorce at redhat.com Thu Jun 18 14:38:35 2009 From: ssorce at redhat.com (Simo Sorce) Date: Thu, 18 Jun 2009 14:38:35 -0400 Subject: /dev/random vs. /dev/urandom and the krb5 test suite In-Reply-To: References: <200906180448.n5I4mScF026930@outgoing.mit.edu> Message-ID: <1245350315.14254.136.camel@localhost.localdomain> On Thu, 2009-06-18 at 14:21 -0400, Sam Hartman wrote: > So, during normal operation I would not expect Kerberos to use > /dev/random much. > I'd expect it to get used at > > * kadmind startup > * kdb5_util usage > * possibly (but probably not) krb5kdc > > The idea is that long-term cryptographic keys such as TGT keys and > service keys should use /dev/random to initialize the PRNG. I would > not expect the KDC or clients to use /dev/random during normal > operation nor would I expect startup of KDC and kadmind to use > non-constant data from /dev/random. > > So, if you do create a krb5.conf option, I think having big warning > flags would be entirely appropriate. I don't think you should ever > need that option in a production environment. Wouldn't it make more sense to have an environment variable used only during tests ? Simo. -- Simo Sorce * Red Hat, Inc * New York From tsitkova at MIT.EDU Thu Jun 18 14:40:41 2009 From: tsitkova at MIT.EDU (Zhanna Tsitkova) Date: Thu, 18 Jun 2009 14:40:41 -0400 Subject: Crypto Modularity proj proposal Message-ID: <6DAAB910-3AA0-485C-942A-7193B5DF67CB@mit.edu> FYI A new project proposal is posted on http://k5wiki.kerberos.org/wiki/Projects/Crypto_modularity to address Crypto Modularity of MIT Kerberos code. From hartmans at MIT.EDU Thu Jun 18 14:43:42 2009 From: hartmans at MIT.EDU (Sam Hartman) Date: Thu, 18 Jun 2009 14:43:42 -0400 Subject: /dev/random vs. /dev/urandom and the krb5 test suite In-Reply-To: (Tom Yu's message of "Thu\, 18 Jun 2009 14\:35\:52 -0400") References: <200906180448.n5I4mScF026930@outgoing.mit.edu> Message-ID: I wonder whether LD_PRELOAD remapping /dev/random to /dev/urandom would be a better solution here. From hartmans at MIT.EDU Thu Jun 18 14:45:52 2009 From: hartmans at MIT.EDU (Sam Hartman) Date: Thu, 18 Jun 2009 14:45:52 -0400 Subject: /dev/random vs. /dev/urandom and the krb5 test suite In-Reply-To: <1245350315.14254.136.camel@localhost.localdomain> (Simo Sorce's message of "Thu\, 18 Jun 2009 14\:38\:35 -0400") References: <200906180448.n5I4mScF026930@outgoing.mit.edu> <1245350315.14254.136.camel@localhost.localdomain> Message-ID: >>>>> "Simo" == Simo Sorce writes: Simo> Wouldn't it make more sense to have an environment variable Simo> used only during tests ? I'm much more comfortable with the implications of introducing a config file options than environment variables. Environment variables tend to get set by things like telnet, ssh, etc and have a checkered security history. From ssorce at redhat.com Thu Jun 18 15:03:08 2009 From: ssorce at redhat.com (Simo Sorce) Date: Thu, 18 Jun 2009 15:03:08 -0400 Subject: /dev/random vs. /dev/urandom and the krb5 test suite In-Reply-To: References: <200906180448.n5I4mScF026930@outgoing.mit.edu> <1245350315.14254.136.camel@localhost.localdomain> Message-ID: <1245351788.14254.141.camel@localhost.localdomain> On Thu, 2009-06-18 at 14:45 -0400, Sam Hartman wrote: > >>>>> "Simo" == Simo Sorce writes: > Simo> Wouldn't it make more sense to have an environment variable > Simo> used only during tests ? > > I'm much more comfortable with the implications of introducing a > config file options than environment variables. Environment variables > tend to get set by things like telnet, ssh, etc and have a checkered > security history. Sorry I thought this applied only to krb5kdc/kadmind, not to libraries/user tools. Your concerns make sense to me, although, if you environment is poisoned I think you have more pressing problems to care about :) Simo. -- Simo Sorce * Red Hat, Inc * New York From tlyu at MIT.EDU Thu Jun 18 15:21:09 2009 From: tlyu at MIT.EDU (Tom Yu) Date: Thu, 18 Jun 2009 15:21:09 -0400 Subject: /dev/random vs. /dev/urandom and the krb5 test suite In-Reply-To: <1245351788.14254.141.camel@localhost.localdomain> (Simo Sorce's message of "Thu, 18 Jun 2009 15:03:08 -0400") References: <200906180448.n5I4mScF026930@outgoing.mit.edu> <1245350315.14254.136.camel@localhost.localdomain> <1245351788.14254.141.camel@localhost.localdomain> Message-ID: Simo Sorce writes: > On Thu, 2009-06-18 at 14:45 -0400, Sam Hartman wrote: >> >>>>> "Simo" == Simo Sorce writes: >> Simo> Wouldn't it make more sense to have an environment variable >> Simo> used only during tests ? >> >> I'm much more comfortable with the implications of introducing a >> config file options than environment variables. Environment variables >> tend to get set by things like telnet, ssh, etc and have a checkered >> security history. > > Sorry I thought this applied only to krb5kdc/kadmind, not to > libraries/user tools. > Your concerns make sense to me, although, if you environment is poisoned > I think you have more pressing problems to care about :) I'm leaning toward checking an environment variable inside these two programs. * Environment variables tend to have a checkered security history, like Sam says. * Checking an environment variable is far easier to implement. * If we implement by checking an environment variable in these two programs to determine whether to read strong random numbers, it localizes the risk to an administrator running the command while having a specific environment variable set. IMHO, administrators should take care to keep their environment clean, especially while performing security-critical operations. From hartmans at MIT.EDU Thu Jun 18 15:27:33 2009 From: hartmans at MIT.EDU (Sam Hartman) Date: Thu, 18 Jun 2009 15:27:33 -0400 Subject: /dev/random vs. /dev/urandom and the krb5 test suite In-Reply-To: (Tom Yu's message of "Thu\, 18 Jun 2009 15\:21\:09 -0400") References: <200906180448.n5I4mScF026930@outgoing.mit.edu> <1245350315.14254.136.camel@localhost.localdomain> <1245351788.14254.141.camel@localhost.localdomain> Message-ID: I'm fine with checking an environment variable in a program instead of the library. From rra at stanford.edu Thu Jun 18 15:33:37 2009 From: rra at stanford.edu (Russ Allbery) Date: Thu, 18 Jun 2009 12:33:37 -0700 Subject: /dev/random vs. /dev/urandom and the krb5 test suite In-Reply-To: (Tom Yu's message of "Thu\, 18 Jun 2009 15\:21\:09 -0400") References: <200906180448.n5I4mScF026930@outgoing.mit.edu> <1245350315.14254.136.camel@localhost.localdomain> <1245351788.14254.141.camel@localhost.localdomain> Message-ID: <877hz9jq0e.fsf@windlord.stanford.edu> Tom Yu writes: > I'm leaning toward checking an environment variable inside these two > programs. > > * Environment variables tend to have a checkered security history, > like Sam says. > > * Checking an environment variable is far easier to implement. If checking an environment variable is far easier to implement than adding a configuration option to an existing configuration file, I think that indicates there's something seriously wrong with your configuration management API. This should not be the case. > * If we implement by checking an environment variable in these two > programs to determine whether to read strong random numbers, it > localizes the risk to an administrator running the command while > having a specific environment variable set. IMHO, administrators > should take care to keep their environment clean, especially while > performing security-critical operations. Given all the problems that MIT Kerberos has had with causing security bugs in other packages due to the handling of KRB5_CONFIG, I think this is a bad decision and a bad set of assumptions. It's easier than it might look for a person's environment variables to leak. It's rather plausible, for example, for someone to set such an environment variable for testing, forget about it, su and do an aptitude upgrade, and end up restarting inetd with that environment variable set, at which point it can then get inherited by other login sessions. -- Russ Allbery (rra at stanford.edu) From ssorce at redhat.com Thu Jun 18 15:57:12 2009 From: ssorce at redhat.com (Simo Sorce) Date: Thu, 18 Jun 2009 15:57:12 -0400 Subject: /dev/random vs. /dev/urandom and the krb5 test suite In-Reply-To: <877hz9jq0e.fsf@windlord.stanford.edu> References: <200906180448.n5I4mScF026930@outgoing.mit.edu> <1245350315.14254.136.camel@localhost.localdomain> <1245351788.14254.141.camel@localhost.localdomain> <877hz9jq0e.fsf@windlord.stanford.edu> Message-ID: <1245355032.14254.147.camel@localhost.localdomain> On Thu, 2009-06-18 at 12:33 -0700, Russ Allbery wrote: > Given all the problems that MIT Kerberos has had with causing security > bugs in other packages due to the handling of KRB5_CONFIG, I think this > is a bad decision and a bad set of assumptions. It's easier than it > might look for a person's environment variables to leak. It's rather > plausible, for example, for someone to set such an environment variable > for testing, forget about it, su and do an aptitude upgrade, and end up > restarting inetd with that environment variable set, at which point it > can then get inherited by other login sessions. Russ, I think that if you set a test environment variable as root and on a production KDC machine, and then go on a perform maintenance task from the same shell, then there is something very wrong in your procedures. The env variable would probably be set just by scripts that run the tests (it would not inherit as you don't set it in your shell) in any normal case, and will avoid creating special krb5.conf files or to change the system config file where the option may persist for a long time across reboots and restarts. Just my 2c, Simo. -- Simo Sorce * Red Hat, Inc * New York From rra at stanford.edu Thu Jun 18 16:17:03 2009 From: rra at stanford.edu (Russ Allbery) Date: Thu, 18 Jun 2009 13:17:03 -0700 Subject: /dev/random vs. /dev/urandom and the krb5 test suite In-Reply-To: <1245355032.14254.147.camel@localhost.localdomain> (Simo Sorce's message of "Thu\, 18 Jun 2009 15\:57\:12 -0400") References: <200906180448.n5I4mScF026930@outgoing.mit.edu> <1245350315.14254.136.camel@localhost.localdomain> <1245351788.14254.141.camel@localhost.localdomain> <877hz9jq0e.fsf@windlord.stanford.edu> <1245355032.14254.147.camel@localhost.localdomain> Message-ID: <87skhxi9fk.fsf@windlord.stanford.edu> Simo Sorce writes: > On Thu, 2009-06-18 at 12:33 -0700, Russ Allbery wrote: >> Given all the problems that MIT Kerberos has had with causing >> security bugs in other packages due to the handling of KRB5_CONFIG, I >> think this is a bad decision and a bad set of assumptions. It's >> easier than it might look for a person's environment variables to >> leak. It's rather plausible, for example, for someone to set such an >> environment variable for testing, forget about it, su and do an >> aptitude upgrade, and end up restarting inetd with that environment >> variable set, at which point it can then get inherited by other login >> sessions. > Russ, I think that if you set a test environment variable as root and > on a production KDC machine, and then go on a perform maintenance task > from the same shell, then there is something very wrong in your > procedures. I agree. But security is about defense in depth. MIT Kerberos has been very bad at providing robustness around environment variables in the past. Many people have been burned by this. Having environment variables change features of code is widely considered to be a horrible interface decision for anything affecting security due to the way environment variables spread promiscuously. It's roundly ridiculed in security fora. I would really hate to see MIT Kerberos add yet another place where magic environment variables change the code behavior. > The env variable would probably be set just by scripts that run the > tests (it would not inherit as you don't set it in your shell) in any > normal case, and will avoid creating special krb5.conf files or to > change the system config file where the option may persist for a long > time across reboots and restarts. For the test suite purpose, it shouldn't make any difference whether you use an environment variable or a configuration option, since the test suite presumably uses its own configuration files. Not adding an environment variable means one fewer potential landmine affecting people who *aren't* running the test suite. -- Russ Allbery (rra at stanford.edu) From jhutz at cmu.edu Thu Jun 18 17:59:05 2009 From: jhutz at cmu.edu (Jeffrey Hutzelman) Date: Thu, 18 Jun 2009 17:59:05 -0400 Subject: /dev/random vs. /dev/urandom and the krb5 test suite In-Reply-To: <9900_1245356245_n5IKHOnU023840_87skhxi9fk.fsf@windlord.stanford.edu> References: <200906180448.n5I4mScF026930@outgoing.mit.edu> <1245350315.14254.136.camel@localhost.localdomain> <1245351788.14254.141.camel@localhost.localdomain> <877hz9jq0e.fsf@windlord.stanford.edu> <1245355032.14254.147.camel@localhost.localdomain> <9900_1245356245_n5IKHOnU023840_87skhxi9fk.fsf@windlord.stanford.edu> Message-ID: --On Thursday, June 18, 2009 01:17:03 PM -0700 Russ Allbery wrote: > MIT Kerberos has been very bad at providing robustness around > environment variables in the past. Many people have been burned by > this. Having environment variables change features of code is widely > considered to be a horrible interface decision for anything affecting > security due to the way environment variables spread promiscuously. > It's roundly ridiculed in security fora. I would really hate to see MIT > Kerberos add yet another place where magic environment variables change > the code behavior. I fully agree with Russ here. Keep away from environment variables for this. -- Jeff From epeisach at MIT.EDU Thu Jun 18 18:07:15 2009 From: epeisach at MIT.EDU (Ezra Peisach) Date: Thu, 18 Jun 2009 18:07:15 -0400 Subject: /dev/random vs. /dev/urandom and the krb5 test suite In-Reply-To: <87skhxi9fk.fsf@windlord.stanford.edu> References: <200906180448.n5I4mScF026930@outgoing.mit.edu> <1245350315.14254.136.camel@localhost.localdomain> <1245351788.14254.141.camel@localhost.localdomain> <877hz9jq0e.fsf@windlord.stanford.edu> <1245355032.14254.147.camel@localhost.localdomain> <87skhxi9fk.fsf@windlord.stanford.edu> Message-ID: <4A3ABA93.4030007@mit.edu> Russ Allbery wrote: > Simo Sorce writes: > >> On Thu, 2009-06-18 at 12:33 -0700, Russ Allbery wrote: >> > > >>> Given all the problems that MIT Kerberos has had with causing >>> security bugs in other packages due to the handling of KRB5_CONFIG, I >>> think this is a bad decision and a bad set of assumptions. It's >>> easier than it might look for a person's environment variables to >>> leak. It's rather plausible, for example, for someone to set such an >>> environment variable for testing, forget about it, su and do an >>> aptitude upgrade, and end up restarting inetd with that environment >>> variable set, at which point it can then get inherited by other login >>> sessions. >>> > > >> Russ, I think that if you set a test environment variable as root and >> on a production KDC machine, and then go on a perform maintenance task >> from the same shell, then there is something very wrong in your >> procedures. >> > > I agree. But security is about defense in depth. > > MIT Kerberos has been very bad at providing robustness around > environment variables in the past. Many people have been burned by > this. Having environment variables change features of code is widely > considered to be a horrible interface decision for anything affecting > security due to the way environment variables spread promiscuously. > It's roundly ridiculed in security fora. I would really hate to see MIT > Kerberos add yet another place where magic environment variables change > the code behavior. > > >> The env variable would probably be set just by scripts that run the >> tests (it would not inherit as you don't set it in your shell) in any >> normal case, and will avoid creating special krb5.conf files or to >> change the system config file where the option may persist for a long >> time across reboots and restarts. >> > > For the test suite purpose, it shouldn't make any difference whether you > use an environment variable or a configuration option, since the test > suite presumably uses its own configuration files. Not adding an > environment variable means one fewer potential landmine affecting people > who *aren't* running the test suite. > > Instead of an environment variable - how about a command line option... No ambiguity there, no fear of strange environment variables.... Then you simply need to document it... If an admin starts the program w/ such a feature - they deserve what they get... Also - you can then syslog in big letters - the fact that they enabled this... Ezra From rra at stanford.edu Thu Jun 18 18:27:54 2009 From: rra at stanford.edu (Russ Allbery) Date: Thu, 18 Jun 2009 15:27:54 -0700 Subject: /dev/random vs. /dev/urandom and the krb5 test suite In-Reply-To: <4A3ABA93.4030007@mit.edu> (Ezra Peisach's message of "Thu\, 18 Jun 2009 18\:07\:15 -0400") References: <200906180448.n5I4mScF026930@outgoing.mit.edu> <1245350315.14254.136.camel@localhost.localdomain> <1245351788.14254.141.camel@localhost.localdomain> <877hz9jq0e.fsf@windlord.stanford.edu> <1245355032.14254.147.camel@localhost.localdomain> <87skhxi9fk.fsf@windlord.stanford.edu> <4A3ABA93.4030007@mit.edu> Message-ID: <877hz9b2j9.fsf@windlord.stanford.edu> Ezra Peisach writes: > Instead of an environment variable - how about a command line > option... No ambiguity there, no fear of strange environment > variables.... Then you simply need to document it... If an admin > starts the program w/ such a feature - they deserve what they > get... Also - you can then syslog in big letters - the fact that they > enabled this... That sounds great to me. -- Russ Allbery (rra at stanford.edu) From ssorce at redhat.com Thu Jun 18 18:40:00 2009 From: ssorce at redhat.com (Simo Sorce) Date: Thu, 18 Jun 2009 18:40:00 -0400 Subject: /dev/random vs. /dev/urandom and the krb5 test suite In-Reply-To: <877hz9b2j9.fsf@windlord.stanford.edu> References: <200906180448.n5I4mScF026930@outgoing.mit.edu> <1245350315.14254.136.camel@localhost.localdomain> <1245351788.14254.141.camel@localhost.localdomain> <877hz9jq0e.fsf@windlord.stanford.edu> <1245355032.14254.147.camel@localhost.localdomain> <87skhxi9fk.fsf@windlord.stanford.edu> <4A3ABA93.4030007@mit.edu> <877hz9b2j9.fsf@windlord.stanford.edu> Message-ID: <1245364800.14254.151.camel@localhost.localdomain> On Thu, 2009-06-18 at 15:27 -0700, Russ Allbery wrote: > Ezra Peisach writes: > > > Instead of an environment variable - how about a command line > > option... No ambiguity there, no fear of strange environment > > variables.... Then you simply need to document it... If an admin > > starts the program w/ such a feature - they deserve what they > > get... Also - you can then syslog in big letters - the fact that they > > enabled this... > > That sounds great to me. Looks like the best option :-) Simo. -- Simo Sorce * Red Hat, Inc * New York From megacz at cs.berkeley.edu Sat Jun 20 13:37:21 2009 From: megacz at cs.berkeley.edu (Adam Megacz) Date: Sat, 20 Jun 2009 10:37:21 -0700 Subject: Reading kerberos-adm from DNS (PATCH) References: <200703120511.AAA11265@quince.ifs.umich.edu> <1E393FB5-8557-4BBE-8896-5FCE67A6F41D@mit.edu> <62BB655E-AFB4-4C02-9B00-C6980E36D857@mit.edu> Message-ID: It seems that this patch didn't wind up in the recent kerberos release. Do you think somebody could review it for inclusion soon, so that it has a chance of making it into the next release? If any changes need to be made, please let me know and I will make them. Thanks! - a Ken Raeburn writes: > Sure. :) > At first glance it looks good, but I want to have a closer look > before committing it (unless someone else gets to it first). Thanks > for sending it in! > > Adam Megacz writes: > > Hi, would it be possible for the Kerberos maintainers to consider the > > patch below for inclusion in the main libkadm5 distribution? > > > > - a > > > > Adam Megacz writes: > >> Ken Raeburn writes: > >>>> I believe the future has already arrived. Current MIT code should > >>>> be capable of finding and using records like this: > >>>> > >>>> spam% dig _kerberos-adm._tcp.umich.edu srv > >>> > >>> This is used for the password-changing service, but unfortunately the > >>> RPC code used for the kadmin program still looks up admin_server, and > >>> uses the first IP address found when looking up that hostname. No > >>> DNS, one hostname, one address, no service-location plugin support, > >>> no IPv6. These do need to be fixed.... > >> > >> This should help. > >> > >> - a > >> > >> > >> diff --git a/src/lib/kadm5/alt_prof.c b/src/lib/kadm5/alt_prof.c > >> index bb87f88..48b1792 100644 > >> --- a/src/lib/kadm5/alt_prof.c > >> +++ b/src/lib/kadm5/alt_prof.c > >> @@ -416,10 +416,31 @@ krb5_error_code kadm5_get_config_params(context, kdcprofile, kdcenv, > >> params.admin_server = strdup(params_in->admin_server); > >> if (params.admin_server) > >> params.mask |= KADM5_CONFIG_ADMIN_SERVER; > >> - } else if (aprofile && > >> - !krb5_aprof_get_string(aprofile, hierarchy, TRUE, &svalue)) { > >> - params.admin_server = svalue; > >> - params.mask |= KADM5_CONFIG_ADMIN_SERVER; > >> + } else if (aprofile) { > >> + if (!krb5_aprof_get_string(aprofile, hierarchy, TRUE, &svalue)) { > >> + params.admin_server = svalue; > >> + params.mask |= KADM5_CONFIG_ADMIN_SERVER; > >> + } else { > >> + struct addrlist addrlist; > >> + int i; > >> + krb5_data drealm; > >> + drealm.data = (void*)params.realm; > >> + drealm.length = strlen(params.realm); > >> + if (!krb5int_locate_server(context, &drealm, &addrlist, 0, > >> + "admin_server", "_kerberos-adm", 1, > >> + DEFAULT_KPASSWD_PORT, 0, 0)) { > >> + for (i=0;i >> + struct addrinfo *a = addrlist.addrs[i]; > >> + if (a->ai_family == AF_INET) { > >> + params.admin_server = strdup(inet_ntoa(sa2sin(a->ai_addr)->sin_addr)); > >> + params.kadmind_port = ntohs(sa2sin (a->ai_addr)->sin_port); > >> + params.mask |= KADM5_CONFIG_ADMIN_SERVER; > >> + params.mask |= KADM5_CONFIG_KADMIND_PORT; > >> + break; > >> + } > >> + } > >> + } > >> + } > >> } > >> if (params.mask & KADM5_CONFIG_ADMIN_SERVER) { > >> char *p; > >> > >> ________________________________________________ > >> Kerberos mailing list Kerberos at mit.edu > >> https://mailman.mit.edu/mailman/listinfo/kerberos > >> > > > > -- > > > > ________________________________________________ > > Kerberos mailing list Kerberos at mit.edu > > https://mailman.mit.edu/mailman/listinfo/kerberos > > > > -- > From john at iastate.edu Sat Jun 20 14:56:55 2009 From: john at iastate.edu (John Hascall) Date: Sat, 20 Jun 2009 13:56:55 CDT Subject: /dev/random vs. /dev/urandom and the krb5 test suite In-Reply-To: Your message of Thu, 18 Jun 2009 00:48:28 -0400. <200906180448.n5I4mScF026930@outgoing.mit.edu> Message-ID: <10689.1245524215@malison.ait.iastate.edu> > The krb5 test suite generates a lot of random keying material. Under > the assumption that cryptographic keys require "strong" randomness, > most of that material comes from /dev/random. This can create stalls > in some environments; for instance, my Linux box spends a few extra > minutes per testing run if I don't use a local hack to make lib/crypto > use /dev/urandom instead. I have not noticed it in this regard, but I did notice some time ago, (and I thought I asked about it here, but my google-fu is weak today), that we had a similar problem with kadmind refusing to start due to a lack of entropy. Our KDCs do nothing else, so at boot time there was virtually no accumulated entropy and with kadmin refusing to start without "enough", nothing else ran to generate any. Catch-22. I ended up putting a silly little loop in our rc script: kadmind5_precmd() { need=2880 d=ld2a b=8192 while : ; do bits=`/sbin/rndctl -s | awk '$3 == "currently" {print $1}'` echo "Have $bits of entropy" [ $bits -ge $need ] && break echo "Not enough entropy for kadmin5, trying to make some" x=`date +%M%S` dd if=/dev/r$d of=/dev/null bs=$b skip=$x count=$x 2>/dev/null done echo "Entropy should be sufficient to start kadmind5" } Putting something like this in the testing sripts seems like it might be an alternative to a possibly-ill-advised option (of any name). John From tlyu at MIT.EDU Mon Jun 22 13:16:26 2009 From: tlyu at MIT.EDU (Tom Yu) Date: Mon, 22 Jun 2009 13:16:26 -0400 Subject: krb5-1.8 release planning Message-ID: We are in the process of planning the krb5-1.8 release. Please see the draft proposal at http://k5wiki.kerberos.org/wiki/Release_1.8 These proposed goals are a subset of the overall development roadmap, which you can see at http://k5wiki.kerberos.org/wiki/Roadmap I would appreciate feedback within the next two weeks. Suggestions for additional goals are welcome. Feedback on the relative priorities of the release goals is also useful, especially if it reflects customer or deployment experience. Feel free to start a thread on this mailing list if you would like us to explore one of these release goals in detail. Thanks. -- Tom Yu Development Team Leader MIT Kerberos Consortium From ghudson at MIT.EDU Mon Jun 22 15:38:13 2009 From: ghudson at MIT.EDU (Greg Hudson) Date: Mon, 22 Jun 2009 15:38:13 -0400 Subject: /dev/random vs. /dev/urandom and the krb5 test suite In-Reply-To: <200906180448.n5I4mScF026930@outgoing.mit.edu> References: <200906180448.n5I4mScF026930@outgoing.mit.edu> Message-ID: <1245699494.1921.9.camel@equal-rites.mit.edu> Since this thread has died, a summary of the outcome: * We only use /dev/random for long-term keys, not for short-term keys generated as a result of traffic to the KDC. * There isn't much operational reason why you'd want to suppress the use of /dev/random in favor of /dev/urandom for all keys. There was one report (from iastate) of a case where a server was so random-starved as to be unable to start kadmind, but using /dev/urandom in that case would be dangerous because the amount of entropy present might be so low as to be attackable. So we are talking purely about an option to be used to make the test suite friendlier to hosts with limited amounts of /dev/random entropy. * A couple of people suggested external methods of generating entropy for the test suite (triggering filesystem or I/O operations) but those methods are dissatisfying from a robustness perspective. * Since we only call for /dev/random in two places (kdb5_util and kadmind), we don't need the knob for this to live inside the library. * There is some resistance to using an environment variable for this purpose, since they can leak into production more easily than other knobs. More universally acceptable options include command-line switches to kadmind/kdb5_util, or a krb5.conf option. * Regarding my original question, as a group we are not aware of any specific attacks on using /dev/urandom to generate cryptographic keys unless the amount of entropy available is so small as to permit a brute force attack on the entire PRNG stream. However, that question is largely moot based on the earlier summary points. Thanks for the input. It is likely that either Tom or I will implement something taking all of this into account. From hartmans at MIT.EDU Mon Jun 22 16:51:43 2009 From: hartmans at MIT.EDU (Sam Hartman) Date: Mon, 22 Jun 2009 16:51:43 -0400 Subject: /dev/random vs. /dev/urandom and the krb5 test suite In-Reply-To: <1245699494.1921.9.camel@equal-rites.mit.edu> (Greg Hudson's message of "Mon\, 22 Jun 2009 15\:38\:13 -0400") References: <200906180448.n5I4mScF026930@outgoing.mit.edu> <1245699494.1921.9.camel@equal-rites.mit.edu> Message-ID: >>>>> "Greg" == Greg Hudson writes: Greg> * There isn't much operational reason why you'd want to Greg> suppress the use of /dev/random in favor of /dev/urandom for Greg> all keys. There was one report (from iastate) of a case Greg> where a server was so random-starved as to be unable to Greg> start kadmind, but using /dev/urandom in that case would be Greg> dangerous because the amount of entropy present might be so Greg> low as to be attackable. So we are talking purely about an Greg> option to be used to make the test suite friendlier to hosts Greg> with limited amounts of /dev/random entropy. It turns out we've seen this in a number of cases in Debian. It's generally acceptable to hold off starting up kadmind until the entropy pool fills. However it's generally not acceptable to Debian's users to block the system initialization process until that happens. The problem was fixed by seeding the PRNG from /dev/random after kadmind forks. I believe that was pushed upstream. From tlyu at MIT.EDU Mon Jun 22 17:03:45 2009 From: tlyu at MIT.EDU (Tom Yu) Date: Mon, 22 Jun 2009 17:03:45 -0400 Subject: /dev/random vs. /dev/urandom and the krb5 test suite In-Reply-To: (Sam Hartman's message of "Mon, 22 Jun 2009 16:51:43 -0400") References: <200906180448.n5I4mScF026930@outgoing.mit.edu> <1245699494.1921.9.camel@equal-rites.mit.edu> Message-ID: Sam Hartman writes: >>>>>> "Greg" == Greg Hudson writes: > > Greg> * There isn't much operational reason why you'd want to > Greg> suppress the use of /dev/random in favor of /dev/urandom for > Greg> all keys. There was one report (from iastate) of a case > Greg> where a server was so random-starved as to be unable to > Greg> start kadmind, but using /dev/urandom in that case would be > Greg> dangerous because the amount of entropy present might be so > Greg> low as to be attackable. So we are talking purely about an > Greg> option to be used to make the test suite friendlier to hosts > Greg> with limited amounts of /dev/random entropy. > > > It turns out we've seen this in a number of cases in Debian. It's > generally acceptable to hold off starting up kadmind until the entropy > pool fills. However it's generally not acceptable to Debian's users > to block the system initialization process until that happens. > > The problem was fixed by seeding the PRNG from /dev/random after > kadmind forks. I believe that was pushed upstream. Do you recall the Debian or krbdev RT bug numbers? From tlyu at MIT.EDU Mon Jun 22 17:03:19 2009 From: tlyu at MIT.EDU (Tom Yu) Date: Mon, 22 Jun 2009 17:03:19 -0400 Subject: /dev/random vs. /dev/urandom and the krb5 test suite In-Reply-To: <10689.1245524215@malison.ait.iastate.edu> (John Hascall's message of "Sat, 20 Jun 2009 13:56:55 CDT") References: <10689.1245524215@malison.ait.iastate.edu> Message-ID: John Hascall writes: >> The krb5 test suite generates a lot of random keying material. Under >> the assumption that cryptographic keys require "strong" randomness, >> most of that material comes from /dev/random. This can create stalls >> in some environments; for instance, my Linux box spends a few extra >> minutes per testing run if I don't use a local hack to make lib/crypto >> use /dev/urandom instead. > > I have not noticed it in this regard, but I did notice some time ago, > (and I thought I asked about it here, but my google-fu is weak today), > that we had a similar problem with kadmind refusing to start due to a > lack of entropy. Our KDCs do nothing else, so at boot time there was > virtually no accumulated entropy and with kadmin refusing to start > without "enough", nothing else ran to generate any. Catch-22. > I ended up putting a silly little loop in our rc script: > > kadmind5_precmd() { > need=2880 > d=ld2a > b=8192 > while : ; do > bits=`/sbin/rndctl -s | awk '$3 == "currently" {print $1}'` > echo "Have $bits of entropy" > [ $bits -ge $need ] && break > echo "Not enough entropy for kadmin5, trying to make some" > x=`date +%M%S` > dd if=/dev/r$d of=/dev/null bs=$b skip=$x count=$x 2>/dev/null > done > echo "Entropy should be sufficient to start kadmind5" > } > > > Putting something like this in the testing sripts seems like it might > be an alternative to a possibly-ill-advised option (of any name). This has the disadvantage of requiring tuning for specific operating systems, so I would discourage using it for testing scripts that must run on multiple operating systems. From john at iastate.edu Mon Jun 22 17:31:16 2009 From: john at iastate.edu (John Hascall) Date: Mon, 22 Jun 2009 16:31:16 CDT Subject: /dev/random vs. /dev/urandom and the krb5 test suite In-Reply-To: Your message of Mon, 22 Jun 2009 17:03:19 -0400. Message-ID: <17500.1245706276@malison.ait.iastate.edu> > John Hascall writes: [...scripty business elided...] > > Putting something like this in the testing sripts seems like it might > > be an alternative to a possibly-ill-advised option (of any name). > This has the disadvantage of requiring tuning for specific operating > systems, so I wourage using it for testing scripts that must > run on multiple operating systems. Sorry for my lack of clarity. I was not so much suggesting my particular "implementation", but that one might consider that the solution to insufficient randomness might be to generate more (by whatever method). John From rra at stanford.edu Mon Jun 22 19:03:23 2009 From: rra at stanford.edu (Russ Allbery) Date: Mon, 22 Jun 2009 16:03:23 -0700 Subject: /dev/random vs. /dev/urandom and the krb5 test suite In-Reply-To: (Tom Yu's message of "Mon\, 22 Jun 2009 17\:03\:45 -0400") References: <200906180448.n5I4mScF026930@outgoing.mit.edu> <1245699494.1921.9.camel@equal-rites.mit.edu> Message-ID: <87iqineuro.fsf@windlord.stanford.edu> Tom Yu writes: > Do you recall the Debian or krbdev RT bug numbers? Debian Bug#364308. I thought it was filed in the krbdev RT as well, but maybe I forgot to do so. -- Russ Allbery (rra at stanford.edu) From tlyu at MIT.EDU Mon Jun 22 20:04:50 2009 From: tlyu at MIT.EDU (Tom Yu) Date: Mon, 22 Jun 2009 20:04:50 -0400 Subject: /dev/random vs. /dev/urandom and the krb5 test suite In-Reply-To: <87iqineuro.fsf@windlord.stanford.edu> (Russ Allbery's message of "Mon, 22 Jun 2009 16:03:23 -0700") References: <200906180448.n5I4mScF026930@outgoing.mit.edu> <1245699494.1921.9.camel@equal-rites.mit.edu> <87iqineuro.fsf@windlord.stanford.edu> Message-ID: Russ Allbery writes: > Tom Yu writes: > >> Do you recall the Debian or krbdev RT bug numbers? > > Debian Bug#364308. I thought it was filed in the krbdev RT as well, but > maybe I forgot to do so. Ok, thanks. This is krbdev ticket #4693, fixed in krb5-1.6. From mdeloera at exacq.com Wed Jun 24 12:02:37 2009 From: mdeloera at exacq.com (Matthew M. DeLoera) Date: Wed, 24 Jun 2009 12:02:37 -0400 Subject: AcceptSecurityContext (SSPI) fails with SEC_E_LOGON_DENIED and a GSS-API Linux client Message-ID: <4A424E1D.9000906@exacq.com> I apologize if this isn't appropriate for this list, but hopefully someone will see something silly that I shouldn't do, or need to do! I've searched but haven't seemed to find the answer I need. I'm running MIT KRB5 (krb5-kdc, kadmin) on an Ubuntu box, and using it for my kdc and my test client. I'm running Windows XP SP2 (DNS name deloera.exacqlinux.org) for my test server. I created 2 Windows users - kerbsvr (pw 54321) and kerbclt (pw 12345) - and configured XP to authenticate to my KDC with Microsoft's ksetup: ksetup /setrealm EXACQLINUX.ORG ksetup /addkdc EXACQLINUX.ORG kdc.exacqlinux.org ksetup /setcomputerpassword machpw ksetup /addkpasswd kdc.exacqlinux.org kdc.exacqlinux.org ksetup /mapuser kerbsvr at EXACQLINUX.ORG kerbsvr ksetup /mapuser kerbclt at EXACQLINUX.ORG kerbclt I added kdc.exacqlinux.org to my Windows hosts file. I created kerbsvr at EXACQLINUX.ORG (pw ks1234), kerbclt at EXACQLINUX.ORG (pw kc1234), and host/deloera.exacqlinux.org at EXACQLINUX.ORG (pw machpw) on the kdc. The 2 user passwords are intentionally different between Windows and the kdc to prove things to myself. I added deloera.exacqlinux.org to the kdc's /etc/hosts. I rebooted XP and successfully logged in with kerbsvr/ks1234 to my EXACQLINUX.ORG realm (in the dropdown). I traced in Linux with Wireshark. The kdc rejects the first AS-REQ with KRB5KDC_ERR_PREAUTH_REQUIRED, a second AS-REQ/AS-REP with preauth material succeeds, and then there's a successful TGS-REQ/TGS-REP. Everything looks nominally good from the kdc's end. In WireShark, I see the expected kerbsvr and host/deloera.exacqlinux.org principals. Then: - Start my test server in Windows (AcquireCredentialsHandle with NULL, to use cached credentials). - In Linux, I successfully kinit kerbclt at EXACQLINUX.ORG then start my test client and WireShark. The client successfully calls gss_import_name with kerbclt at EXACQLINUX.ORG and gss_acquire_cred. - The client successfully calls gss_import_name with host at deloera.exacqlinux.org and then gss_init_sec_context, and sends the token to my test server. - The server calls AcceptSecurityContext with the token, and fails with SEC_E_LOGON_DENIED. Any suggestions? Since I was able to log into Windows as kerbsvr, then I'd think Windows and my kdc must be configured correctly. I successfully kinit'd on Linux, so the principals should all be fine. I apologize if this is more of an SSPI question, but I was hoping some of you have done some interoperability testing and perhaps have encountered this same situation. Regards, - Matthew DeLoera From hartmans at MIT.EDU Wed Jun 24 13:11:27 2009 From: hartmans at MIT.EDU (Sam Hartman) Date: Wed, 24 Jun 2009 13:11:27 -0400 Subject: AcceptSecurityContext (SSPI) fails with SEC_E_LOGON_DENIED and a GSS-API Linux client In-Reply-To: <4A424E1D.9000906@exacq.com> (Matthew M. DeLoera's message of "Wed\, 24 Jun 2009 12\:02\:37 -0400") References: <4A424E1D.9000906@exacq.com> Message-ID: Is your server actually running as the system account? If so, then no idea. If not, then for the server name in gss_init_sec_context, please try importing the name of the account it is running as. --Sam From ghudson at MIT.EDU Wed Jun 24 13:40:40 2009 From: ghudson at MIT.EDU (Greg Hudson) Date: Wed, 24 Jun 2009 13:40:40 -0400 Subject: Crypto Modularity proj proposal In-Reply-To: <6DAAB910-3AA0-485C-942A-7193B5DF67CB@mit.edu> References: <6DAAB910-3AA0-485C-942A-7193B5DF67CB@mit.edu> Message-ID: <1245865240.6259.68.camel@ray> The code organization part has already been discussed and I think is mostly uncontroversial. The hard part is what we do to allow keyblocks to support: * Caching of derived keys * Caching of implementation object handles for keys * References to keys stored opaquely in cryptographic modules The second and third points are related; I'm just drawing a distinction between the performance goal of not having to create an object handle for each operation and the functionality goal of being able to support opaque, external storage of long-term keys. There is some previous discussion of this in the thread beginning at: http://mailman.mit.edu/pipermail/krbdev/2008-September/006865.html Particularly: http://mailman.mit.edu/pipermail/krbdev/2008-September/006877.html The basic options I am aware of are: * Do nothing, and simply support none of the above-listed functionality. This sacrifices much of the value of the crypto modularity project, delivering only the ability to use different implementations of exactly the same crypto functionality as we currently have, likely without much opportunity for performance gains. * Simply change the size of the keyblock structures, breaking compatibility with the krb5 API and ABI. It's important to recognize that keyblock structures are contained by value inside krb5_creds and krb5_keytab_entry structures, and by reference in a few other structures. Even if it's rare for application code to play with krb5_keyblocks directly, any code which acquires and dereferences a krb5_creds structure would also experience ABI breakage. * Same as above, but use a configure switch to determine whether to build with the old or new ABI/API. This option effectively delegates the pain of breakage to the OS, but does not mitigate it. This option has specific advantages for Sun if we use a specific set of new structure fields. * Rev every part of the API which deals with keyblocks. By this I mean create new structure and function names for every library symbol affected by keyblocks, and make the old names operate in a compatibility mode. Because of the infiltration of keyblocks into credentials, this is a pretty massive change. Some of the higher-level functions might remain untouched (like rd_req and mk_req), although at least mk_creds and rd_creds would have to change. * Reuse the contents field of a keyblock as a pointer to an extended structure; this allows us to add fields without changing the size. Label this using a new magic number, so that keyblocks constructed by old application code would continue to work with lower efficiency. This is effectively breaking the ABI and API, but in a more limited way: - Code which retrieves a keyblock and directly uses the contents would break ungracefully (probably seg faulting); affected code might include things like aklog which push keys from user space into kernel space. - Because we do not check magic numbers in every function currently using keyblocks, old code does not necessarily set these fields. It's unlikely for random stack or heap garbage to contain the new magic number--but stack garbage is not random, and it's quite conceivable for the new magic number to make its way from a deallocated or discarded keyblock structure to the uninitialized magic field of an application-created keyblock. We can mitigate this possibility somewhat by zeroing the magic field in krb5int_c_free_keyblock_contents. * Same as above, but using a special enctype instead of a new magic number. This option sidesteps the uninitialized-magic problem, but has different pitfalls in the other department: - Code which retrieves a keyblock and directly uses the contents has at least a chance of breaking more gracefully, as it might check the enctype first. But it might still fail ungracefully. - Code which retrieves a keyblock and examines the enctype (but does not directly use the contents) will fail, when it would have succeeded under the new-magic-number option. * In the krb5_context, store a lookaside table mapping keyblock contents to extended structures. This structure would be somewhat slow to access because of the need to hash and maybe compare 128-bit or 256-bit values. In some cases the extended structures might not be found: - If it never existed (keyblock constructed by application code) - If a keyblock is used with a different krb5_context from the one it was created in - If a keyblock is copied, and then the original freed (triggering the removal of the lookaside entry) Failure to find extended structures would only impact performance, except when opaque external key references are used. * Same as the above option, but use keyblock addresses instead of contents as the keys for better performance. Nico considered this option in September but discarded it because keyblocks can be stack-allocated; I am not sure if that's a fatal objection. If we only create lookaside entries at keyblock construction time, we can avoid creating entries for stack-allocated keyblocks (or, more generally, keyblocks that won't be freed through an API we control); the downside is that we don't cache derived keys or object handles for application-constructed keyblocks unless they use some new constructor API. I'm interested in discussion of which option is best, and options we might have missed. Please keep the conversation forward-looking; we are not currently budgeted for a time machine. On Thu, 2009-06-18 at 14:40 -0400, Zhanna Tsitkova wrote: > FYI > A new project proposal is posted on http://k5wiki.kerberos.org/wiki/Projects/Crypto_modularity > to address Crypto Modularity of MIT Kerberos code. > > > > > _______________________________________________ > krbdev mailing list krbdev at mit.edu > https://mailman.mit.edu/mailman/listinfo/krbdev From mdeloera at exacq.com Wed Jun 24 13:52:31 2009 From: mdeloera at exacq.com (Matthew M. DeLoera) Date: Wed, 24 Jun 2009 13:52:31 -0400 Subject: AcceptSecurityContext (SSPI) fails with SEC_E_LOGON_DENIED and a GSS-API Linux client In-Reply-To: References: <4A424E1D.9000906@exacq.com> Message-ID: <4A4267DF.20902@exacq.com> Actually, my Windows service is running under the kerbsvr user account, not the system account..... Per your suggestion, I created a "kerbsvr/deloera.exacqlinux.org" principal in my kdc, then imported "kerbsvr at deloera.exacqlinux.org" into my gss_init_sec_context call. The server process was still running as the kerbsvr user account. It worked. I *really* appreciate your tip! Can you or someone tell me what this means, then? FYI, my test service can build and run in Windows (with SSPI) as well as Linux (via GSSAPI) and is intended to be compatible with both AD and Linux KDCs. The Linux version was extremely simple to get working, and it's super easy to manage my keytab. My understanding of Windows service security is much sketchier, unfortunately. Since there's no keytab, my understanding is totally empirical right now, and it's not easy to find good references on "Kerberized Windows service". When working with AD, it works if I create the SPN via ktpass, map it to the account as which the service will run, then request that SPN in my client. So that leaves me with questions about setspn vs. ktpass, host/deloera.exacqlinux.org vs. myservice/deloera.exacqlinux.org, and as what account should a Windows service run in which circumstances. As for working with krb5-kdc, why did it work with the user principal under which the service was running, instead of the generic host principal? Is the host principal really an SPN, or something slightly different, and am I misunderstanding things? As which Windows account should I run my service? Also, are there any good examples or guides that I should check out? I've gotten this far by synthesizing a lot of different bits and pieces here and there, but I'm still looking for good references to further clarify all of this. Thanks for the assistance! Regards, - Matthew Sam Hartman wrote: > Is your server actually running as the system account? > If so, then no idea. > > If not, then for the server name in gss_init_sec_context, please try > importing the name of the account it is running as. > > --Sam > > From mdeloera at exacq.com Wed Jun 24 13:52:57 2009 From: mdeloera at exacq.com (Matthew M. DeLoera) Date: Wed, 24 Jun 2009 13:52:57 -0400 Subject: AcceptSecurityContext (SSPI) fails with SEC_E_LOGON_DENIED and a GSS-API Linux client In-Reply-To: References: <4A424E1D.9000906@exacq.com> Message-ID: <4A4267F9.1070704@exacq.com> Sam, Actually, my Windows service is running under the kerbsvr user account, not the system account..... Per your suggestion, I created a "kerbsvr/deloera.exacqlinux.org" principal in my kdc, then imported "kerbsvr at deloera.exacqlinux.org" into my gss_init_sec_context call. The server process was still running as the kerbsvr user account. It worked. I *really* appreciate your tip! Can you or someone tell me what this means, then? FYI, my test service can build and run in Windows (with SSPI) as well as Linux (via GSSAPI) and is intended to be compatible with both AD and Linux KDCs. The Linux version was extremely simple to get working, and it's super easy to manage my keytab. My understanding of Windows service security is much sketchier, unfortunately. Since there's no keytab, my understanding is totally empirical right now, and it's not easy to find good references on "Kerberized Windows service". When working with AD, it works if I create the SPN via ktpass, map it to the account as which the service will run, then request that SPN in my client. So that leaves me with questions about setspn vs. ktpass, host/deloera.exacqlinux.org vs. myservice/deloera.exacqlinux.org, and as what account should a Windows service run in which circumstances. As for working with krb5-kdc, why did it work with the user principal under which the service was running, instead of the generic host principal? Is the host principal really an SPN, or something slightly different, and am I misunderstanding things? As which Windows account should I run my service? Also, are there any good examples or guides that I should check out? I've gotten this far by synthesizing a lot of different bits and pieces here and there, but I'm still looking for good references to further clarify all of this. Thanks for the assistance! Regards, - Matthew Sam Hartman wrote: > Is your server actually running as the system account? > If so, then no idea. > > If not, then for the server name in gss_init_sec_context, please try > importing the name of the account it is running as. > > --Sam > > From Nicolas.Williams at sun.com Wed Jun 24 13:50:43 2009 From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Wed, 24 Jun 2009 12:50:43 -0500 Subject: Crypto Modularity proj proposal In-Reply-To: <1245865240.6259.68.camel@ray> References: <6DAAB910-3AA0-485C-942A-7193B5DF67CB@mit.edu> <1245865240.6259.68.camel@ray> Message-ID: <20090624175043.GM1308@Sun.COM> On Wed, Jun 24, 2009 at 01:40:40PM -0400, Greg Hudson wrote: > The code organization part has already been discussed and I think is > mostly uncontroversial. > > The hard part is what we do to allow keyblocks to support: > * Caching of derived keys I think it turns out to be easier than we (Wyllys and I) thought years ago when Wyllys implemented this for Solaris. Love argues that there's no need to change krb5_keyblock, mostly because performance matters most in the GSS-API mechanism, where we have a great place to stash derived keys: the mech-specific gss_ctx_id_t. I agree with that. If you do this then only GSS apps will get the perf improvement, though you could also cache derived keys in krb5_auth_context for raw krb5 apps. > * Caching of implementation object handles for keys > * References to keys stored opaquely in cryptographic modules > The second and third points are related; I'm just drawing a distinction > between the performance goal of not having to create an object handle > for each operation and the functionality goal of being able to support > opaque, external storage of long-term keys. Keys stored in HW tokens should be allowed only for long-term keys. If you do that then you need only make the token/slot/session available to the pre-auth plugins (and on the KDC side for using the master DB keys and, maybe, TGS and kadmin keys). Again, no need to touch krb5_keyblock. Nico -- From paul.moore at centrify.com Wed Jun 24 14:01:36 2009 From: paul.moore at centrify.com (Paul Moore) Date: Wed, 24 Jun 2009 11:01:36 -0700 Subject: AcceptSecurityContext (SSPI) fails with SEC_E_LOGON_DENIED anda GSS-API Linux client In-Reply-To: <4A4267F9.1070704@exacq.com> References: <4A424E1D.9000906@exacq.com> <4A4267F9.1070704@exacq.com> Message-ID: a service has access to the 'keytab' for its own account. SO the service running under kerbsvr account has no access to the 'keytab' that belongs to the system account (the one that belongs to the machine); you were trying to authenticate to the system account (host/) Also another thing to remeber is that you need to have the right 'allow access from the network ' right set for the on the server machine. For regular server and client machines this is OK, but for Domain Controllers it is not; DC have this set to a restricted list of accounts. -----Original Message----- From: krbdev-bounces at mit.edu [mailto:krbdev-bounces at mit.edu] On Behalf Of Matthew M. DeLoera Sent: Wednesday, June 24, 2009 10:53 AM To: krbdev at mit.edu Subject: Re: AcceptSecurityContext (SSPI) fails with SEC_E_LOGON_DENIED anda GSS-API Linux client Sam, Actually, my Windows service is running under the kerbsvr user account, not the system account..... Per your suggestion, I created a "kerbsvr/deloera.exacqlinux.org" principal in my kdc, then imported "kerbsvr at deloera.exacqlinux.org" into my gss_init_sec_context call. The server process was still running as the kerbsvr user account. It worked. I *really* appreciate your tip! Can you or someone tell me what this means, then? FYI, my test service can build and run in Windows (with SSPI) as well as Linux (via GSSAPI) and is intended to be compatible with both AD and Linux KDCs. The Linux version was extremely simple to get working, and it's super easy to manage my keytab. My understanding of Windows service security is much sketchier, unfortunately. Since there's no keytab, my understanding is totally empirical right now, and it's not easy to find good references on "Kerberized Windows service". When working with AD, it works if I create the SPN via ktpass, map it to the account as which the service will run, then request that SPN in my client. So that leaves me with questions about setspn vs. ktpass, host/deloera.exacqlinux.org vs. myservice/deloera.exacqlinux.org, and as what account should a Windows service run in which circumstances. As for working with krb5-kdc, why did it work with the user principal under which the service was running, instead of the generic host principal? Is the host principal really an SPN, or something slightly different, and am I misunderstanding things? As which Windows account should I run my service? Also, are there any good examples or guides that I should check out? I've gotten this far by synthesizing a lot of different bits and pieces here and there, but I'm still looking for good references to further clarify all of this. Thanks for the assistance! Regards, - Matthew Sam Hartman wrote: > Is your server actually running as the system account? > If so, then no idea. > > If not, then for the server name in gss_init_sec_context, please try > importing the name of the account it is running as. > > --Sam > > _______________________________________________ krbdev mailing list krbdev at mit.edu https://mailman.mit.edu/mailman/listinfo/krbdev From tlyu at MIT.EDU Wed Jun 24 14:03:47 2009 From: tlyu at MIT.EDU (Tom Yu) Date: Wed, 24 Jun 2009 14:03:47 -0400 Subject: AS_REQ key expiration vs principal expiration checking order? Message-ID: Existing code in src/kdc_util.c (trunk and krb5-1.7, also probably older releases), while validating the AS_REQ, checks for key expiration before checking for client principal expiration. There is a bug report that the principal expiration condition should be reported to the client in preference to the password expiration condition, rather than the reverse ordering, which is what the code currently does: http://krbdev.mit.edu/rt/Ticket/Display.html?id=6428 Does anyone recall a reason why we might deliberately use the existing ordering for AS_REQ validation? RFC 4120 and RFC 1510 do not specify anything related to this behavior. From hartmans at MIT.EDU Wed Jun 24 14:13:36 2009 From: hartmans at MIT.EDU (Sam Hartman) Date: Wed, 24 Jun 2009 14:13:36 -0400 Subject: AcceptSecurityContext (SSPI) fails with SEC_E_LOGON_DENIED and a GSS-API Linux client In-Reply-To: <4A4267DF.20902@exacq.com> (Matthew M. DeLoera's message of "Wed\, 24 Jun 2009 13\:52\:31 -0400") References: <4A424E1D.9000906@exacq.com> <4A4267DF.20902@exacq.com> Message-ID: >>>>> "Matthew" == Matthew M DeLoera writes: 8 Matthew> Actually, my Windows service is running under the kerbsvr Matthew> user account, not the system account..... Ok, then you need to import kerbsvr as a name using gss_nt_user_principal or some such rather than gss_nt_srv_hst. You should not create a new principal in the KDC. --Sam From mdeloera at exacq.com Wed Jun 24 14:19:01 2009 From: mdeloera at exacq.com (Matthew M. DeLoera) Date: Wed, 24 Jun 2009 14:19:01 -0400 Subject: AcceptSecurityContext (SSPI) fails with SEC_E_LOGON_DENIED anda GSS-API Linux client In-Reply-To: References: <4A424E1D.9000906@exacq.com> <4A4267F9.1070704@exacq.com> Message-ID: <4A426E15.1090703@exacq.com> Paul, (hopefully my last list posting didn't pop up twice....) Ah, I see. I'll experiment with those notes. They leave me with 2 offhand questions: - Are there any conventions surrounding using a host principal versus a more custom user principal? Would it be preferable to run as the system account so that I can use the host principal, or preferable to create some service accounts in order to specify something custom like "myservice/"? Or is it just whatever I feel like? - Is the reverse question true? If I want to specify a custom service class, must I have a corresponding account? If so, could I just use the same class name on each server that run my service? FYI, I don't intend to run my service on domain controllers. I intend for the kdc to be external to all systems running my service. Regards, - Matthew Paul Moore wrote: > a service has access to the 'keytab' for its own account. SO the service > running under kerbsvr account has no access to the 'keytab' that belongs > to the system account (the one that belongs to the machine); you were > trying to authenticate to the system account (host/) > > Also another thing to remeber is that you need to have the right 'allow > access from the network ' right set for the on the server machine. > For regular server and client machines this is OK, but for Domain > Controllers it is not; DC have this set to a restricted list of > accounts. > > From paul.moore at centrify.com Wed Jun 24 14:35:07 2009 From: paul.moore at centrify.com (Paul Moore) Date: Wed, 24 Jun 2009 11:35:07 -0700 Subject: AcceptSecurityContext (SSPI) fails with SEC_E_LOGON_DENIED anda GSS-API Linux client In-Reply-To: <4A426E15.1090703@exacq.com> References: <4A424E1D.9000906@exacq.com> <4A4267F9.1070704@exacq.com> <4A426E15.1090703@exacq.com> Message-ID: lets get a few basics a) the gss app runs as some account as far as windows is concerned. This has to be an account that exists in AD (since that where all MS kerberosness flows from) b) the machine itself has an account in AD Its called $ and is created when the machine joins the domain c) Service principal names are associated with AD accounts you can have several SPNs associated with one account. If you look at the machine's account you will see it has several SPNs (host/, host/.acme.com, ...) SO what does this mean well you could create an account called foo, add an SPN to it called bar/wizbang, logon as foo and run the server at a command prompt. This works fine (if you tell the client to target the bar/wizbang spn), but lacks a little in convenience {Note - you cannot target an account the does not have an SPN set on it. Even if the client was to set the target to 'foo' it would fail - AD wont let you do it} You really need to run the server as a service. When you run as a service you have to say what account it runs under. You have 2 choices 1) run as the machine 2) run as somebody else 1 is very convenient because you don't have to create a special account, nor do you have to enter its password. But it is suggested by many that this breaks the least privilege concept; you are running as Windows version of 'root', this lays you open to all sorts of potential hacks if your code isnt 100% safe. Also you dont have to add SPNs to the machine account - its already got them 2 is safe. Run as account with the bare minimum of rights. But you have to enter the password in the service UI and either - stop the password from being forcibly changed (not secure) - change the password regularly and remember to update the service settings And you must add SPNs -----Original Message----- From: Matthew M. DeLoera [mailto:mdeloera at exacq.com] Sent: Wednesday, June 24, 2009 11:19 AM To: krbdev at mit.edu Subject: Re: AcceptSecurityContext (SSPI) fails with SEC_E_LOGON_DENIED anda GSS-API Linux client Paul, (hopefully my last list posting didn't pop up twice....) Ah, I see. I'll experiment with those notes. They leave me with 2 offhand questions: - Are there any conventions surrounding using a host principal versus a more custom user principal? Would it be preferable to run as the system account so that I can use the host principal, or preferable to create some service accounts in order to specify something custom like "myservice/"? Or is it just whatever I feel like? - Is the reverse question true? If I want to specify a custom service class, must I have a corresponding account? If so, could I just use the same class name on each server that run my service? FYI, I don't intend to run my service on domain controllers. I intend for the kdc to be external to all systems running my service. Regards, - Matthew Paul Moore wrote: > a service has access to the 'keytab' for its own account. SO the service > running under kerbsvr account has no access to the 'keytab' that belongs > to the system account (the one that belongs to the machine); you were > trying to authenticate to the system account (host/) > > Also another thing to remeber is that you need to have the right 'allow > access from the network ' right set for the on the server machine. > For regular server and client machines this is OK, but for Domain > Controllers it is not; DC have this set to a restricted list of > accounts. > > From jhutz at cmu.edu Wed Jun 24 17:04:43 2009 From: jhutz at cmu.edu (Jeffrey Hutzelman) Date: Wed, 24 Jun 2009 17:04:43 -0400 Subject: Crypto Modularity proj proposal In-Reply-To: <16178_1245866488_n5OI1RVV012055_20090624175043.GM1308@Sun.COM> References: <6DAAB910-3AA0-485C-942A-7193B5DF67CB@mit.edu> <1245865240.6259.68.camel@ray> <16178_1245866488_n5OI1RVV012055_20090624175043.GM1308@Sun.COM> Message-ID: <4EB5F19C45BF58FDEE590B58@MINBAR.FAC.CS.CMU.EDU> --On Wednesday, June 24, 2009 12:50:43 PM -0500 Nicolas Williams wrote: > On Wed, Jun 24, 2009 at 01:40:40PM -0400, Greg Hudson wrote: >> The code organization part has already been discussed and I think is >> mostly uncontroversial. >> >> The hard part is what we do to allow keyblocks to support: >> * Caching of derived keys > > I think it turns out to be easier than we (Wyllys and I) thought years > ago when Wyllys implemented this for Solaris. Love argues that there's > no need to change krb5_keyblock, mostly because performance matters most > in the GSS-API mechanism, where we have a great place to stash derived > keys: the mech-specific gss_ctx_id_t. I agree with that. > > If you do this then only GSS apps will get the perf improvement, though > you could also cache derived keys in krb5_auth_context for raw krb5 > apps. The problem with this theory is that it massively breaks modularity. Neither the GSS-API mechanism nor the auth-context-level operations need access to the underlying crypto primitives. Anything that's going to benefit caching, hardware assist, etc is below the 3961 abstraction. Most especially, notably, key derivation happens below the 3961 abstraction. Also, we know there are things coming along which use the 3961 interface directly, including various GSS-API mechanism proposals, a new security class for AFS, and I think something else I've forgotten about. These things should also get the performance benefits. >> * Caching of implementation object handles for keys >> * References to keys stored opaquely in cryptographic modules >> The second and third points are related; I'm just drawing a distinction >> between the performance goal of not having to create an object handle >> for each operation and the functionality goal of being able to support >> opaque, external storage of long-term keys. > > Keys stored in HW tokens should be allowed only for long-term keys. If > you do that then you need only make the token/slot/session available to > the pre-auth plugins (and on the KDC side for using the master DB keys > and, maybe, TGS and kadmin keys). Again, no need to touch > krb5_keyblock. Unless there is fancy preauth in use, I need my long-term key to decrpyt an AS_REP. Services need their long-term keys to decrypt AP_REQ's. Again, I think there's another case I'm forgetting. You seem to be arguing for leaving the current abstractions as-is and inventing a complete new set of interfaces, then changing everything to use the new interfaces. I suppose that's an option, but it's a pretty invasive one. -- Jeff From jhutz at cmu.edu Wed Jun 24 17:15:12 2009 From: jhutz at cmu.edu (Jeffrey Hutzelman) Date: Wed, 24 Jun 2009 17:15:12 -0400 Subject: AS_REQ key expiration vs principal expiration checking order? In-Reply-To: <12542_1245866876_n5OI7tlF013293_ldv4ou5ik58.fsf@cathode-dark-space.mit.edu> References: <12542_1245866876_n5OI7tlF013293_ldv4ou5ik58.fsf@cathode-dark-space.mit.edu> Message-ID: <587A6E00D1BCFAAC4543A0F4@MINBAR.FAC.CS.CMU.EDU> --On Wednesday, June 24, 2009 02:03:47 PM -0400 Tom Yu wrote: > Existing code in src/kdc_util.c (trunk and krb5-1.7, also probably > older releases), while validating the AS_REQ, checks for key > expiration before checking for client principal expiration. There is > a bug report that the principal expiration condition should be > reported to the client in preference to the password expiration > condition, rather than the reverse ordering, which is what the code > currently does: > > http://krbdev.mit.edu/rt/Ticket/Display.html?id=6428 > > Does anyone recall a reason why we might deliberately use the existing > ordering for AS_REQ validation? RFC 4120 and RFC 1510 do not specify > anything related to this behavior. I can't think of one, and I can think of a good reason to check for client principal expiration first. Particularly, KDC_ERR_KEY_EXPIRED carries the implication that you can resolve the problem by changing the password, and a pretty large class of clients (PAM modules and similar) will assume this and prompt the user to change the password. -- Jeff From raeburn at MIT.EDU Wed Jun 24 17:24:44 2009 From: raeburn at MIT.EDU (Ken Raeburn) Date: Wed, 24 Jun 2009 17:24:44 -0400 Subject: Crypto Modularity proj proposal In-Reply-To: <1245865240.6259.68.camel@ray> References: <6DAAB910-3AA0-485C-942A-7193B5DF67CB@mit.edu> <1245865240.6259.68.camel@ray> Message-ID: <30D91687-DDD1-42BA-9E5D-75379EF49F23@mit.edu> On Jun 24, 2009, at 13:40, Greg Hudson wrote: > The hard part is what we do to allow keyblocks to support: Caching of key schedules? If you're going to encrypt 30000 short messages with the same key, it'd be faster if you don't have to generate the key schedule 30000 times. This would mostly be of interest for the derived keys; there aren't going to be too many encryptions directly with the primary keys except to generate a handful of derived keys. -- Ken Raeburn / raeburn at mit.edu / no longer at MIT Kerberos Consortium From Nicolas.Williams at sun.com Wed Jun 24 17:11:53 2009 From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Wed, 24 Jun 2009 16:11:53 -0500 Subject: Crypto Modularity proj proposal In-Reply-To: <4EB5F19C45BF58FDEE590B58@MINBAR.FAC.CS.CMU.EDU> References: <6DAAB910-3AA0-485C-942A-7193B5DF67CB@mit.edu> <1245865240.6259.68.camel@ray> <16178_1245866488_n5OI1RVV012055_20090624175043.GM1308@Sun.COM> <4EB5F19C45BF58FDEE590B58@MINBAR.FAC.CS.CMU.EDU> Message-ID: <20090624211153.GZ1308@Sun.COM> On Wed, Jun 24, 2009 at 05:04:43PM -0400, Jeffrey Hutzelman wrote: > --On Wednesday, June 24, 2009 12:50:43 PM -0500 Nicolas Williams > wrote: > >[...] > > The problem with this theory is that it massively breaks modularity. Not really: you can always introduce a new version of krb5_keyblock that does the Right Thing (tm) and use that in the GSS and auth contexts. (Also, though we didn't have an ABI to break, it's very likely that diverging from the MIT krb5 ABI will cause us headaches down the road. Now I'm having buyer's remorse.) > >Keys stored in HW tokens should be allowed only for long-term keys. If > >you do that then you need only make the token/slot/session available to > >the pre-auth plugins (and on the KDC side for using the master DB keys > >and, maybe, TGS and kadmin keys). Again, no need to touch > >krb5_keyblock. > > Unless there is fancy preauth in use, I need my long-term key to decrpyt an > AS_REP. Services need their long-term keys to decrypt AP_REQ's. Again, I > think there's another case I'm forgetting. My list was clearly not exhaustive (in that I failed to make it so :). But also, I did say "only for long-term keys", which includes the keys servers store. > You seem to be arguing for leaving the current abstractions as-is and > inventing a complete new set of interfaces, then changing everything to use > the new interfaces. I suppose that's an option, but it's a pretty invasive > one. Almost a correct characterization. I'm not advocating changing _everything_ to use new interfaces. I'm advocating changing those components where the perf boost of caching derived keys is most sorely needed, and that would be the GSS-API mechanism. Nico -- From ghudson at MIT.EDU Fri Jun 26 12:55:50 2009 From: ghudson at MIT.EDU (Greg Hudson) Date: Fri, 26 Jun 2009 12:55:50 -0400 Subject: Crypto Modularity proj proposal In-Reply-To: <4EB5F19C45BF58FDEE590B58@MINBAR.FAC.CS.CMU.EDU> References: <6DAAB910-3AA0-485C-942A-7193B5DF67CB@mit.edu> <1245865240.6259.68.camel@ray> <16178_1245866488_n5OI1RVV012055_20090624175043.GM1308@Sun.COM> <4EB5F19C45BF58FDEE590B58@MINBAR.FAC.CS.CMU.EDU> Message-ID: <1246035350.6259.115.camel@ray> On Wed, 2009-06-24 at 17:04 -0400, Jeffrey Hutzelman wrote: > You seem to be arguing for leaving the current abstractions as-is and > inventing a complete new set of interfaces, then changing everything to use > the new interfaces. I suppose that's an option, but it's a pretty invasive > one. Nico is effectively proposing a variation on the "rev every part of the API which deals with keyblocks" option, where we only rev the crypto API itself and not the krb5.h structures which currently reference keyblocks. In this proposal, a krb5_keyblock continues to hold only a cryptographic key (no other state) and some other structure would be created to hold cached information derived from a key or references to keys. The basic question here is: when keyblocks are used in other krb5.h structures, (a) when would it be very convenient to store cached information alongside them, and (b) when could it make sense to store an external reference instead of a key? Here are the structure references: * krb5_enc_tkt_part: session key contained within ticket * krb5_authenticator: AP-REQ subkey * krb5_enc_kdc_rep_part: session key sent from KDC to client * krb5_ap_rep_enc_part: AP-REP subkey. * krb5_cred_info: session key in ticket forwarding message * krb5_creds (by value): ticket session key stored by client * krb5_keytab_entry (by value): secret key of keytab entry For (a), I don't think any of these keys are used to perform repeated encryptions with the same key usage; as Nico points out, that would be done with keys stored in krb5_auth_context or krb5_gss_ctx_id_t structures, which are private. For (b), the last case is one of the primary cases where someone might want to use an external reference. Possibly the second-to-last case as well; a client might want to push the session key into a cryptographic token at AS-REQ time. So those would be problem cases. From Nicolas.Williams at sun.com Sat Jun 27 19:02:52 2009 From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Sat, 27 Jun 2009 18:02:52 -0500 Subject: Crypto Modularity proj proposal In-Reply-To: <1246035350.6259.115.camel@ray> References: <6DAAB910-3AA0-485C-942A-7193B5DF67CB@mit.edu> <1245865240.6259.68.camel@ray> <16178_1245866488_n5OI1RVV012055_20090624175043.GM1308@Sun.COM> <4EB5F19C45BF58FDEE590B58@MINBAR.FAC.CS.CMU.EDU> <1246035350.6259.115.camel@ray> Message-ID: <20090627230252.GW1308@Sun.COM> On Fri, Jun 26, 2009 at 12:55:50PM -0400, Greg Hudson wrote: > On Wed, 2009-06-24 at 17:04 -0400, Jeffrey Hutzelman wrote: > > You seem to be arguing for leaving the current abstractions as-is and > > inventing a complete new set of interfaces, then changing everything to use > > the new interfaces. I suppose that's an option, but it's a pretty invasive > > one. > > Nico is effectively proposing a variation on the "rev every part of the > API which deals with keyblocks" option, where we only rev the crypto API > itself and not the krb5.h structures which currently reference > keyblocks. In this proposal, a krb5_keyblock continues to hold only a > cryptographic key (no other state) and some other structure would be > created to hold cached information derived from a key or references to > keys. I don't quite understand your characterization of my proposal, so I'll just say that's not it ;) I'm saying that caching derived keys is performance critical in only a few places, and that those are mostly (only?) the ones where we happen to have an apaque context handle in which to hold the derived keys (the GSS mechanism's security context handles, and the krb5_auth_context)... ... therefore: cache derived keys in those handles and leave krb5_keyblock and all existing references to it alone. This may mean _adding_ new APIs that take derived keys (for implementing the GSS-API mechanism's per-token message functions, and for the krb5_mk/rd_priv/safe/cred() functions. But that would not be a wholesale revving of "every part of the API which deals with keyblocks". > The basic question here is: when keyblocks are used in other krb5.h > structures, (a) when would it be very convenient to store cached > information alongside them, and (b) when could it make sense to store an > external reference instead of a key? Here are the structure references: > > * krb5_enc_tkt_part: session key contained within ticket > * krb5_authenticator: AP-REQ subkey > * krb5_enc_kdc_rep_part: session key sent from KDC to client > * krb5_ap_rep_enc_part: AP-REP subkey. > * krb5_cred_info: session key in ticket forwarding message > * krb5_creds (by value): ticket session key stored by client > * krb5_keytab_entry (by value): secret key of keytab entry > > For (a), I don't think any of these keys are used to perform repeated > encryptions with the same key usage; as Nico points out, that would be > done with keys stored in krb5_auth_context or krb5_gss_ctx_id_t > structures, which are private. Right. > For (b), the last case is one of the primary cases where someone might > want to use an external reference. Possibly the second-to-last case as > well; a client might want to push the session key into a cryptographic > token at AS-REQ time. So those would be problem cases. I don't think anyone will want session keys in tokens. As for deriving keys from non-extractable key material stored in tokens, that is problematic. Nico -- From jhutz at cmu.edu Sun Jun 28 12:02:30 2009 From: jhutz at cmu.edu (Jeffrey Hutzelman) Date: Sun, 28 Jun 2009 12:02:30 -0400 Subject: Crypto Modularity proj proposal In-Reply-To: <20090627230252.GW1308@Sun.COM> References: <6DAAB910-3AA0-485C-942A-7193B5DF67CB@mit.edu> <1245865240.6259.68.camel@ray> <16178_1245866488_n5OI1RVV012055_20090624175043.GM1308@Sun.COM> <4EB5F19C45BF58FDEE590B58@MINBAR.FAC.CS.CMU.EDU> <1246035350.6259.115.camel@ray> <20090627230252.GW1308@Sun.COM> Message-ID: <7149710FE9572AA487E96501@atlantis.pc.cs.cmu.edu> --On Saturday, June 27, 2009 06:02:52 PM -0500 Nicolas Williams wrote: > I'm saying that caching derived keys is performance critical in only a > few places, and that those are mostly (only?) the ones where we happen > to have an apaque context handle in which to hold the derived keys (the > GSS mechanism's security context handles, and the krb5_auth_context)... > > ... therefore: cache derived keys in those handles and leave > krb5_keyblock and all existing references to it alone. That seems a reasonable approach. > This may mean _adding_ new APIs that take derived keys (for implementing > the GSS-API mechanism's per-token message functions, and for the > krb5_mk/rd_priv/safe/cred() functions. ... and for external users that might benefit from such caching. >> For (b), the last case is one of the primary cases where someone might >> want to use an external reference. Possibly the second-to-last case as >> well; a client might want to push the session key into a cryptographic >> token at AS-REQ time. So those would be problem cases. > > I don't think anyone will want session keys in tokens. Application session keys, no. TGT session keys, maybe. Or at least, in something that presents the same interface as a token: you tell it the key once, and never get it back, but it does crypto operations for you. > As for deriving > keys from non-extractable key material stored in tokens, that is > problematic. That depends on the derivation in use. The key derivations used in RFC3961 and RFC3962 all depend on either using the source key as an encryption key or (for single-DES) are the identity mapping. Both forms can be implemented with a non-extractable source key stored in a token, provided the token is willing to do encryption operations with that key. -- Jeff From Nicolas.Williams at sun.com Sun Jun 28 21:34:09 2009 From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Sun, 28 Jun 2009 20:34:09 -0500 Subject: Crypto Modularity proj proposal In-Reply-To: <7149710FE9572AA487E96501@atlantis.pc.cs.cmu.edu> References: <6DAAB910-3AA0-485C-942A-7193B5DF67CB@mit.edu> <1245865240.6259.68.camel@ray> <16178_1245866488_n5OI1RVV012055_20090624175043.GM1308@Sun.COM> <4EB5F19C45BF58FDEE590B58@MINBAR.FAC.CS.CMU.EDU> <1246035350.6259.115.camel@ray> <20090627230252.GW1308@Sun.COM> <7149710FE9572AA487E96501@atlantis.pc.cs.cmu.edu> Message-ID: <20090629013408.GA1308@Sun.COM> On Sun, Jun 28, 2009 at 12:02:30PM -0400, Jeffrey Hutzelman wrote: > >... therefore: cache derived keys in those handles and leave > >krb5_keyblock and all existing references to it alone. > > That seems a reasonable approach. I wish we'd thought of it years ago :( > >This may mean _adding_ new APIs that take derived keys (for implementing > >the GSS-API mechanism's per-token message functions, and for the > >krb5_mk/rd_priv/safe/cred() functions. > > ... and for external users that might benefit from such caching. Sure, adding a replacement for krb5_keyblock and full complement of APIs (including types) that deal in it would be fine, but it'd be a plus, not a requirement. > >I don't think anyone will want session keys in tokens. > > Application session keys, no. TGT session keys, maybe. Or at least, > in something that presents the same interface as a token: you tell it > the key once, and never get it back, but it does crypto operations for > you. True. This would have zero impact on the scheme I proposed (but really, it's Love's proposal). > > As for deriving > >keys from non-extractable key material stored in tokens, that is > >problematic. > > That depends on the derivation in use. The key derivations used in RFC3961 > and RFC3962 all depend on either using the source key as an encryption key > or (for single-DES) are the identity mapping. Both forms can be > implemented with a non-extractable source key stored in a token, provided > the token is willing to do encryption operations with that key. D'oh, yeah, you're right. Nico -- From jfoley at irobot.com Mon Jun 29 15:26:05 2009 From: jfoley at irobot.com (Foley, Joe) Date: Mon, 29 Jun 2009 15:26:05 -0400 Subject: The joys of ActiveDirectory and Kerberized SSH Message-ID: Hi there. We had a hell of a time getting ActiveDirectory Kerberos and Kerberized ssh to work here at iRobot, and I can't completely blame MicroSoft for the problems. Hacksaw (David Todd) best summarized it so I'm sending his email with with a bit of rewording. Goal: kerberize ssh access to our svn server (hq-svn), for use with svn+ssh style URL's. Involved software: libkrb53 in Ubuntu-8.04, ktpass from Microsoft on MS-Server 2003, samba from Ubuntu 8.04. Obstacles: There needs to be service principals put into the KDC, in this case Microsoft's active directory. - The mechanisms for doing this don't tell you what you have done. - It's possible with the commands for adding principals to add them to accounts to which they are not related. Thus (our Network Admin) Keith, thinking he was adding SPNs to the hq-svn account was actually adding them to his own accounts. This is an important point. Keith was allowed to add things to the database, which ensured that the database could not give a sane answer. This is a defiency in AD, but it wouldn't surprise me if others made this mistake. At some point the problem appeared to be the AD server giving back more than one answer to a query on a principal. This was very hard to detect because different clients failed in very different ways. Doing a kinit with the keytab for the principal "hq-svn/host" would fail, but "hq-svn%" worked. Once we had figured that out, the next step was to try again. Once again there was an error. In this case the error was "No such file or directory." with not hint as to what file or directory the thing might have been looking for. In fact, using ltrace didn't help this. I have no idea where it actually looks up that file name. It turns out that it was looking for keytab file. The only reason I realized that was because I started trying to think of the mechanism, and how it all worked. We really could have used help from the kerberos clients error messages. "No such file or directory" without context gives you no idea what to fix. When the clients got confused because they were getting multiple responses from the AD server, they gave nonsensical error messages. If the clients had simply told us that they didn't like the multiple answers it was getting back from the AD server, this would have helped clear things up much faster. To summarize, the error messages for problems like this *must* say what exactly is wrong, what resource is wrong or missing, preferably with as much context as possible. It's not reasonable to hope that ltrace or strace will give you enough information. It is also not reasonable for the sys-admin to be expected to run through the entire installation procedure again. Sys-admin's are harried, and need shortcuts and complete error messages. Joe Foley, Ph.D. Senior Mechanical Engineer iRobot G&I Research Mail Stop: 8-1 8 Crosby Dr. Bedford, MA 01730 T: 781-430-3117 F: 781-430-3001 From tlyu at MIT.EDU Tue Jun 30 08:27:27 2009 From: tlyu at MIT.EDU (Tom Yu) Date: Tue, 30 Jun 2009 08:27:27 -0400 Subject: The joys of ActiveDirectory and Kerberized SSH In-Reply-To: (Joe Foley's message of "Mon, 29 Jun 2009 15:26:05 -0400") References: Message-ID: "Foley, Joe" writes: > At some point the problem appeared to be the AD server giving back more > than one answer to a query on a principal. This was very hard to detect > because different clients failed in very different ways. Doing a kinit > with the keytab for the principal "hq-svn/host" would fail, but Are you sure this isn't "host/hq-svn" or "host/" followed by the fully-qualified domain name of "hq-svn"? > "hq-svn%" worked. I would expect this to be something like "HQ-SVN$" to correspond with the NetBIOS name of the host. I have not seen the percent sign in these contexts. I would like to know more details about the "AD server giving back more than one answer" situation. How did you determine this, and what different answers was it giving back? > Once we had figured that out, the next step was to try again. Once again > there was an error. In this case the error was "No such file or > directory." with not hint as to what file or directory the thing might > have been looking for. > > In fact, using ltrace didn't help this. I have no idea where it actually > looks up that file name. > > It turns out that it was looking for keytab file. The only reason I > realized that was because I started trying to think of the mechanism, > and how it all worked. Ubuntu 8.04 uses krb5-1.6.3. The recent krb5-1.7 release has many enhancements, which include providing extended error information strings in more places, including in the situation you describe. There is also a patch queued for the upcoming krb5-1.6.4 maintenance release to add that extended error reporting information. > To summarize, the error messages for problems like this *must* say what > exactly is wrong, what resource is wrong or missing, preferably with as > much context as possible. It's not reasonable to hope that ltrace or > strace will give you enough information. It is also not reasonable for > the sys-admin to be expected to run through the entire installation > procedure again. Sys-admin's are harried, and need shortcuts and > complete error messages. Thanks for letting us know. We have been working on improving our error reporting for some time now, mostly by adding extended error information to places where the existing fixed strings provide insufficient information. Having additional reports like yours can help us with that effort. From jfoley at irobot.com Tue Jun 30 10:34:23 2009 From: jfoley at irobot.com (Foley, Joe) Date: Tue, 30 Jun 2009 10:34:23 -0400 Subject: The joys of ActiveDirectory and Kerberized SSH In-Reply-To: References: Message-ID: >> "hq-svn%" worked. > >I would expect this to be something like "HQ-SVN$" to correspond with the NetBIOS name of the host. >I have not seen the percent sign in these contexts. Oops. Yes, I meant hq-svn$ I misremembered which special character it was. Thanks for pointing us at 1.7. I've also gotten responses from companies that do things with AD and Kerberos in general. Joe Foley, Ph.D. Senior Mechanical Engineer iRobot G&I Research Mail Stop: 8-1 8 Crosby Dr. Bedford, MA 01730 T: 781-430-3117 F: 781-430-3001 -----Original Message----- From: Tom Yu [mailto:tlyu at MIT.EDU] Sent: Tuesday, June 30, 2009 8:27 AM To: Foley, Joe Cc: krbdev at mit.edu; Todd, David Subject: Re: The joys of ActiveDirectory and Kerberized SSH "Foley, Joe" writes: > At some point the problem appeared to be the AD server giving back > more than one answer to a query on a principal. This was very hard to > detect because different clients failed in very different ways. Doing > a kinit with the keytab for the principal "hq-svn/host" would fail, > but Are you sure this isn't "host/hq-svn" or "host/" followed by the fully-qualified domain name of "hq-svn"? > "hq-svn%" worked. I would expect this to be something like "HQ-SVN$" to correspond with the NetBIOS name of the host. I have not seen the percent sign in these contexts. I would like to know more details about the "AD server giving back more than one answer" situation. How did you determine this, and what different answers was it giving back? > Once we had figured that out, the next step was to try again. Once > again there was an error. In this case the error was "No such file or > directory." with not hint as to what file or directory the thing > might have been looking for. > > In fact, using ltrace didn't help this. I have no idea where it > actually looks up that file name. > > It turns out that it was looking for keytab file. The only reason I > realized that was because I started trying to think of the mechanism, > and how it all worked. Ubuntu 8.04 uses krb5-1.6.3. The recent krb5-1.7 release has many enhancements, which include providing extended error information strings in more places, including in the situation you describe. There is also a patch queued for the upcoming krb5-1.6.4 maintenance release to add that extended error reporting information. > To summarize, the error messages for problems like this *must* say > what exactly is wrong, what resource is wrong or missing, preferably with as > much context as possible. It's not reasonable to hope that ltrace or > strace will give you enough information. It is also not reasonable > for the sys-admin to be expected to run through the entire > installation procedure again. Sys-admin's are harried, and need > shortcuts and complete error messages. Thanks for letting us know. We have been working on improving our error reporting for some time now, mostly by adding extended error information to places where the existing fixed strings provide insufficient information. Having additional reports like yours can help us with that effort. From mdeloera at exacq.com Tue Jun 30 14:29:43 2009 From: mdeloera at exacq.com (Matthew M. DeLoera) Date: Tue, 30 Jun 2009 14:29:43 -0400 Subject: AcceptSecurityContext (SSPI) fails with SEC_E_LOGON_DENIED anda GSS-API Linux client In-Reply-To: References: <4A424E1D.9000906@exacq.com> <4A4267F9.1070704@exacq.com> <4A426E15.1090703@exacq.com> Message-ID: <4A4A5997.3090406@exacq.com> Just a quick note of thanks to everyone who responded (especially Paul and Sam!!). I've been on a customer issue, so only just got the chance to read their responses and apply that information to my problem. I now seem to be up and running beautifully. I'm running 2 WinXP virtual machines, one freshly configured for my AD server, and the other freshly configured for my Linux MIT krb5-kdc. Each one authenticates nicely in conjunction with my test client. I appreciate the help to get me out of my hole. Thanks again! - Matthew DeLoera