From hartmans at MIT.EDU Mon Mar 2 14:35:29 2009 From: hartmans at MIT.EDU (Sam Hartman) Date: Mon, 02 Mar 2009 14:35:29 -0500 Subject: KDC modifications for FAST Message-ID: Please see the KDC modifications section of the FAST project for some background. FAST requires that we extend the KDC pre-authentication requests to handle some additional state. In particular, two items seem to affect a lot. * pre-authentication mechanisms and other parts of the KDC need to be able to p get access to FAST state such as the armor key. * FAST changes how error handling works. FAST says that the e_data field in a krb-error always contains a sequence of padata. It contains rules for dealing with typed data. Doing this in the KDC code proper is reasonably easy. However, doing it is more difficult for the pre-authentication plugins. The pre-authentication plugin interface has a get_data_entry procedure that given a type can look up some data and return it. The goal is to avoid exposing too much internal structure to the plugins. This would be ideal for getting the FAST state, except that it only takes the kdc_req and the db_entry as arguments. There are a few possibilities for fixing that I discussed on jabber: * extending kdc_req * adding something to krb5_context and requiring that the context given to the preauth plugin be used * a new plugin interface. In addition, the current plugin interface assumes that plugins return e_data to be included in errors in the verify_preauth stage. Unfortunately, with FAST, we need to include the fast padata itself, and we also assume we're going to be generating a pdata sequence. So, we really want a sequence of padata out of the plugins, not a single e_data. As it turns out, that e_data will always be a sequence of padata or a sequence of typed-data in our code and the plugins/errors I'm aware of. I was considering designing a new plugin interface that: * took a void * to give to the get_data procedure (as is done on the client) * Returned a set of padata for inclusion in errors, possibly along with an indication as to whether they should be encoded as padata or typed data if FAST is not being used. However there are a couple of issues with doing that. There are some tricky design issues around the error return, and the plugin are interface doesn't provide a good way to support multiple versions. If you have a v1 and a v2 symbol table, there is no way of saying that you want the v2 symbol table if available, otherwise the v1 symbol table. So, instead I propose to do something simpler: * add an internal_state pointer to krb5_kdc_req. It's a krb5.h structure, but we've already extended it for krb5 1.7. There are no public APIs that take or return it. * Attempt to decode the returned e_data from the plugin as either a typed-data or padata sequence and if successful re-encode as legacy. Note that this will be required for legacy plugin support even if we do a new interface. I believe that taking these steps allows me to move forward, does not produce significantly more ugly code than otherwise might result, and avoids boiling oceans. Comments welcome. --Sam From ghudson at MIT.EDU Wed Mar 4 19:56:48 2009 From: ghudson at MIT.EDU (ghudson@MIT.EDU) Date: Wed, 4 Mar 2009 19:56:48 -0500 (EST) Subject: Preliminary discussion: DB alias entries Message-ID: <200903050056.n250umZq006351@outgoing.mit.edu> I've been asked to at least try to implement alias entries in the shipped KDB back ends for the 1.7 release. The main use case I have in mind for this work is servers with more than one name (which we currently tend to handle on the client through DNS canonicalization, which is awful). I am not looking into case-folding for this project, as we have very limited time and there are some design issues there. I'm currently planning to add support to the LDAP back end as well as the DB2 back end for feature parity, but I don't yet understand that code well enough to understand the design alternatives. This message will focus on the DB2 back end. I've looked into three basic options for adding alias entries to the DB2 back end: 1. Store the same entry data with multiple keys: principalname -> { info, principalname, tl_data, key_data } aliasname -> { info, principalname, tl_data, key_data } This is sort of elegant in that it doesn't modify the DB schema and doesn't require any changes to the lookup path, but it introduces consistency issues--if you change the password of the principal, the aliases don't get updated. 2. Define a magic type of principal entry marked by a len value of 0 or some other magic value. Unfortunately, the existing <1.7 parsing code does not check the length field until it is done decoding all of the integer fields of the entry (it does check the length of the value blob, so there's no input buffer overrun), so it wouldn't fail very gracefully on seeing an alias entry. 3. Define a magic type of principal entry structured as a current principal entry, but with most of the integer fields being 0, no key data, and with a single piece of tl_data giving the canonical name of the principal. Option #3 seems the most practical. krb5_db2_db_get_principal would check the result for the tl_data canonical name field, and would follow the link. Comments on this so far? I'll be fleshing this all out into a detailed project proposal over the next couple of days. From lha at kth.se Wed Mar 4 20:47:47 2009 From: lha at kth.se (=?utf-8?Q?Love_H=C3=B6rnquist_=C3=85strand?=) Date: Wed, 4 Mar 2009 17:47:47 -0800 Subject: Preliminary discussion: DB alias entries In-Reply-To: <200903050056.n250umZq006351@outgoing.mit.edu> References: <200903050056.n250umZq006351@outgoing.mit.edu> Message-ID: <23757EC5-C803-4128-AFA6-ED71AA809774@kth.se> Put alias key in namespace that normal key not is in, no collisions then with old codebase. make alias data an indirection to real entry Skickat fr?n min iPhone 4 mar 2009 kl. 16.56 skrev "ghudson at mit.edu" : > I've been asked to at least try to implement alias entries in the > shipped KDB back ends for the 1.7 release. > > The main use case I have in mind for this work is servers with more > than one name (which we currently tend to handle on the client through > DNS canonicalization, which is awful). I am not looking into > case-folding for this project, as we have very limited time and there > are some design issues there. > > I'm currently planning to add support to the LDAP back end as well as > the DB2 back end for feature parity, but I don't yet understand that > code well enough to understand the design alternatives. This message > will focus on the DB2 back end. > > I've looked into three basic options for adding alias entries to the > DB2 back end: > > 1. Store the same entry data with multiple keys: > > principalname -> { info, principalname, tl_data, key_data } > aliasname -> { info, principalname, tl_data, key_data } > > This is sort of elegant in that it doesn't modify the DB schema and > doesn't require any changes to the lookup path, but it introduces > consistency issues--if you change the password of the principal, > the aliases don't get updated. > > 2. Define a magic type of principal entry marked by a len value of 0 > or some other magic value. Unfortunately, the existing <1.7 > parsing code does not check the length field until it is done > decoding all of the integer fields of the entry (it does check the > length of the value blob, so there's no input buffer overrun), so > it wouldn't fail very gracefully on seeing an alias entry. > > 3. Define a magic type of principal entry structured as a current > principal entry, but with most of the integer fields being 0, no > key data, and with a single piece of tl_data giving the canonical > name of the principal. > > Option #3 seems the most practical. krb5_db2_db_get_principal would > check the result for the tl_data canonical name field, and would > follow the link. > > Comments on this so far? I'll be fleshing this all out into a > detailed project proposal over the next couple of days. > _______________________________________________ > krbdev mailing list krbdev at mit.edu > https://mailman.mit.edu/mailman/listinfo/krbdev From lukeh at padl.com Wed Mar 4 21:44:41 2009 From: lukeh at padl.com (Luke Howard) Date: Thu, 5 Mar 2009 13:44:41 +1100 Subject: Preliminary discussion: DB alias entries In-Reply-To: <200903050056.n250umZq006351@outgoing.mit.edu> References: <200903050056.n250umZq006351@outgoing.mit.edu> Message-ID: > I'm currently planning to add support to the LDAP back end as well as > the DB2 back end for feature parity, but I don't yet understand that > code well enough to understand the design alternatives. This message > will focus on the DB2 back end. For the LDAP code, the simplest approach might be to add a canonical principal name attribute. Which reminds me, the following usage of strcaescmp() in krb5_ldap_get_principal() is somewhat dubious: /* a wild-card in a principal name can return a list of kerberos principals. * Make sure that the correct principal is returned. * NOTE: a principalname k* in ldap server will return all the principals starting with a k */ for (i=0; values[i] != NULL; ++i) { if (strcasecmp(values[i], user) == 0) { *nentries = 1; break; } } > 1. Store the same entry data with multiple keys: > > principalname -> { info, principalname, tl_data, key_data } > aliasname -> { info, principalname, tl_data, key_data } > > This is sort of elegant in that it doesn't modify the DB schema and > doesn't require any changes to the lookup path, but it introduces > consistency issues--if you change the password of the principal, > the aliases don't get updated. Could you have absent key data (or a magic value indicating it was an alias). > 3. Define a magic type of principal entry structured as a current > principal entry, but with most of the integer fields being 0, no > key data, and with a single piece of tl_data giving the canonical > name of the principal. Well, there you go. :) -- Luke From ghudson at MIT.EDU Wed Mar 4 23:29:26 2009 From: ghudson at MIT.EDU (Greg Hudson) Date: Wed, 04 Mar 2009 23:29:26 -0500 Subject: Preliminary discussion: DB alias entries In-Reply-To: <23757EC5-C803-4128-AFA6-ED71AA809774@kth.se> References: <200903050056.n250umZq006351@outgoing.mit.edu> <23757EC5-C803-4128-AFA6-ED71AA809774@kth.se> Message-ID: <1236227366.7413.65.camel@ray> On Wed, 2009-03-04 at 17:47 -0800, Love H?rnquist ?strand wrote: > Put alias key in namespace that normal key not is in, no collisions > then with old codebase. make alias data an indirection to real entry I thought about that, but that adds an extra lookup in some cases. (Either two lookups all the time, or three lookups for an aliased name, depending on the implementation.) It is in some ways more elegant, though. I'll think on it more carefully. From ssorce at redhat.com Thu Mar 5 00:04:38 2009 From: ssorce at redhat.com (Simo Sorce) Date: Thu, 05 Mar 2009 00:04:38 -0500 Subject: Preliminary discussion: DB alias entries In-Reply-To: <200903050056.n250umZq006351@outgoing.mit.edu> References: <200903050056.n250umZq006351@outgoing.mit.edu> Message-ID: <1236229479.19057.19.camel@localhost.localdomain> On Wed, 2009-03-04 at 19:56 -0500, ghudson at MIT.EDU wrote: > > I'm currently planning to add support to the LDAP back end as well as > the DB2 back end for feature parity, but I don't yet understand that > code well enough to understand the design alternatives. This message > will focus on the DB2 back end. For the LDAP case all you need to do is to either just use krbPrincipalName as a multivalued attribute (although that means you will loose sight of waht was the "original" name). Or just add a multivalued attribute for all aliases (with it's auxiliary objectclass) and treat krbPrincipalName as the "real" name. In either cases you will need a single lookup, and the modification to the backend would be trivial. Simo. -- Simo Sorce * Red Hat, Inc * New York From hartmans at MIT.EDU Thu Mar 5 10:04:16 2009 From: hartmans at MIT.EDU (Sam Hartman) Date: Thu, 05 Mar 2009 10:04:16 -0500 Subject: Preliminary discussion: DB alias entries In-Reply-To: <200903050056.n250umZq006351@outgoing.mit.edu> (ghudson@MIT.EDU's message of "Wed, 4 Mar 2009 19:56:48 -0500 (EST)") References: <200903050056.n250umZq006351@outgoing.mit.edu> Message-ID: Greg, if you do something like what you are talking about, I think Love's approach is the best: a separate key space for aliases. I understand there will be multiple lookups but I think that's OK. However, I'd like to ask you to think about whether adding alias support to db2 done this way makes any sense at all. If you have a major sponsor who really wants aliases in db2 manipulated through kadm5, then by all means go forward. What you are proposing is not harmful; it just seems like something that very few people will find useful and thus is likely to be an inefficient use of the consortium's time. Here's why I say that. If you go back to _The Role of Kerberos in Modern Information Systems_, you find that your target customers use Kerberos as part of larger infrastructure. Your customers typically are not manipulating the kdb by hand, they are using tools to do that. They want Kerberos to play well with their existing other infrastructure--whether it is infrastructure that maintains DNS, DHCP, user accounts, whatever. In each of the case studies examined in that paper, Kerberos was used along side other systems. So, if the problem you are trying to solve is better host name canonicalization, requiring the admin to use kadmin to manipulate your database seems like a poor approach. I'd instead pick some way to make host aliases available to the KDC, within the db2 backend, but independent of the existing KDB. I might consider things like * a second db2 database (Love's approach) along with a tool to load this from a DNS zone file * an sqllite database along with example scripts to load from a zone file * Look the alias info (and alias info only) up in LDAP My point though is that I think it makes sense to separate the alias information from the other parts of the system, to focus on infrastructure integration rather than on hand aliases, and to understand that people will be adapting your solution to a lot of different infrastructures. Based on the feedback in the paper, I suspect that concrete instantiations of a solution would be better than a well designed plugin interface, although I'd certainly have making this pluggable in the back of my head even though I doubt you have time to pull that off for 1.7. From hartmans at MIT.EDU Thu Mar 5 10:51:34 2009 From: hartmans at MIT.EDU (Sam Hartman) Date: Thu, 05 Mar 2009 10:51:34 -0500 Subject: FAST error handling and our plugin interface Message-ID: I need review on this, or at least I need people who don't raise objections very soon to not raise objections later:-) I've described the general issue on the ietf list, but I need to discuss the implications for our code base. Briefly, FAST changes how errors are handled at a protocol level. Today, most errors have an unspecified e_data field that has an untyped octet string. Some errors tell you what goes there, but most do not. So, with most errors you cannot interoperably exchange information there. One error (PREAUTH_REQUIRED) is specified to contain a sequence of padata in that space. Another error (PREAUTH_FAILED) traditionally also contains padata in the Microsoft implementation. Luke's changes also cause us to include padata in that error. Some pkinit errors contain something called typed-data which is basically similar to padata except that the encoding is different. One key thing to understand is that both in the PREAUTH_REQUIRED and PREAUTH_FAILED error, the padata contained with the error roughly are a list of pre-authentication mechanisms you should try next. So, the code in preauth2.c interprets PREAUTH_REQUIRED and pulls out the padata from the e_data and uses it to update the methods to try. However for other errors, it simply calls the tryagain function and passes in the e_data. FAST changes the handling of all errors. They all return padata in the e_data field. However only the preauth_required and preauth_failed errors use padata to drive what mechanisms a client should use. So, the ideal fast interface would pass two sets of padata into the preauth2.c loop. It would pass a set of driving padata from hints or from preauth_required along with a set of padata from the current error. The loop would make the set of padata available from the current error to all pre-auth plugins, not just the padata corresponding to the current plugin. However we don't have that plugin interface today and it is desirable to keep things working with the current plugins. So, my plan for the current interface is to continue doing what we're doing in the non-FAST case. In the FAST case, I plan to take the padata , re-encode as typed-data and pass that into the plugins as the e_data field. That is ugly, but will work with all the existing plugins. Things are correspondingly messy on the KDC side, although I have discussed that via jabber. From jaltman at secure-endpoints.com Thu Mar 5 11:25:01 2009 From: jaltman at secure-endpoints.com (Jeffrey Altman) Date: Thu, 05 Mar 2009 11:25:01 -0500 Subject: FAST error handling and our plugin interface In-Reply-To: References: Message-ID: <49AFFCDD.7030301@secure-endpoints.com> Sam Hartman wrote: > However we don't have that plugin interface today and it is desirable > to keep things working with the current plugins. So, my plan for the > current interface is to continue doing what we're doing in the > non-FAST case. For clarity sake, just how many plugins are we talking about? When the plugin interface was being designed we knew that it was not a complete interface and it was exposed with the expectation that things might have to change in the future. My failing to pass in the two separate sets of padata to the plugins, each plugin is going to have to replicate the logic to separate the hints from the actual error data. I agree with you. The hack of re-encoding the pa-data as typed-data so that the existing plug-ins can accept it in the e_data field is ugly and potentially confusing to future implementers. If we believe that we know most of the plug-in authors, then I would advise to revise the plug-in interface to make life easier for everyone going forward. The old interface should be recognized and either have a "deprecated" error returned to them or perhaps take the code that you were going to use to translate the padata to the typed-data and instead of using it everywhere, just use it as a wrapper to provide data to plug-ins that support the old interface. Documentation describing how to convert a plug-in from the old interface to the new interface could be written including how to detect at compile time which interface is available so that the plug-in can be built appropriately. I'm not going to be putting any resources behind any of this so feel free to toss this e-mail into the trash and forget it was ever written. Just my $0.00 cents. Jeffrey Altman -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3355 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.mit.edu/pipermail/krbdev/attachments/20090305/f75f3ea2/smime-0001.bin From ssorce at redhat.com Thu Mar 5 11:48:04 2009 From: ssorce at redhat.com (Simo Sorce) Date: Thu, 05 Mar 2009 11:48:04 -0500 Subject: Preliminary discussion: DB alias entries In-Reply-To: References: <200903050056.n250umZq006351@outgoing.mit.edu> Message-ID: <1236271684.6848.10.camel@localhost.localdomain> On Thu, 2009-03-05 at 10:04 -0500, Sam Hartman wrote: > > My point though is that I think it makes sense to separate the alias > information from the other parts of the system, to focus on > infrastructure integration rather than on hand aliases, and to > understand that people will be adapting your solution to a lot of > different infrastructures. Based on the feedback in the paper, I > suspect that concrete instantiations of a solution would be better > than a well designed plugin interface, although I'd certainly have > making this pluggable in the back of my head even though I doubt you > have time to pull that off for 1.7. Sam I totally agree on this proposal, a separate interface would be awesome esp. if it can be used for referrals too. Simo. -- Simo Sorce * Red Hat, Inc * New York From hartmans at MIT.EDU Thu Mar 5 11:50:54 2009 From: hartmans at MIT.EDU (Sam Hartman) Date: Thu, 05 Mar 2009 11:50:54 -0500 Subject: FAST error handling and our plugin interface In-Reply-To: <49AFFCDD.7030301@secure-endpoints.com> (Jeffrey Altman's message of "Thu, 05 Mar 2009 11:25:01 -0500") References: <49AFFCDD.7030301@secure-endpoints.com> Message-ID: >>>>> "Jeffrey" == Jeffrey Altman writes: Jeffrey> Sam Hartman wrote: >> However we don't have that plugin interface today and it is >> desirable to keep things working with the current plugins. So, >> my plan for the current interface is to continue doing what >> we're doing in the non-FAST case. Jeffrey> For clarity sake, just how many plugins are we talking Jeffrey> about? I don't know. I know of two companies that would be affected with shipping products that it would be difficult for me to change, and suspect others. I do agree a new plugin interface should be designed, especially for mechanisms that are actually FAST factors. Jeffrey> My failing to pass in the two separate sets of padata to Jeffrey> the plugins, each plugin is going to have to replicate Jeffrey> the logic to separate the hints from the actual error Jeffrey> data. Jeffrey> I agree with you. The hack of re-encoding the pa-data as Jeffrey> typed-data so that the existing plug-ins can accept it in Jeffrey> the e_data field is ugly and potentially confusing to Jeffrey> future implementers. Note that some hack like this is actually much easier for pkinit authors, which are the primary consumer of the tryagain interface today. If I'm getting an error from a non-FAST KDC, I don't know what the e_data field is encoded as. So, I have to pass it directly to the plugin. If I re-encode padata as typed-data, then a pkinit plugin can always look at the e_data field as a sequence of typed data both in the FAST and non-FAST case. An obvious question that comes up at this point is whether FAST is right to change the encoding of errors. I think so, because I think normalizing that and removing the typed-data vs padata vs other things confusion is good. However there is a consensus call open on that issue over in the IETF right now. You might argue that this uglyness is worse than normalizing the errors at all. From ghudson at MIT.EDU Thu Mar 5 12:27:07 2009 From: ghudson at MIT.EDU (Greg Hudson) Date: Thu, 05 Mar 2009 12:27:07 -0500 Subject: Preliminary discussion: DB alias entries In-Reply-To: References: <200903050056.n250umZq006351@outgoing.mit.edu> Message-ID: <1236274027.7413.80.camel@ray> Sam proposes separating the alias database from the principal database to facilitate integration. If we go that route for DB2--say, using a second DB2 database for aliases--how do people think LDAP aliases should be handled? Perhaps a separate container DN for aliases? From Nicolas.Williams at sun.com Thu Mar 5 12:23:13 2009 From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Thu, 5 Mar 2009 11:23:13 -0600 Subject: Preliminary discussion: DB alias entries In-Reply-To: References: <200903050056.n250umZq006351@outgoing.mit.edu> Message-ID: <20090305172313.GK9992@Sun.COM> On Thu, Mar 05, 2009 at 10:04:16AM -0500, Sam Hartman wrote: > Greg, if you do something like what you are talking about, I think > Love's approach is the best: a separate key space for aliases. I > understand there will be multiple lookups but I think that's OK. I agree. Multiple lookups are not an issue unless they can block a single-threaded KDC (e.g., imagine using DNS lookups here). > However, I'd like to ask you to think about whether adding alias > support to db2 done this way makes any sense at all. If you have a > major sponsor who really wants aliases in db2 manipulated through > kadm5, then by all means go forward. What you are proposing is not > harmful; it just seems like something that very few people will find > useful and thus is likely to be an inefficient use of the consortium's > time. Here's why I say that. Storing aliases in the KDB is almost certain to lead to double entry procedures for hostname aliases. Like Sam I'm not sure that's a good idea -- it's OK as an option, but not OK as the only option unless... ...there's a process for synchronizing alias information in the KDB with a customer's primary source (or DNS, but handled securely). In other words, I'm arguing for any reasonable variant of Sam's "SQLite3 DB loaded from DNS zone files" option, including that option too. Using the LDAP backend doesn't seem like a great idea because it's likely in some cases that the LDAP backend's DIT will be separate from the primary DIT for the realm, in which case we're back to double entry or synchronization, and even if the backend is using the realm's DIT we still have the problem that full host and aliasing data might not be present in it. The one common denominator is that almost every environment using Kerberos V also uses DNS. So I think we're looking for any reasonable variant of Sam's "SQLite3 DB loaded from DNS zone files" or any solution using DNS securely: * Look in specific DNS domainnames using a _local_ nameserver. Don't use recursive queries, don't follow delegations, ... If the canonical name of an alias is not found immediately, then stop looking. A KDC admin can probably arrange to replicate DNS data to a server private to the KDC. I don't terribly love this -- it's exactly what I would want in terms of avoiding double entry and in terms of how easy it is to arrange this, but in so far as one could misconfigure the system to do the lookups on a public, caching server, it scares me. * Have the KDC do DNS zone transfers (secured somehow) of relevant zones (the base domainnames can be determined from the contents of the KDB) and then load them in a DB. * Use DNSSEC (and multi-thread krb5kdc or re-factor it to be async, and since the standard resolver APIs are not async, do the DNS lookups in worker threads). Nico -- From hartmans at MIT.EDU Thu Mar 5 12:49:16 2009 From: hartmans at MIT.EDU (Sam Hartman) Date: Thu, 05 Mar 2009 12:49:16 -0500 Subject: Preliminary discussion: DB alias entries In-Reply-To: <1236274027.7413.80.camel@ray> (Greg Hudson's message of "Thu, 05 Mar 2009 12:27:07 -0500") References: <200903050056.n250umZq006351@outgoing.mit.edu> <1236274027.7413.80.camel@ray> Message-ID: >>>>> "Greg" == Greg Hudson writes: Greg> Sam proposes separating the alias database from the Greg> principal database to facilitate integration. I meant only within the db2 backend. Greg> If we go that route for DB2--say, using a second DB2 Greg> database for aliases--how do people think LDAP aliases Greg> should be handled? Perhaps a separate container DN for Greg> aliases? I think that as several people have proposed an additional multi-valued attribute will be appropriate. In a lot of places I think it will be reasonable for this attribute to live in the same object. The basic argument is that if your infrastructure is ldap based, you probably have facilities for populating this sort of thing. I think that long term you may need more flexibility, but a multi-valued attribute seems like a good starting point. I'm not sure that a separate container DN would be more valuable and it seems like a lot more work in cases where a multi-valued attribute would work. From Nicolas.Williams at sun.com Thu Mar 5 12:33:50 2009 From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Thu, 5 Mar 2009 11:33:50 -0600 Subject: Preliminary discussion: DB alias entries In-Reply-To: <1236274027.7413.80.camel@ray> References: <200903050056.n250umZq006351@outgoing.mit.edu> <1236274027.7413.80.camel@ray> Message-ID: <20090305173350.GN9992@Sun.COM> On Thu, Mar 05, 2009 at 12:27:07PM -0500, Greg Hudson wrote: > Sam proposes separating the alias database from the principal database > to facilitate integration. See my follow-up to Sam's post. > If we go that route for DB2--say, using a second DB2 database for > aliases--how do people think LDAP aliases should be handled? Perhaps a > separate container DN for aliases? I'd certainly like the _option_ to be able to use the LDAP krb5 schema as an extension of the RFC2307bis+ schema. From jaltman at secure-endpoints.com Thu Mar 5 13:23:20 2009 From: jaltman at secure-endpoints.com (Jeffrey Altman) Date: Thu, 05 Mar 2009 13:23:20 -0500 Subject: FAST error handling and our plugin interface In-Reply-To: References: <49AFFCDD.7030301@secure-endpoints.com> Message-ID: <49B01898.1070304@secure-endpoints.com> Sam Hartman wrote: >>>>>> "Jeffrey" == Jeffrey Altman writes: > > Jeffrey> Sam Hartman wrote: > >> However we don't have that plugin interface today and it is > >> desirable to keep things working with the current plugins. So, > >> my plan for the current interface is to continue doing what > >> we're doing in the non-FAST case. > > Jeffrey> For clarity sake, just how many plugins are we talking > Jeffrey> about? > > I don't know. I know of two companies that would be affected with > shipping products that it would be difficult for me to change, and > suspect others. These vendors are not going to replace 1.6.x with 1.7.x in their already shipping versions. 1.7.x will go into a new major release and the work necessary to update the plug-ins for the new interface should not be significant. I would be more concerned about organizations that have developed their own plug-ins that were distributed on a wide scale. I'm not aware of any on the client side and for the KDC, updating the plug-ins when rolling out a new KDC platform is not such a big deal either. Jeffrey Altman From ssorce at redhat.com Thu Mar 5 13:38:29 2009 From: ssorce at redhat.com (Simo Sorce) Date: Thu, 05 Mar 2009 13:38:29 -0500 Subject: Preliminary discussion: DB alias entries In-Reply-To: <1236274027.7413.80.camel@ray> References: <200903050056.n250umZq006351@outgoing.mit.edu> <1236274027.7413.80.camel@ray> Message-ID: <1236278309.6848.18.camel@localhost.localdomain> On Thu, 2009-03-05 at 12:27 -0500, Greg Hudson wrote: > Sam proposes separating the alias database from the principal database > to facilitate integration. > > If we go that route for DB2--say, using a second DB2 database for > aliases--how do people think LDAP aliases should be handled? Perhaps a > separate container DN for aliases? No please, separate interfaces does not mean you have to have separate objects, you rather want to keep all information in one object so that it is consistent. Simo. -- Simo Sorce * Red Hat, Inc * New York From hartmans at MIT.EDU Thu Mar 5 13:42:21 2009 From: hartmans at MIT.EDU (Sam Hartman) Date: Thu, 05 Mar 2009 13:42:21 -0500 Subject: Preliminary discussion: DB alias entries In-Reply-To: <1236278309.6848.18.camel@localhost.localdomain> (Simo Sorce's message of "Thu, 05 Mar 2009 13:38:29 -0500") References: <200903050056.n250umZq006351@outgoing.mit.edu> <1236274027.7413.80.camel@ray> <1236278309.6848.18.camel@localhost.localdomain> Message-ID: >>>>> "Simo" == Simo Sorce writes: Simo> On Thu, 2009-03-05 at 12:27 -0500, Greg Hudson wrote: >> Sam proposes separating the alias database from the principal >> database to facilitate integration. >> >> If we go that route for DB2--say, using a second DB2 database >> for aliases--how do people think LDAP aliases should be >> handled? Perhaps a separate container DN for aliases? Simo> No please, separate interfaces does not mean you have to Simo> have separate objects, you rather want to keep all Simo> information in one object so that it is consistent. I think for db2 separate interfaces basically does mean separate objects. From hartmans at MIT.EDU Thu Mar 5 13:48:56 2009 From: hartmans at MIT.EDU (Sam Hartman) Date: Thu, 05 Mar 2009 13:48:56 -0500 Subject: FAST error handling and our plugin interface In-Reply-To: <49B01898.1070304@secure-endpoints.com> (Jeffrey Altman's message of "Thu, 05 Mar 2009 13:23:20 -0500") References: <49AFFCDD.7030301@secure-endpoints.com> <49B01898.1070304@secure-endpoints.com> Message-ID: >>>>> "Jeffrey" == Jeffrey Altman writes: Jeffrey> Sam Hartman wrote: >>>>>>> "Jeffrey" == Jeffrey Altman >>>>>>> writes: >> Jeffrey> Sam Hartman wrote: >> >> However we don't have that plugin interface today and it is >> >> desirable to keep things working with the current plugins. >> So, >> my plan for the current interface is to continue doing >> what >> we're doing in the non-FAST case. >> Jeffrey> For clarity sake, just how many plugins are we talking Jeffrey> about? >> I don't know. I know of two companies that would be affected >> with shipping products that it would be difficult for me to >> change, and suspect others. Jeffrey> These vendors are not going to replace 1.6.x with 1.7.x Jeffrey> in their already shipping versions. 1.7.x will go into a Jeffrey> new major release and the work necessary to update the Jeffrey> plug-ins for the new interface should not be significant. I disagree with you about the compatibility model we should work to achieve. I think it is desirable to make upgrading to a new krb5 release very easy for vendors. If there were a compelling cleanlyness you could get by breaking the old interface, I'd agree. However I suspect at least one vendor would end up shipping both interfaces, and as I mentioned in my first reply to you I think some similar uglyness is inherent in needing to support both old and new format errors. I do think that we need to come up with the new interface though. And if we come up with a particularly clean interface for the new plugins I think it might be desirable to make a clean break. --Sam From tsitkova at MIT.EDU Thu Mar 5 13:56:38 2009 From: tsitkova at MIT.EDU (Zhanna Tsitkova) Date: Thu, 5 Mar 2009 13:56:38 -0500 Subject: Preliminary discussion: DB alias entries In-Reply-To: References: <200903050056.n250umZq006351@outgoing.mit.edu> <1236274027.7413.80.camel@ray> Message-ID: <7A0C937B-293B-4C92-9613-085367167296@mit.edu> How about adding a new auxulary attr to the entries - for example 1.3.18.0.2.4.1154 NAME ( 'krbHintAliases' ) or just krbAliases as defined in http://publib.boulder.ibm.com/infocenter/zvm/v5r3/index.jsp?topic=/com.ibm.zvm.v53.kldl0/tivap02998897.htm In fact , on KDC startup these aliases could be stored in memory. Then, when the request comes in, the normalized string would be searched in the mem cache and then decided if the further processing is needed. Thanks, Zhanna >>>>>> "Greg" == Greg Hudson writes: > > Greg> Sam proposes separating the alias database from the > Greg> principal database to facilitate integration. > I meant only within the db2 backend. > > Greg> If we go that route for DB2--say, using a second DB2 > Greg> database for aliases--how do people think LDAP aliases > Greg> should be handled? Perhaps a separate container DN for > Greg> aliases? > > I think that as several people have proposed an additional > multi-valued attribute will be appropriate. In a lot of places I > think it will be reasonable for this attribute to live in the same > object. The basic argument is that if your infrastructure is ldap > based, you probably have facilities for populating this sort of thing. > I think that long term you may need more flexibility, but a > multi-valued attribute seems like a good starting point. I'm not sure > that a separate container DN would be more valuable and it seems like > a lot more work in cases where a multi-valued attribute would work. > > _______________________________________________ > krbdev mailing list krbdev at mit.edu > https://mailman.mit.edu/mailman/listinfo/krbdev From ssorce at redhat.com Thu Mar 5 13:59:34 2009 From: ssorce at redhat.com (Simo Sorce) Date: Thu, 05 Mar 2009 13:59:34 -0500 Subject: Preliminary discussion: DB alias entries In-Reply-To: References: <200903050056.n250umZq006351@outgoing.mit.edu> <1236274027.7413.80.camel@ray> <1236278309.6848.18.camel@localhost.localdomain> Message-ID: <1236279574.6848.22.camel@localhost.localdomain> On Thu, 2009-03-05 at 13:42 -0500, Sam Hartman wrote: > >>>>> "Simo" == Simo Sorce writes: > > Simo> On Thu, 2009-03-05 at 12:27 -0500, Greg Hudson wrote: > >> Sam proposes separating the alias database from the principal > >> database to facilitate integration. > >> > >> If we go that route for DB2--say, using a second DB2 database > >> for aliases--how do people think LDAP aliases should be > >> handled? Perhaps a separate container DN for aliases? > > Simo> No please, separate interfaces does not mean you have to > Simo> have separate objects, you rather want to keep all > Simo> information in one object so that it is consistent. > > I think for db2 separate interfaces basically does mean separate > objects. I guess it depends on how the backend is implemented. I agree that for db2 it might be the case, but for LDAP it does not have to. Simo. -- Simo Sorce * Red Hat, Inc * New York From hartmans at MIT.EDU Thu Mar 5 14:23:34 2009 From: hartmans at MIT.EDU (Sam Hartman) Date: Thu, 05 Mar 2009 14:23:34 -0500 Subject: Preliminary discussion: DB alias entries In-Reply-To: <1236279574.6848.22.camel@localhost.localdomain> (Simo Sorce's message of "Thu, 05 Mar 2009 13:59:34 -0500") References: <200903050056.n250umZq006351@outgoing.mit.edu> <1236274027.7413.80.camel@ray> <1236278309.6848.18.camel@localhost.localdomain> <1236279574.6848.22.camel@localhost.localdomain> Message-ID: >>>>> "Simo" == Simo Sorce writes: Simo> I guess it depends on how the backend is implemented. I Simo> agree that for db2 it might be the case, but for LDAP it Simo> does not have to. Agreed! For LDAP it does not have to. From ghudson at MIT.EDU Thu Mar 5 17:39:23 2009 From: ghudson at MIT.EDU (Greg Hudson) Date: Thu, 05 Mar 2009 17:39:23 -0500 Subject: Preliminary discussion: DB alias entries In-Reply-To: <200903050056.n250umZq006351@outgoing.mit.edu> References: <200903050056.n250umZq006351@outgoing.mit.edu> Message-ID: <1236292763.7413.87.camel@ray> Status update on this work: * I will take Love and Sam's suggestion to use a separate namespace (and database file) for DB2 aliases. * Based on the resource situation here, I am trying to cut as many deliverables as possible to be able to implement this for 1.7 without delaying the release. Therefore, the alias database will be read-only from the libkdb db2 plugin's perspective, and aliases will be invisible to delete/iterate. The expectation is that most users will generate and synchronize the alias database from an external information source. * To ensure that alias database manipulation is scriptable, I may need to provide a short C program to write to kdb2 databases. The operating system's native DB library may not be format-compatible with kdb2 so other options like perl's DB_File may not work. * I expect to provide some kind of sample script, or feature of the short C program, which grabs cname records from a BIND zone file and synchronizes an alias database with them. That should be pretty trivial. * I probably won't be able to implement LDAP alias support for 1.7. Very basic early project proposal at: http://k5wiki.kerberos.org/wiki/Projects/DBAliases From hartmans at MIT.EDU Thu Mar 5 18:43:11 2009 From: hartmans at MIT.EDU (Sam Hartman) Date: Thu, 05 Mar 2009 18:43:11 -0500 Subject: Preliminary discussion: DB alias entries In-Reply-To: <1236292763.7413.87.camel@ray> (Greg Hudson's message of "Thu, 05 Mar 2009 17:39:23 -0500") References: <200903050056.n250umZq006351@outgoing.mit.edu> <1236292763.7413.87.camel@ray> Message-ID: >>>>> "Greg" == Greg Hudson writes: Greg> * I probably won't be able to implement LDAP alias support Greg> for 1.7. I think that LDAP alias support is more important than db2. Personally if I had to pick one it would be LDAP. However I understand you may have different constraints. OTOH, if I'm understanding the LDAP issues that should be a very simple patch. Is there any chance we could get someone not at MIT to agree to contribute it? From smurca at googlemail.com Fri Mar 6 14:28:45 2009 From: smurca at googlemail.com (Marcus Granado) Date: Fri, 6 Mar 2009 19:28:45 +0000 Subject: segfault in spnego_mech.c Message-ID: <7a83c8e0903061128s346bd633t3f1ed0de1f43ae8e@mail.gmail.com> Hi, I think there's a bug in spnego_mech.c leading to a segfault. The line numbers here are relative to the release 20899 at http://src.mit.edu/fisheye/browse/krb5/branches/mskrb-integ/src/lib/gssapi/spnego/spnego_mech.c?r=20899(the latest revision of this file in trunk, I believe: http://src.mit.edu/fisheye/browse/krb5/branches/mskrb-integ/src/lib/gssapi/spnego/spnego_mech.c ). A quick description of the problem: The function acc_ctx_new()@919 can fail with 3 possibilities in the return_token parameter: {INIT_TOKEN_SEND,NO_TOKEN_SEND,ERROR_TOKEN_SEND}. Now, the function spnego_gss_accept_sec_context()@1199 calls acc_ctx_new() at line 1248. If ret != GSS_S_COMPLETE, it goesto cleanup at 1291, checking for non-equality of only two possible values in return_token: NO_TOKEN_SEND and CHECK_MIC. If return_token is not any of them, it calls make_spnego_tokenTarg_msg(), dereferencing the NULL pointer sc and triggering a segfault! The pointer sc is not initialized at this point for two reasons: (1) we jumped over its initialization on line 1264 when we wentto cleanup at 1291; and (2) we might be calling gss_accept_sec_context for the first time with an null context_handle. A quick way to test the bug: if the input_token sent to gss_accept_sec_context() is not null, but an empty buffer (i.e. GSS_C_EMPTY_BUFFER instead of GSS_C_NO_BUFFER), line 1257 will call acc_ctx_new() with an empty input_token (len=0) in its buf parameter, and send that to get_negTokenInit()@2032 -> g_verify_token_header()@2802, which will fail with a G_BAD_TOK_HEADER because the size of the input_token is 0, causing acc_ctx_new() to return an ERROR_TOKEN_SEND in return_token. That will cause acc_ctx_new() to fail with a GSS_S_FAILURE and return_token=ERROR_TOKEN_SEND. We'll be sent to cleanup at 1291, and the condition (return_token != NO_TOKEN_SEND && return_token != CHECK_MIC) will be true, calling make_spnego_toeknTarg_msg() with a NULL sc pointer, leading to a crash. Anyone else able to reproduce that as well? I believe a solution is to improve the condition above at line 1292, including also the possible return_token values INIT_TOKEN_SEND and NO_TOKEN_SEND that can be returned by acc_ctx_new() [btw, I didn't check what acc_ctx_cont() and acc_ctx_call_acc() could return in return_token], but since the algorithm is not trivial, it will take someone knowledgeable in the gssapi spec to assert that. Thanks, Marcus From Nicolas.Williams at sun.com Mon Mar 9 05:49:41 2009 From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Mon, 9 Mar 2009 04:49:41 -0500 Subject: [FWD: Any interest from MIT/Heimdal in implementing draft-ietf-kitten-gssapi-store-cred-04.txt] Message-ID: <20090309094941.GP9992@Sun.COM> ----- Forwarded message from Alexey Melnikov ----- Date: Mon, 09 Mar 2009 09:11:58 +0000 From: Alexey Melnikov Subject: Any interest from MIT/Heimdal in implementing draft-ietf-kitten-gssapi-store-cred-04.txt Folks, I am doing IESG write-up for draft-ietf-kitten-gssapi-store-cred-04.txt and would like to know if anybody other then Sun has implemented or interested in implementing it. Please help! :-) ----- End forwarded message ----- From ghudson at MIT.EDU Mon Mar 9 14:29:46 2009 From: ghudson at MIT.EDU (Greg Hudson) Date: Mon, 09 Mar 2009 14:29:46 -0400 Subject: Preliminary discussion: DB alias entries In-Reply-To: <7A0C937B-293B-4C92-9613-085367167296@mit.edu> References: <200903050056.n250umZq006351@outgoing.mit.edu> <1236274027.7413.80.camel@ray> <7A0C937B-293B-4C92-9613-085367167296@mit.edu> Message-ID: <1236623386.31266.45.camel@ray> On Thu, 2009-03-05 at 13:56 -0500, Zhanna Tsitkova wrote: > How about adding a new auxulary attr to the entries What do you mean by "auxiliary attribute" here? My understanding is that object classes can be auxiliary, but not attributes. (Sorry; I'm new to LDAP so I need people to speak precisely or I can't understand.) > - for example > 1.3.18.0.2.4.1154 NAME ( 'krbHintAliases' ) or just krbAliases as > defined in > http://publib.boulder.ibm.com/infocenter/zvm/v5r3/index.jsp?topic=/com.ibm.zvm.v53.kldl0/tivap02998897.htm What is that page exactly? Is it appropriate to pull attribute and object class definitions from a completely different schema from the Novell one we have? > In fact , on KDC startup these aliases could be stored in memory. > Then, when the request comes in, the normalized string would be > searched in the mem cache and then decided if the further processing > is needed. Wouldn't that introduce consistency issues if the LDAP data is modified outside of the KDC? From ssorce at redhat.com Mon Mar 9 14:53:15 2009 From: ssorce at redhat.com (Simo Sorce) Date: Mon, 09 Mar 2009 14:53:15 -0400 Subject: Preliminary discussion: DB alias entries In-Reply-To: <1236623386.31266.45.camel@ray> References: <200903050056.n250umZq006351@outgoing.mit.edu> <1236274027.7413.80.camel@ray> <7A0C937B-293B-4C92-9613-085367167296@mit.edu> <1236623386.31266.45.camel@ray> Message-ID: <1236624795.3975.24.camel@localhost.localdomain> On Mon, 2009-03-09 at 14:29 -0400, Greg Hudson wrote: > On Thu, 2009-03-05 at 13:56 -0500, Zhanna Tsitkova wrote: > > How about adding a new auxulary attr to the entries > > What do you mean by "auxiliary attribute" here? My understanding is > that object classes can be auxiliary, but not attributes. > > (Sorry; I'm new to LDAP so I need people to speak precisely or I can't > understand.) > > > - for example > > 1.3.18.0.2.4.1154 NAME ( 'krbHintAliases' ) or just krbAliases as > > defined in > > http://publib.boulder.ibm.com/infocenter/zvm/v5r3/index.jsp?topic=/com.ibm.zvm.v53.kldl0/tivap02998897.htm > > What is that page exactly? Is it appropriate to pull attribute and > object class definitions from a completely different schema from the > Novell one we have? If it's not incompatible for some reason, reuse is usually encouraged in the LDAP communities. > > In fact , on KDC startup these aliases could be stored in memory. > > Then, when the request comes in, the normalized string would be > > searched in the mem cache and then decided if the further processing > > is needed. > > Wouldn't that introduce consistency issues if the LDAP data is modified > outside of the KDC? It would, unless the KDC has ways to refresh its cache fetching from LDAP. Simo. -- Simo Sorce * Red Hat, Inc * New York From hartmans at MIT.EDU Mon Mar 9 16:15:10 2009 From: hartmans at MIT.EDU (Sam Hartman) Date: Mon, 09 Mar 2009 16:15:10 -0400 Subject: Preliminary discussion: DB alias entries In-Reply-To: <1236623386.31266.45.camel@ray> (Greg Hudson's message of "Mon, 09 Mar 2009 14:29:46 -0400") References: <200903050056.n250umZq006351@outgoing.mit.edu> <1236274027.7413.80.camel@ray> <7A0C937B-293B-4C92-9613-085367167296@mit.edu> <1236623386.31266.45.camel@ray> Message-ID: I'd feel uncomfortable using an OID from an IBM arc for this. From tsitkova at MIT.EDU Mon Mar 9 16:25:01 2009 From: tsitkova at MIT.EDU (Zhanna Tsitkova) Date: Mon, 9 Mar 2009 16:25:01 -0400 Subject: Preliminary discussion: DB alias entries In-Reply-To: References: <200903050056.n250umZq006351@outgoing.mit.edu> <1236274027.7413.80.camel@ray> <7A0C937B-293B-4C92-9613-085367167296@mit.edu> <1236623386.31266.45.camel@ray> Message-ID: Does MIT Kerb have own OID "prefix" - I mean OID that may be extended for additional attributes? Would you like rather have Novell-based OIDs? Any other suitable "krb-alias"-like attr.? On Mar 9, 2009, at 4:15 PM, Sam Hartman wrote: > I'd feel uncomfortable using an OID from an IBM arc for this. > From hartmans at MIT.EDU Mon Mar 9 16:43:08 2009 From: hartmans at MIT.EDU (Sam Hartman) Date: Mon, 09 Mar 2009 16:43:08 -0400 Subject: Preliminary discussion: DB alias entries In-Reply-To: (Zhanna Tsitkova's message of "Mon, 9 Mar 2009 16:25:01 -0400") References: <200903050056.n250umZq006351@outgoing.mit.edu> <1236274027.7413.80.camel@ray> <7A0C937B-293B-4C92-9613-085367167296@mit.edu> <1236623386.31266.45.camel@ray> Message-ID: >>>>> "Zhanna" == Zhanna Tsitkova writes: Zhanna> Does MIT Kerb have own OID "prefix" - I mean OID that may Zhanna> be extended for additional attributes? Would you like Zhanna> rather have Novell-based OIDs? Any other suitable Yes, we should be able to get OIDs; talk to Tom. A Novell OID would involve coordinating with them. Clearly we should not change existing novell OIDs we're using. From lukeh at padl.com Mon Mar 9 17:29:12 2009 From: lukeh at padl.com (Luke Howard) Date: Tue, 10 Mar 2009 08:29:12 +1100 Subject: Preliminary discussion: DB alias entries In-Reply-To: <1236623386.31266.45.camel@ray> References: <200903050056.n250umZq006351@outgoing.mit.edu> <1236274027.7413.80.camel@ray> <7A0C937B-293B-4C92-9613-085367167296@mit.edu> <1236623386.31266.45.camel@ray> Message-ID: On 10/03/2009, at 5:29 AM, Greg Hudson wrote: > On Thu, 2009-03-05 at 13:56 -0500, Zhanna Tsitkova wrote: >> How about adding a new auxulary attr to the entries > > What do you mean by "auxiliary attribute" here? My understanding is > that object classes can be auxiliary, but not attributes. > > (Sorry; I'm new to LDAP so I need people to speak precisely or I can't > understand.) You are correct. >> - for example >> 1.3.18.0.2.4.1154 NAME ( 'krbHintAliases' ) or just krbAliases as >> defined in >> http://publib.boulder.ibm.com/infocenter/zvm/v5r3/index.jsp?topic=/com.ibm.zvm.v53.kldl0/tivap02998897.htm > > What is that page exactly? Is it appropriate to pull attribute and > object class definitions from a completely different schema from the > Novell one we have? Correct, this is a bad idea. >> In fact , on KDC startup these aliases could be stored in memory. >> Then, when the request comes in, the normalized string would be >> searched in the mem cache and then decided if the further processing >> is needed. > > Wouldn't that introduce consistency issues if the LDAP data is > modified > outside of the KDC? Yes, this is a really bad idea. -- Luke From sbuckley at MIT.EDU Mon Mar 9 17:36:47 2009 From: sbuckley at MIT.EDU (Stephen C. Buckley) Date: Mon, 9 Mar 2009 17:36:47 -0400 Subject: Preliminary discussion: DB alias entries In-Reply-To: References: <200903050056.n250umZq006351@outgoing.mit.edu> <1236274027.7413.80.camel@ray> <7A0C937B-293B-4C92-9613-085367167296@mit.edu> <1236623386.31266.45.camel@ray> Message-ID: <2ED6B9F9-79CC-4C2A-B7CA-4C160BB41505@mit.edu> Luke, Do you know who the right person is at Novell to coordinate? s On Mar 9, 2009, at 4:43 PM, Sam Hartman wrote: >>>>>> "Zhanna" == Zhanna Tsitkova writes: > > Zhanna> Does MIT Kerb have own OID "prefix" - I mean OID that may > Zhanna> be extended for additional attributes? Would you like > Zhanna> rather have Novell-based OIDs? Any other suitable > > Yes, we should be able to get OIDs; talk to Tom. > A Novell OID would involve coordinating with them. > Clearly we should not change existing novell OIDs we're using. > _______________________________________________ > krbdev mailing list krbdev at mit.edu > https://mailman.mit.edu/mailman/listinfo/krbdev From tsitkova at MIT.EDU Mon Mar 9 17:42:05 2009 From: tsitkova at MIT.EDU (Zhanna Tsitkova) Date: Mon, 9 Mar 2009 17:42:05 -0400 Subject: Preliminary discussion: DB alias entries In-Reply-To: <2ED6B9F9-79CC-4C2A-B7CA-4C160BB41505@mit.edu> References: <200903050056.n250umZq006351@outgoing.mit.edu> <1236274027.7413.80.camel@ray> <7A0C937B-293B-4C92-9613-085367167296@mit.edu> <1236623386.31266.45.camel@ray> <2ED6B9F9-79CC-4C2A-B7CA-4C160BB41505@mit.edu> Message-ID: <06610A6E-DCDA-43B7-8B75-6C2B2AFD2ADA@mit.edu> Mark Hinckley was running NDS schema for a long time. Now he is in tech support. On Mar 9, 2009, at 5:36 PM, Stephen C. Buckley wrote: > Luke, > > Do you know who the right person is at Novell to coordinate? > > s > > On Mar 9, 2009, at 4:43 PM, Sam Hartman wrote: > >>>>>>> "Zhanna" == Zhanna Tsitkova writes: >> >> Zhanna> Does MIT Kerb have own OID "prefix" - I mean OID that may >> Zhanna> be extended for additional attributes? Would you like >> Zhanna> rather have Novell-based OIDs? Any other suitable >> >> Yes, we should be able to get OIDs; talk to Tom. >> A Novell OID would involve coordinating with them. >> Clearly we should not change existing novell OIDs we're using. >> _______________________________________________ >> krbdev mailing list krbdev at mit.edu >> https://mailman.mit.edu/mailman/listinfo/krbdev > From tsitkova at MIT.EDU Mon Mar 9 17:46:09 2009 From: tsitkova at MIT.EDU (Zhanna Tsitkova) Date: Mon, 9 Mar 2009 17:46:09 -0400 Subject: Preliminary discussion: DB alias entries In-Reply-To: References: <200903050056.n250umZq006351@outgoing.mit.edu> <1236274027.7413.80.camel@ray> <7A0C937B-293B-4C92-9613-085367167296@mit.edu> <1236623386.31266.45.camel@ray> Message-ID: <16D0028C-A69C-489B-840D-C1B745BEB0B5@mit.edu> I would look for MIT Kerberos own OID number for any attr if we cannot find one among the existing OIDs, created by different vendors. Otherwise, I would reuse the existing and registered one, created by Novell, or Sun, or IBM or anyone else. Of course, we cannot modify vendors OID as they are strictly assigned to the organization. On Mar 9, 2009, at 4:43 PM, Sam Hartman wrote: >>>>>> "Zhanna" == Zhanna Tsitkova writes: > > Zhanna> Does MIT Kerb have own OID "prefix" - I mean OID that may > Zhanna> be extended for additional attributes? Would you like > Zhanna> rather have Novell-based OIDs? Any other suitable > > Yes, we should be able to get OIDs; talk to Tom. > A Novell OID would involve coordinating with them. > Clearly we should not change existing novell OIDs we're using. From jhutz at cmu.edu Mon Mar 9 17:55:49 2009 From: jhutz at cmu.edu (Jeffrey Hutzelman) Date: Mon, 09 Mar 2009 17:55:49 -0400 Subject: Preliminary discussion: DB alias entries In-Reply-To: <200903092137.n29Lb2QR003849@toasties.srv.cs.cmu.edu> References: <200903050056.n250umZq006351@outgoing.mit.edu> <1236274027.7413.80.camel@ray> <7A0C937B-293B-4C92-9613-085367167296@mit.edu> <1236623386.31266.45.camel@ray> <200903092137.n29Lb2QR003849@toasties.srv.cs.cmu.edu> Message-ID: --On Monday, March 09, 2009 05:36:47 PM -0400 "Stephen C. Buckley" wrote: > Do you know who the right person is at Novell to coordinate? That shouldn't be necessary. The point of using OID's for something like this is that everyone can assign OID's out of their own arcs, rather than having to coordinate with someone else to use theirs. MIT Kerberos has its own OID arc from which ID's can be assigned for this purpose; there's no reason to use numbers in space belonging to IBM or Novell. -- Jeff From hartmans at MIT.EDU Mon Mar 9 18:35:40 2009 From: hartmans at MIT.EDU (Sam Hartman) Date: Mon, 09 Mar 2009 18:35:40 -0400 Subject: Preliminary discussion: DB alias entries In-Reply-To: <16D0028C-A69C-489B-840D-C1B745BEB0B5@mit.edu> (Zhanna Tsitkova's message of "Mon, 9 Mar 2009 17:46:09 -0400") References: <200903050056.n250umZq006351@outgoing.mit.edu> <1236274027.7413.80.camel@ray> <7A0C937B-293B-4C92-9613-085367167296@mit.edu> <1236623386.31266.45.camel@ray> <16D0028C-A69C-489B-840D-C1B745BEB0B5@mit.edu> Message-ID: >>>>> "Zhanna" == Zhanna Tsitkova writes: Zhanna> I would look for MIT Kerberos own OID number for any attr Zhanna> if we cannot find one among the existing OIDs, created by Zhanna> different vendors. Otherwise, I would reuse the existing Zhanna> and registered one, created by Novell, or Sun, or IBM or Zhanna> anyone else. Of course, we cannot modify vendors OID as Zhanna> they are strictly assigned to the organization. I think reusing Novell attributes is fine for this schema. My concern about other vendors would be to what extent they are coordinating with us before changing the semantics of their attribute. Also, I'd want to make sure that the OID was stable nad that the vendor in question had good OID management practices. However I'll admit that I'm very conservative in this sort of space. From ghudson at MIT.EDU Tue Mar 10 22:16:32 2009 From: ghudson at MIT.EDU (Greg Hudson) Date: Tue, 10 Mar 2009 22:16:32 -0400 Subject: Preliminary discussion: DB alias entries In-Reply-To: References: <200903050056.n250umZq006351@outgoing.mit.edu> <1236274027.7413.80.camel@ray> Message-ID: <1236737792.6246.8.camel@ray> On Thu, 2009-03-05 at 12:49 -0500, Sam Hartman wrote: > I think that as several people have proposed an additional > multi-valued attribute will be appropriate. In a lot of places I > think it will be reasonable for this attribute to live in the same > object. (Several days of LDAP research and code hacking later...) Luke actually suggested adding a canonical principal name attribute, not a multi-valued attribute for aliases. I didn't catch that at the time. The subtlety here is that krbPrincipalName is already multi-valued. You can add multiple principal names to a single LDAP entry (using -x dn=... as an argument to add_princ, or from outside of kadmin entirely) and delete them independently of each other. They will share keys and other metadata, as well as any non-Kerberos data on the object (of course). If you search for any of the names, you will get the name you searched for returned back to you. For service principals I believe this level of support is sufficient as is, because we don't canonicalize service principal names anyway. Does that seem accurate? For user principal aliases you do presumably want to canonicalize the name--but I am not aware of any use cases for user principal aliases other than case-folding. From Nicolas.Williams at sun.com Tue Mar 10 22:26:40 2009 From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Tue, 10 Mar 2009 21:26:40 -0500 Subject: Preliminary discussion: DB alias entries In-Reply-To: <1236737792.6246.8.camel@ray> References: <200903050056.n250umZq006351@outgoing.mit.edu> <1236274027.7413.80.camel@ray> <1236737792.6246.8.camel@ray> Message-ID: <20090311022639.GP9992@Sun.COM> On Tue, Mar 10, 2009 at 10:16:32PM -0400, Greg Hudson wrote: > For service principals I believe this level of support is sufficient as > is, because we don't canonicalize service principal names anyway. Does > that seem accurate? Yes. Has it been tested? > For user principal aliases you do presumably want to canonicalize the > name--but I am not aware of any use cases for user principal aliases > other than case-folding. Windows "UPNs," perhaps? Nico -- From ghudson at MIT.EDU Tue Mar 10 23:33:11 2009 From: ghudson at MIT.EDU (Greg Hudson) Date: Tue, 10 Mar 2009 23:33:11 -0400 Subject: Preliminary discussion: DB alias entries In-Reply-To: <20090311022639.GP9992@Sun.COM> References: <200903050056.n250umZq006351@outgoing.mit.edu> <1236274027.7413.80.camel@ray> <1236737792.6246.8.camel@ray> <20090311022639.GP9992@Sun.COM> Message-ID: <1236742391.6246.13.camel@ray> On Tue, 2009-03-10 at 21:26 -0500, Nicolas Williams wrote: > On Tue, Mar 10, 2009 at 10:16:32PM -0400, Greg Hudson wrote: > > For service principals I believe this level of support is sufficient as > > is, because we don't canonicalize service principal names anyway. Does > > that seem accurate? > > Yes. Has it been tested? Just did that now. You can't actually add an alias with addprinc -x dn=... because the addprinc LDAP code refuses to touch an already kerberized entry, but if you add other principals to a service key by hand with ldapmodify, you can get service tickets under the other names and they will work against a keytab with the original name (using sclient and sserver as test cases). From lukeh at padl.com Wed Mar 11 01:00:55 2009 From: lukeh at padl.com (Luke Howard) Date: Wed, 11 Mar 2009 16:00:55 +1100 Subject: Authenticating using lower case domain/realm In-Reply-To: <87bps93pg0.fsf@windlord.stanford.edu> References: <5439879E-41AD-4913-AD44-1E0756FA1064@padl.com> <4650F168-D9BC-4A30-984A-E7D726C28F14@padl.com> <87bps93pg0.fsf@windlord.stanford.edu> Message-ID: <7A98A8E4-9199-46AF-A28B-08BD8A70673C@padl.com> I was looking into implementing support for name canonicalization / UPNs in pam_krb5. In the PAM case, the canonicalized name may be used for authorization to the host system. We can't rely on the name returned in the AS-REP because it is unprotected. So, I think we need to introduce a krb5_verify_init_creds() variant that returns the canonicalized name from the host service ticket. I propose either krb5_verify_init_creds_canonical() with an extra krb5_principal * argument, or a more general krb5_verify_init_creds_ext() API. Thoughts? -- Luke On 11/03/2009, at 10:53 AM, Russ Allbery wrote: > Luke Howard writes: > >> No, it doesn't (nor should it). >> >> However, try the following (untested) patch to pam_krb5. Using >> 1.7, it >> should only be necessary to set the "use_upn" option, either in >> PAM >> libdefaults or pam.conf. > > This is great, thank you! Let me know if he confirms that this > works, and > I'll incorporate it into the next release. > > -- > Russ Allbery (rra at stanford.edu) > > -- www.padl.com | www.fghr.net From hartmans at painless-security.com Wed Mar 11 06:24:35 2009 From: hartmans at painless-security.com (Sam Hartman) Date: Wed, 11 Mar 2009 06:24:35 -0400 Subject: Authenticating using lower case domain/realm In-Reply-To: <7A98A8E4-9199-46AF-A28B-08BD8A70673C@padl.com> (Luke Howard's message of "Wed, 11 Mar 2009 16:00:55 +1100") References: <5439879E-41AD-4913-AD44-1E0756FA1064@padl.com> <4650F168-D9BC-4A30-984A-E7D726C28F14@padl.com> <87bps93pg0.fsf@windlord.stanford.edu> <7A98A8E4-9199-46AF-A28B-08BD8A70673C@padl.com> Message-ID: I'd definitely prefer some sort of extended API. I wonder what it should give you back though. An auth_context? Is that good enough? From raeburn at MIT.EDU Wed Mar 11 13:37:32 2009 From: raeburn at MIT.EDU (Ken Raeburn) Date: Wed, 11 Mar 2009 13:37:32 -0400 Subject: Preliminary discussion: DB alias entries In-Reply-To: <1236737792.6246.8.camel@ray> References: <200903050056.n250umZq006351@outgoing.mit.edu> <1236274027.7413.80.camel@ray> <1236737792.6246.8.camel@ray> Message-ID: On Mar 10, 2009, at 22:16, Greg Hudson wrote: > For user principal aliases you do presumably want to canonicalize the > name--but I am not aware of any use cases for user principal aliases > other than case-folding. Some possible ideas: User name change (e.g., after marriage if the account name is based on the surname, or when a college student heading out into the real world decides maybe an obscene word wasn't a great choice of account name) -- keeping alias info around may be handy for others looking up the person under the old name, but it might be convenient if, should the user enter the old name due to "finger macros" not yet retrained, the name is mapped to the new one. Map reusable UNIX user names to non-reusable unique principal names -- "jsmith" becomes "jsmith/92198478910", while "jsmith/1348539845" was the "jsmith" who left three years ago but might still be in some ACL or log file somewhere. Map real names to user names -- "John Smith" and "J.Smith" become "jsmith" or "jsmith/92198478910". Common typos -- in a small, privately managed realm, perhaps "jsmith" adds an alias "jsmiht" because he keeps typing it wrong when he's in a hurry. Some of these (including determining the correct case) could probably be done externally too, e.g., through LDAP. I haven't particularly thought about which way would be more appropriate for these possible use cases. Ken From hartmans at MIT.EDU Wed Mar 11 13:54:46 2009 From: hartmans at MIT.EDU (Sam Hartman) Date: Wed, 11 Mar 2009 13:54:46 -0400 Subject: Preliminary discussion: DB alias entries In-Reply-To: (Ken Raeburn's message of "Wed, 11 Mar 2009 13:37:32 -0400") References: <200903050056.n250umZq006351@outgoing.mit.edu> <1236274027.7413.80.camel@ray> <1236737792.6246.8.camel@ray> Message-ID: You also want to canonicalize the name when a service principal gets tickets as a client. From raeburn at MIT.EDU Wed Mar 11 14:15:49 2009 From: raeburn at MIT.EDU (Ken Raeburn) Date: Wed, 11 Mar 2009 14:15:49 -0400 Subject: Preliminary discussion: DB alias entries In-Reply-To: References: <200903050056.n250umZq006351@outgoing.mit.edu> <1236274027.7413.80.camel@ray> <1236737792.6246.8.camel@ray> Message-ID: <680A9D06-997F-4BC2-B508-096754E58595@mit.edu> On Mar 11, 2009, at 13:54, Sam Hartman wrote: > You also want to canonicalize the name when a service principal gets > tickets as a client. We may also need to do service-name canonicalization of user principals in some u2u cases -- if not changing the actual name in the credentials, at least being able to look up or verify an alias. (My usual example is "alice" and "bob" talk in the lunch room and decide to exchange files over some p2p system with u2u authentication, but since those are the enterprise names they type in at login time, and the names they've exchanged at lunch, and the names they'll be typing in or looking for, the "real" NT-UID principal names "3F2504E0-4F89-11D3-9A0C-0305E82C3301" and "2f1e4fc0-81fd-11da-9156-00036a0f876a" won't mean anything to either of them.) From lukeh at padl.com Wed Mar 11 18:48:23 2009 From: lukeh at padl.com (Luke Howard) Date: Thu, 12 Mar 2009 09:48:23 +1100 Subject: Authenticating using lower case domain/realm In-Reply-To: References: <5439879E-41AD-4913-AD44-1E0756FA1064@padl.com> <4650F168-D9BC-4A30-984A-E7D726C28F14@padl.com> <87bps93pg0.fsf@windlord.stanford.edu> <7A98A8E4-9199-46AF-A28B-08BD8A70673C@padl.com> Message-ID: <9234E835-D756-44B9-8EFF-3A5DA149E329@padl.com> On 11/03/2009, at 9:24 PM, Sam Hartman wrote: > I'd definitely prefer some sort of extended API. > I wonder what it should give you back though. > An auth_context? > Is that good enough? Just the auth_context? You can't get the ticket principal out of that. It could give back everything rd_req does. -- Luke From hartmans at painless-security.com Wed Mar 11 20:28:28 2009 From: hartmans at painless-security.com (Sam Hartman) Date: Wed, 11 Mar 2009 20:28:28 -0400 Subject: Authenticating using lower case domain/realm In-Reply-To: <9234E835-D756-44B9-8EFF-3A5DA149E329@padl.com> (Luke Howard's message of "Thu, 12 Mar 2009 09:48:23 +1100") References: <5439879E-41AD-4913-AD44-1E0756FA1064@padl.com> <4650F168-D9BC-4A30-984A-E7D726C28F14@padl.com> <87bps93pg0.fsf@windlord.stanford.edu> <7A98A8E4-9199-46AF-A28B-08BD8A70673C@padl.com> <9234E835-D756-44B9-8EFF-3A5DA149E329@padl.com> Message-ID: Ah, I always get confused between authenticator and ap-req. and thought that krb5_auth_gcon_getauthenticator would help. But yes, giving back everything from rd_req sounds good. From snambakam at likewise.com Wed Mar 11 20:23:52 2009 From: snambakam at likewise.com (Sriram Nambakam) Date: Wed, 11 Mar 2009 20:23:52 -0400 Subject: segfault in spnego_mech.c In-Reply-To: <7a83c8e0903061128s346bd633t3f1ed0de1f43ae8e@mail.gmail.com> References: <7a83c8e0903061128s346bd633t3f1ed0de1f43ae8e@mail.gmail.com> Message-ID: <23447137FA0DAA4D95EF535FF356BE4601C61251@mse3be2.mse3.exchange.ms> I was able to reproduce the crash by causing a clock skew on the system. -----Original Message----- From: krbdev-bounces at mit.edu [mailto:krbdev-bounces at mit.edu] On Behalf Of Marcus Granado Sent: Friday, March 06, 2009 11:29 AM To: krbdev at mit.edu Subject: segfault in spnego_mech.c Hi, I think there's a bug in spnego_mech.c leading to a segfault. The line numbers here are relative to the release 20899 at http://src.mit.edu/fisheye/browse/krb5/branches/mskrb-integ/src/lib/gssa pi/spnego/spnego_mech.c?r=20899(the latest revision of this file in trunk, I believe: http://src.mit.edu/fisheye/browse/krb5/branches/mskrb-integ/src/lib/gssa pi/spnego/spnego_mech.c ). A quick description of the problem: The function acc_ctx_new()@919 can fail with 3 possibilities in the return_token parameter: {INIT_TOKEN_SEND,NO_TOKEN_SEND,ERROR_TOKEN_SEND}. Now, the function spnego_gss_accept_sec_context()@1199 calls acc_ctx_new() at line 1248. If ret != GSS_S_COMPLETE, it goesto cleanup at 1291, checking for non-equality of only two possible values in return_token: NO_TOKEN_SEND and CHECK_MIC. If return_token is not any of them, it calls make_spnego_tokenTarg_msg(), dereferencing the NULL pointer sc and triggering a segfault! The pointer sc is not initialized at this point for two reasons: (1) we jumped over its initialization on line 1264 when we wentto cleanup at 1291; and (2) we might be calling gss_accept_sec_context for the first time with an null context_handle. A quick way to test the bug: if the input_token sent to gss_accept_sec_context() is not null, but an empty buffer (i.e. GSS_C_EMPTY_BUFFER instead of GSS_C_NO_BUFFER), line 1257 will call acc_ctx_new() with an empty input_token (len=0) in its buf parameter, and send that to get_negTokenInit()@2032 -> g_verify_token_header()@2802, which will fail with a G_BAD_TOK_HEADER because the size of the input_token is 0, causing acc_ctx_new() to return an ERROR_TOKEN_SEND in return_token. That will cause acc_ctx_new() to fail with a GSS_S_FAILURE and return_token=ERROR_TOKEN_SEND. We'll be sent to cleanup at 1291, and the condition (return_token != NO_TOKEN_SEND && return_token != CHECK_MIC) will be true, calling make_spnego_toeknTarg_msg() with a NULL sc pointer, leading to a crash. Anyone else able to reproduce that as well? I believe a solution is to improve the condition above at line 1292, including also the possible return_token values INIT_TOKEN_SEND and NO_TOKEN_SEND that can be returned by acc_ctx_new() [btw, I didn't check what acc_ctx_cont() and acc_ctx_call_acc() could return in return_token], but since the algorithm is not trivial, it will take someone knowledgeable in the gssapi spec to assert that. Thanks, Marcus _______________________________________________ krbdev mailing list krbdev at mit.edu https://mailman.mit.edu/mailman/listinfo/krbdev From hartmans at MIT.EDU Thu Mar 12 08:50:46 2009 From: hartmans at MIT.EDU (Sam Hartman) Date: Thu, 12 Mar 2009 08:50:46 -0400 Subject: Preliminary discussion: DB alias entries In-Reply-To: (Ken Raeburn's message of "Wed, 11 Mar 2009 13:37:32 -0400") References: <200903050056.n250umZq006351@outgoing.mit.edu> <1236274027.7413.80.camel@ray> <1236737792.6246.8.camel@ray> Message-ID: >>>>> "Ken" == Ken Raeburn writes: Ken> On Mar 10, 2009, at 22:16, Greg Hudson wrote: >> For user principal aliases you do presumably want to canonicalize the >> name--but I am not aware of any use cases for user principal aliases >> other than case-folding. I understand if we don't have time to add a canonical principal attribute for 1.7, but I think we should try for 1.7.1. We do support user name aliases, and they seem to be something that people care about. The Role of Kerberos paper and the Kerberos in Mixed Environments paper talk about this in some detail, although a lot of that discussion applies more to enterprise names than non-enterprise aliases. Another case where user principal aliases come into play is the one I discussed: services getting tickets as a user. Having non-canonicalized user principals is very bad because it breaks name-based authorization. It's not so bad if you generate a PAC (and use it), but our LDAP backend does not do that. --Sam From nikhilm at gs-lab.com Thu Mar 12 08:55:27 2009 From: nikhilm at gs-lab.com (Nikhil Mishra) Date: Thu, 12 Mar 2009 18:25:27 +0530 Subject: Is MIT kerberos thread safe ?? Message-ID: <49B9063F.8040109@gs-lab.com> Hi All , As the subject says , Is MIT kerberos thread safe ? My device is a high performance network appliance and I need to analyze threadsafe-ness of MIT kerberos library. I have followed following links from past discussion forums : http://mailman.mit.edu/pipermail/kerberos/2003-July/003483.html http://mailman.mit.edu/pipermail/krbdev/2003-December/002096.html evident from which is library is not thread-safe . But I see some progress towards identifying issues with being thread-safe , Is there any progress in this area ? Is there any plan for doing so ? Any help is appreciated . Thanks Nikhil From raeburn at MIT.EDU Thu Mar 12 12:43:09 2009 From: raeburn at MIT.EDU (Ken Raeburn) Date: Thu, 12 Mar 2009 12:43:09 -0400 Subject: Is MIT kerberos thread safe ?? In-Reply-To: <49B9063F.8040109@gs-lab.com> References: <49B9063F.8040109@gs-lab.com> Message-ID: On Mar 12, 2009, at 08:55, Nikhil Mishra wrote: > As the subject says , Is MIT kerberos thread safe ? > My device is a high performance network appliance and > I need to analyze threadsafe-ness of MIT kerberos library. The 1.6.x releases should be thread-safe provided certain objects are not shared across threads for simultaneous use, primarily the Kerberos and GSSAPI context types. Various other objects, especially the simpler ones like krb5_data and krb5_principal, and most of the structures exposed in our API, can be shared as long as both uses are read-only. Some more complex, opaque types like krb5_ccache, and most if not all internal static data, have internal locking performed within the libraries, so that they can be used from multiple threads without corruption. Unfortunately, we don't have documentation written up on *exactly* what can be shared across threads and when, but "never share contexts, and share other stuff only as inputs not outputs" is a good guideline. And, all the above said, there could of course be bugs; if you run into anything, we'd like to know. Depending on the OS, there may also be a few bits where no thread-safe OS version of some functionality is available. In particular, tty handling when prompting for passwords is not likely to be thread-safe -- but if your application is prompting for several passwords simultaneously, it's probably doing something else wrong. > I have followed following links from past discussion > forums : [... stuff five years old ...] The thread-safety patches were included in the 1.4 release series, not too long after those discussions. Ken From hotz at jpl.nasa.gov Thu Mar 12 12:43:24 2009 From: hotz at jpl.nasa.gov (Henry B. Hotz) Date: Thu, 12 Mar 2009 09:43:24 -0700 Subject: Authenticating using lower case domain/realm In-Reply-To: References: Message-ID: <2CA55CE7-451B-4D4A-84A9-18EF5EA0B1F6@jpl.nasa.gov> On Mar 11, 2009, at 9:12 AM, krbdev-request at mit.edu wrote: > Date: Wed, 11 Mar 2009 16:00:55 +1100 > From: Luke Howard > Subject: Re: Authenticating using lower case domain/realm > To: Russ Allbery , Sam Hartman > > Cc: "krbdev at mit.edu List" > Message-ID: <7A98A8E4-9199-46AF-A28B-08BD8A70673C at padl.com> > Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes > > I was looking into implementing support for name canonicalization / > UPNs in pam_krb5. In the PAM case, the canonicalized name may be used > for authorization to the host system. We can't rely on the name > returned in the AS-REP because it is unprotected. > > So, I think we need to introduce a krb5_verify_init_creds() variant > that returns the canonicalized name from the host service ticket. I > propose either krb5_verify_init_creds_canonical() with an extra > krb5_principal * argument, or a more general > krb5_verify_init_creds_ext() API. > > Thoughts? > > -- Luke Which pam_krb5? There are so many! I would vote for the Debian/Stanford one. (Hint to RedHat.) (Nothing against the Solaris one, but they have the luxury of making the pam framework and ssh behave in a sane manner.) ------------------------------------------------------ The opinions expressed in this message are mine, not those of Caltech, JPL, NASA, or the US Government. Henry.B.Hotz at jpl.nasa.gov, or hbhotz at oxy.edu From tlyu at MIT.EDU Thu Mar 12 12:53:45 2009 From: tlyu at MIT.EDU (Tom Yu) Date: Thu, 12 Mar 2009 12:53:45 -0400 Subject: segfault in spnego_mech.c In-Reply-To: <7a83c8e0903061128s346bd633t3f1ed0de1f43ae8e@mail.gmail.com> (Marcus Granado's message of "Fri, 6 Mar 2009 19:28:45 +0000") References: <7a83c8e0903061128s346bd633t3f1ed0de1f43ae8e@mail.gmail.com> Message-ID: Marcus Granado writes: > Hi, > > I think there's a bug in spnego_mech.c leading to a segfault. The line > numbers here are relative to the release 20899 at > http://src.mit.edu/fisheye/browse/krb5/branches/mskrb-integ/src/lib/gssapi/spnego/spnego_mech.c?r=20899(the > latest revision of this file in trunk, I believe: > http://src.mit.edu/fisheye/browse/krb5/branches/mskrb-integ/src/lib/gssapi/spnego/spnego_mech.c > ). > > A quick description of the problem: > > The function acc_ctx_new()@919 can fail with 3 possibilities in the > return_token parameter: {INIT_TOKEN_SEND,NO_TOKEN_SEND,ERROR_TOKEN_SEND}. > > Now, the function spnego_gss_accept_sec_context()@1199 calls acc_ctx_new() > at line 1248. If ret != GSS_S_COMPLETE, it goesto cleanup at 1291, checking for > non-equality of only two possible values in return_token: NO_TOKEN_SEND and > CHECK_MIC. > > If return_token is not any of them, it calls make_spnego_tokenTarg_msg(), > dereferencing the NULL pointer sc and triggering a segfault! The pointer sc > is not initialized at this point for two reasons: (1) we jumped over its > initialization on line 1264 when we wentto cleanup at 1291; and (2) we might be > calling gss_accept_sec_context for the first time with an null > context_handle. I believe this is related to, if not identical to, ticket #6402. From ghudson at MIT.EDU Thu Mar 12 16:05:29 2009 From: ghudson at MIT.EDU (Greg Hudson) Date: Thu, 12 Mar 2009 16:05:29 -0400 Subject: Preliminary discussion: DB alias entries In-Reply-To: References: <200903050056.n250umZq006351@outgoing.mit.edu> Message-ID: <1236888329.6246.29.camel@ray> On Thu, 2009-03-05 at 13:44 +1100, Luke Howard wrote: > Which reminds me, the following usage of > strcaescmp() in krb5_ldap_get_principal() is somewhat dubious: Since that loop is iterating over a list of values returned by a case-sensitive match (the concern is that the principal name might contain a wildcard), I think this can just be changed to strcmp. > /* a wild-card in a principal name can return a list > of kerberos principals. > * Make sure that the correct principal is returned. > * NOTE: a principalname k* in ldap server will > return all the principals starting with a k > */ > for (i=0; values[i] != NULL; ++i) { > if (strcasecmp(values[i], user) == 0) { > *nentries = 1; > break; > } > } From Mark.Phalan at Sun.COM Thu Mar 12 17:13:40 2009 From: Mark.Phalan at Sun.COM (Mark Phalan) Date: Thu, 12 Mar 2009 22:13:40 +0100 Subject: Is MIT kerberos thread safe ?? In-Reply-To: References: <49B9063F.8040109@gs-lab.com> Message-ID: On 12 Mar 2009, at 17:43, Ken Raeburn wrote: > On Mar 12, 2009, at 08:55, Nikhil Mishra wrote: >> As the subject says , Is MIT kerberos thread safe ? >> My device is a high performance network appliance and >> I need to analyze threadsafe-ness of MIT kerberos library. > > The 1.6.x releases should be thread-safe provided certain objects are > not shared across threads for simultaneous use, primarily the Kerberos > and GSSAPI context types. Various other objects, especially the > simpler ones like krb5_data and krb5_principal, and most of the > structures exposed in our API, can be shared as long as both uses are > read-only. Some more complex, opaque types like krb5_ccache, and most > if not all internal static data, have internal locking performed > within the libraries, so that they can be used from multiple threads > without corruption. > > Unfortunately, we don't have documentation written up on *exactly* > what can be shared across threads and when, but "never share contexts, > and share other stuff only as inputs not outputs" is a good guideline. > > And, all the above said, there could of course be bugs; if you run > into anything, we'd like to know. The PKINIT plugin is a problem if it is used in multiple threads due to its use of OpenSSL. -M From raeburn at MIT.EDU Thu Mar 12 17:35:55 2009 From: raeburn at MIT.EDU (Ken Raeburn) Date: Thu, 12 Mar 2009 17:35:55 -0400 Subject: Is MIT kerberos thread safe ?? In-Reply-To: References: <49B9063F.8040109@gs-lab.com> Message-ID: <8D1D636E-9A99-4348-A42A-C265C4177787@mit.edu> On Mar 12, 2009, at 17:13, Mark Phalan wrote: > The PKINIT plugin is a problem if it is used in multiple threads due > to its use of OpenSSL. Interesting, thanks for the info. I'll put that in the bug database. It *should* be part of the plugin API specs whether the plugin or the caller is responsible for thread safety issues. I don't know what the story is with the preauth plugin API offhand. Ken From ghudson at MIT.EDU Thu Mar 12 23:21:24 2009 From: ghudson at MIT.EDU (Greg Hudson) Date: Thu, 12 Mar 2009 23:21:24 -0400 Subject: Preliminary discussion: DB alias entries In-Reply-To: <1236292763.7413.87.camel@ray> References: <200903050056.n250umZq006351@outgoing.mit.edu> <1236292763.7413.87.camel@ray> Message-ID: <1236914484.6246.65.camel@ray> More status updates on DB alias entries: * Based on feedback from Sam and others, I prioritized LDAP aliases ahead of DB2 aliases. * It turns out that the existing LDAP code already supports multiple names for an entry, but doesn't know which one is canonical. I have working code to add krbCanonicalName to the schema and support for it, and am just waiting for an OID assignment from the MIT arc for the new attribute. (Do I also need to register the name somewhere in some global LDAP list of names?) * My very simple plan for introducing db2 aliases may not be as simple as I hoped. Our current back end code does not assume that different processes can share an opened db2 database. I'm not sure how much of that is conservatism and how much of that is real. If we use a second db2 database for the aliases, that means there has to be a locking protocol between the KDC and the code to update the aliases DB--which means you can't use just any old db2 program to update the DB. I'll need to think on this some more. Side issues which came up: * I discovered that kdb5_ldap_utils had been broken by the merge of Luke's work and fixed it (though there may be an additional constraint on how much of krb5.conf has to be set up for kdb5_ldap_utils to work). * I discovered that our client side support for aliases didn't work in cases where the client derives the salt from the client principal name. I've committed a fix for the simple case (no preauth); Sam thinks further changes are probably necessary for some preauth cases but hopes to learn more about what those changes are at the interop event. * If the client principal is canonicalized by the KDC, we are still prompting for a password using the requested principal name, which is perhaps undesirable. This is because the canonicalized name might contain unprintable characters (either from a malicious KDC or from an attacker) and I wasn't prepared to add unprintable-sanitization code to the library at this moment. Comments welcome as usual. From ssorce at redhat.com Fri Mar 13 08:58:32 2009 From: ssorce at redhat.com (Simo Sorce) Date: Fri, 13 Mar 2009 08:58:32 -0400 Subject: Preliminary discussion: DB alias entries In-Reply-To: <1236914484.6246.65.camel@ray> References: <200903050056.n250umZq006351@outgoing.mit.edu> <1236292763.7413.87.camel@ray> <1236914484.6246.65.camel@ray> Message-ID: <1236949112.25780.2.camel@localhost.localdomain> On Thu, 2009-03-12 at 23:21 -0400, Greg Hudson wrote: > * I discovered that our client side support for aliases didn't work in > cases where the client derives the salt from the client principal name. > I've committed a fix for the simple case (no preauth); Sam thinks > further changes are probably necessary for some preauth cases but hopes > to learn more about what those changes are at the interop event. Thanks, I meant to ask about this for some time, but always postponed to gather some more info before asking :/ I tested a while back if renaming users (changing krbPrincipalName via ldapmodify) would work, and it didn't (I had to reset the secret as well every time). I assume the fix you did would also resolve this issue, it would be very cool. Simo. -- Simo Sorce * Red Hat, Inc * New York From lukeh at padl.com Fri Mar 13 09:37:26 2009 From: lukeh at padl.com (Luke Howard) Date: Sat, 14 Mar 2009 00:37:26 +1100 Subject: Preliminary discussion: DB alias entries In-Reply-To: <1236949112.25780.2.camel@localhost.localdomain> References: <200903050056.n250umZq006351@outgoing.mit.edu> <1236292763.7413.87.camel@ray> <1236914484.6246.65.camel@ray> <1236949112.25780.2.camel@localhost.localdomain> Message-ID: <6C30A94A-AE24-4B40-980F-7C2AD369688D@padl.com> > I meant to ask about this for some time, but always postponed to > gather > some more info before asking :/ > I tested a while back if renaming users (changing krbPrincipalName via > ldapmodify) would work, and it didn't (I had to reset the secret as > well > every time). I assume the fix you did would also resolve this issue, > it > would be very cool. Right, it should work; the salt should be stored with the key, independently of the principal name, and if necessary returned to the client in an ETYPE-INFO[2]. Things are a little more complicated for service principals, but hopefully their names are less likely to change. -- Luke From ssorce at redhat.com Fri Mar 13 09:45:00 2009 From: ssorce at redhat.com (Simo Sorce) Date: Fri, 13 Mar 2009 09:45:00 -0400 Subject: Preliminary discussion: DB alias entries In-Reply-To: <6C30A94A-AE24-4B40-980F-7C2AD369688D@padl.com> References: <200903050056.n250umZq006351@outgoing.mit.edu> <1236292763.7413.87.camel@ray> <1236914484.6246.65.camel@ray> <1236949112.25780.2.camel@localhost.localdomain> <6C30A94A-AE24-4B40-980F-7C2AD369688D@padl.com> Message-ID: <1236951900.25780.24.camel@localhost.localdomain> On Sat, 2009-03-14 at 00:37 +1100, Luke Howard wrote: > > I meant to ask about this for some time, but always postponed to > > gather > > some more info before asking :/ > > I tested a while back if renaming users (changing krbPrincipalName via > > ldapmodify) would work, and it didn't (I had to reset the secret as > > well > > every time). I assume the fix you did would also resolve this issue, > > it > > would be very cool. > > Right, it should work; the salt should be stored with the key, > independently of the principal name, and if necessary returned to the > client in an ETYPE-INFO[2]. Things are a little more complicated for > service principals, but hopefully their names are less likely to change. Yes, I initially tried making the salt always random, but that obviously didn't work, if the libs are fixed to accept a random salt with all enctypes that would be also nice. Simo. -- Simo Sorce * Red Hat, Inc * New York From lukeh at padl.com Fri Mar 13 09:51:36 2009 From: lukeh at padl.com (Luke Howard) Date: Sat, 14 Mar 2009 00:51:36 +1100 Subject: Preliminary discussion: DB alias entries In-Reply-To: <1236951900.25780.24.camel@localhost.localdomain> References: <200903050056.n250umZq006351@outgoing.mit.edu> <1236292763.7413.87.camel@ray> <1236914484.6246.65.camel@ray> <1236949112.25780.2.camel@localhost.localdomain> <6C30A94A-AE24-4B40-980F-7C2AD369688D@padl.com> <1236951900.25780.24.camel@localhost.localdomain> Message-ID: <0CA4D587-12B6-44DF-B72E-690921B5AED8@padl.com> > I initially tried making the salt always random, but that obviously > didn't work, if the libs are fixed to accept a random salt with all > enctypes that would be also nice. It can save the client a round trip if the salt is well known. For AD, the rules for the salting principal input (NOT the salt itself) are: For users: samAccountName at DOMAIN, unless the user has a UPN, in which case it is LHS-of-UPN at DOMAIN. For machine accounts: host/samAccountName-without-$.domain at DOMAIN. For trust and TGS accounts, krbtgt/DOMAIN1 at DOMAIN2. -- Luke From raeburn at MIT.EDU Fri Mar 13 10:23:28 2009 From: raeburn at MIT.EDU (Ken Raeburn) Date: Fri, 13 Mar 2009 10:23:28 -0400 Subject: Is MIT kerberos thread safe ?? In-Reply-To: <49B9FAD9.7020904@gs-lab.com> References: <49B9063F.8040109@gs-lab.com> <49B9FAD9.7020904@gs-lab.com> Message-ID: <1547CB40-4580-44E6-962D-856C789A337F@MIT.EDU> On Mar 13, 2009, at 02:19, Nikhil Mishra wrote: > As far as I understand , Context object has some profile related > objects > which is essentially a global static variable and this might give me > some > trouble . The profile objects are shared when derived from the same set of config files (which can be controlled via environment variables), to reduce file accesses for a common case; however, locking is used internally on the profile objects. > The thing that I am trying to do here is , My box gets N users per > second > and I would like to authenticate all of them ( so , basically fetch > the TGT) > through kerberos. I was trying to run all of them through a thread > based > solution . > > If thats the case I can may be create a context once and share it > across > all > the threads for fetching the credentials ? Not without locking, as other data in the context is modified without additional locking. A context can only be used in one thread at a time. (And auth_context likewise.) Ken From hartmans at MIT.EDU Fri Mar 13 10:53:43 2009 From: hartmans at MIT.EDU (Sam Hartman) Date: Fri, 13 Mar 2009 10:53:43 -0400 Subject: Preliminary discussion: DB alias entries In-Reply-To: <1236949112.25780.2.camel@localhost.localdomain> (Simo Sorce's message of "Fri, 13 Mar 2009 08:58:32 -0400") References: <200903050056.n250umZq006351@outgoing.mit.edu> <1236292763.7413.87.camel@ray> <1236914484.6246.65.camel@ray> <1236949112.25780.2.camel@localhost.localdomain> Message-ID: >>>>> "Simo" == Simo Sorce writes: Simo> On Thu, 2009-03-12 at 23:21 -0400, Greg Hudson wrote: >> * I discovered that our client side support for aliases didn't >> work in cases where the client derives the salt from the client >> principal name. I've committed a fix for the simple case (no >> preauth); Sam thinks further changes are probably necessary for >> some preauth cases but hopes to learn more about what those >> changes are at the interop event. Simo> Thanks, I meant to ask about this for some time, but always Simo> postponed to gather some more info before asking :/ I tested Simo> a while back if renaming users (changing krbPrincipalName Simo> via ldapmodify) would work, and it didn't (I had to reset Simo> the secret as well every time). I assume the fix you did Simo> would also resolve this issue, it would be very cool. Not really. If you want to rename a principal, you need to update the key data to include the old salt in the key data. I seem to recall John Hascall had a mostly working patch for doing that. I think after I figure out what KDC side changes are needed, if you had a 1.7 KDC and added/removed aliases to a principal but do not change the canonical name, you will not need to rekey the principal. From hartmans at MIT.EDU Fri Mar 13 10:54:32 2009 From: hartmans at MIT.EDU (Sam Hartman) Date: Fri, 13 Mar 2009 10:54:32 -0400 Subject: Preliminary discussion: DB alias entries In-Reply-To: <6C30A94A-AE24-4B40-980F-7C2AD369688D@padl.com> (Luke Howard's message of "Sat, 14 Mar 2009 00:37:26 +1100") References: <200903050056.n250umZq006351@outgoing.mit.edu> <1236292763.7413.87.camel@ray> <1236914484.6246.65.camel@ray> <1236949112.25780.2.camel@localhost.localdomain> <6C30A94A-AE24-4B40-980F-7C2AD369688D@padl.com> Message-ID: >>>>> "Luke" == Luke Howard writes: >> I meant to ask about this for some time, but always postponed >> to gather some more info before asking :/ I tested a while back >> if renaming users (changing krbPrincipalName via ldapmodify) >> would work, and it didn't (I had to reset the secret as well >> every time). I assume the fix you did would also resolve this >> issue, it would be very cool. Luke> Right, it should work; the salt should be stored with the Luke> key, independently of the principal name, and if necessary Luke> returned to the client in an ETYPE-INFO[2]. Things are a Luke> little more complicated for service principals, but Luke> hopefully their names are less likely to change. Our code doesn't store salts like that. kadmind could be changed to do so. From hartmans at MIT.EDU Fri Mar 13 10:55:24 2009 From: hartmans at MIT.EDU (Sam Hartman) Date: Fri, 13 Mar 2009 10:55:24 -0400 Subject: Preliminary discussion: DB alias entries In-Reply-To: <1236951900.25780.24.camel@localhost.localdomain> (Simo Sorce's message of "Fri, 13 Mar 2009 09:45:00 -0400") References: <200903050056.n250umZq006351@outgoing.mit.edu> <1236292763.7413.87.camel@ray> <1236914484.6246.65.camel@ray> <1236949112.25780.2.camel@localhost.localdomain> <6C30A94A-AE24-4B40-980F-7C2AD369688D@padl.com> <1236951900.25780.24.camel@localhost.localdomain> Message-ID: >>>>> "Simo" == Simo Sorce writes: Simo> Yes, I initially tried making the salt always random, but Simo> that obviously didn't work, if the libs are fixed to accept Simo> a random salt with all enctypes that would be also nice. How did this fail? I'd definitely expect it to work. If it does not, we have some deeper problems. From hartmans at MIT.EDU Fri Mar 13 10:57:23 2009 From: hartmans at MIT.EDU (Sam Hartman) Date: Fri, 13 Mar 2009 10:57:23 -0400 Subject: Is MIT kerberos thread safe ?? In-Reply-To: <1547CB40-4580-44E6-962D-856C789A337F@MIT.EDU> (Ken Raeburn's message of "Fri, 13 Mar 2009 10:23:28 -0400") References: <49B9063F.8040109@gs-lab.com> <49B9FAD9.7020904@gs-lab.com> <1547CB40-4580-44E6-962D-856C789A337F@MIT.EDU> Message-ID: I'd expect a context per thread would be a better fit for this use case. From ssorce at redhat.com Fri Mar 13 11:28:27 2009 From: ssorce at redhat.com (Simo Sorce) Date: Fri, 13 Mar 2009 11:28:27 -0400 Subject: Preliminary discussion: DB alias entries In-Reply-To: <0CA4D587-12B6-44DF-B72E-690921B5AED8@padl.com> References: <200903050056.n250umZq006351@outgoing.mit.edu> <1236292763.7413.87.camel@ray> <1236914484.6246.65.camel@ray> <1236949112.25780.2.camel@localhost.localdomain> <6C30A94A-AE24-4B40-980F-7C2AD369688D@padl.com> <1236951900.25780.24.camel@localhost.localdomain> <0CA4D587-12B6-44DF-B72E-690921B5AED8@padl.com> Message-ID: <1236958107.25780.29.camel@localhost.localdomain> On Sat, 2009-03-14 at 00:51 +1100, Luke Howard wrote: > > I initially tried making the salt always random, but that obviously > > didn't work, if the libs are fixed to accept a random salt with all > > enctypes that would be also nice. > > It can save the client a round trip if the salt is well known. For AD, > the rules for the salting principal input (NOT the salt itself) are: > > For users: samAccountName at DOMAIN, unless the user has a UPN, in which > case it is LHS-of-UPN at DOMAIN. > > For machine accounts: host/samAccountName-without-$.domain at DOMAIN. > > For trust and TGS accounts, krbtgt/DOMAIN1 at DOMAIN2. I use pre-authentication anyway so I already have to do the second round trip, shouldn't be a problem in that case, right ? Simo. -- Simo Sorce * Red Hat, Inc * New York From ssorce at redhat.com Fri Mar 13 11:35:15 2009 From: ssorce at redhat.com (Simo Sorce) Date: Fri, 13 Mar 2009 11:35:15 -0400 Subject: Preliminary discussion: DB alias entries In-Reply-To: References: <200903050056.n250umZq006351@outgoing.mit.edu> <1236292763.7413.87.camel@ray> <1236914484.6246.65.camel@ray> <1236949112.25780.2.camel@localhost.localdomain> <6C30A94A-AE24-4B40-980F-7C2AD369688D@padl.com> <1236951900.25780.24.camel@localhost.localdomain> Message-ID: <1236958515.25780.31.camel@localhost.localdomain> On Fri, 2009-03-13 at 10:55 -0400, Sam Hartman wrote: > >>>>> "Simo" == Simo Sorce writes: > > Simo> Yes, I initially tried making the salt always random, but > Simo> that obviously didn't work, if the libs are fixed to accept > Simo> a random salt with all enctypes that would be also nice. > > How did this fail? > I'd definitely expect it to work. > If it does not, we have some deeper problems. I had no time to do a complete assessment of why it failed, that's why I didn't report it. I will get back with a bug report when I am able to confirm it wasn't just my fault (I don't use kadmin to create keys in ldap, so there may very well be bugs in my code that prevented that from working correctly). Simo. -- Simo Sorce * Red Hat, Inc * New York From nikhilm at gs-lab.com Fri Mar 13 02:19:05 2009 From: nikhilm at gs-lab.com (Nikhil Mishra) Date: Fri, 13 Mar 2009 11:49:05 +0530 Subject: Is MIT kerberos thread safe ?? In-Reply-To: References: <49B9063F.8040109@gs-lab.com> Message-ID: <49B9FAD9.7020904@gs-lab.com> Hello Ken , Thanks for the info above. As far as I understand , Context object has some profile related objects which is essentially a global static variable and this might give me some trouble . The thing that I am trying to do here is , My box gets N users per second and I would like to authenticate all of them ( so , basically fetch the TGT) through kerberos. I was trying to run all of them through a thread based solution . If thats the case I can may be create a context once and share it across all the threads for fetching the credentials ? Thanks --Nikhil Ken Raeburn wrote: > On Mar 12, 2009, at 08:55, Nikhil Mishra wrote: >> As the subject says , Is MIT kerberos thread safe ? >> My device is a high performance network appliance and >> I need to analyze threadsafe-ness of MIT kerberos library. > > The 1.6.x releases should be thread-safe provided certain objects are > not shared across threads for simultaneous use, primarily the Kerberos > and GSSAPI context types. Various other objects, especially the > simpler ones like krb5_data and krb5_principal, and most of the > structures exposed in our API, can be shared as long as both uses are > read-only. Some more complex, opaque types like krb5_ccache, and most > if not all internal static data, have internal locking performed > within the libraries, so that they can be used from multiple threads > without corruption. > > Unfortunately, we don't have documentation written up on *exactly* > what can be shared across threads and when, but "never share contexts, > and share other stuff only as inputs not outputs" is a good guideline. > > And, all the above said, there could of course be bugs; if you run > into anything, we'd like to know. > > Depending on the OS, there may also be a few bits where no thread-safe > OS version of some functionality is available. In particular, tty > handling when prompting for passwords is not likely to be thread-safe > -- but if your application is prompting for several passwords > simultaneously, it's probably doing something else wrong. > >> I have followed following links from past discussion >> forums : > > [... stuff five years old ...] > > The thread-safety patches were included in the 1.4 release series, not > too long after those discussions. > > Ken > From lukeh at padl.com Fri Mar 13 18:06:34 2009 From: lukeh at padl.com (Luke Howard) Date: Sat, 14 Mar 2009 09:06:34 +1100 Subject: Preliminary discussion: DB alias entries In-Reply-To: <1236958107.25780.29.camel@localhost.localdomain> References: <200903050056.n250umZq006351@outgoing.mit.edu> <1236292763.7413.87.camel@ray> <1236914484.6246.65.camel@ray> <1236949112.25780.2.camel@localhost.localdomain> <6C30A94A-AE24-4B40-980F-7C2AD369688D@padl.com> <1236951900.25780.24.camel@localhost.localdomain> <0CA4D587-12B6-44DF-B72E-690921B5AED8@padl.com> <1236958107.25780.29.camel@localhost.localdomain> Message-ID: > I use pre-authentication anyway so I already have to do the second > round > trip, shouldn't be a problem in that case, right ? That would depend on whether your client tries pre-authentication by default. -- Luke From lukeh at padl.com Fri Mar 13 18:06:54 2009 From: lukeh at padl.com (Luke Howard) Date: Sat, 14 Mar 2009 09:06:54 +1100 Subject: Preliminary discussion: DB alias entries In-Reply-To: References: <200903050056.n250umZq006351@outgoing.mit.edu> <1236292763.7413.87.camel@ray> <1236914484.6246.65.camel@ray> <1236949112.25780.2.camel@localhost.localdomain> <6C30A94A-AE24-4B40-980F-7C2AD369688D@padl.com> Message-ID: <0B94A571-C763-48E7-8F01-B0B73F6AB3E1@padl.com> > Luke> Right, it should work; the salt should be stored with the > Luke> key, independently of the principal name, and if necessary > Luke> returned to the client in an ETYPE-INFO[2]. Things are a > Luke> little more complicated for service principals, but > Luke> hopefully their names are less likely to change. > > Our code doesn't store salts like that. > kadmind could be changed to do so. Ah, OK. So, I was thinking of the Novell backend. -- Luke From Qiang.Xu at fujixerox.com Mon Mar 16 04:03:15 2009 From: Qiang.Xu at fujixerox.com (Xu, Qiang (FXSGSC)) Date: Mon, 16 Mar 2009 16:03:15 +0800 Subject: SASL authentication Message-ID: Hi, all: I am trying to do LDAP SASL binding to ADS in Windows 2003 server, which is where KDC resides at the same time. Unfortunately, an error is confusing me: ============================================== (Fri Mar 13 2009 13:34:19.846) INFO>> SASL Login (Fri Mar 13 2009 13:35:07.089) INFO>> SASL LDAP BIND with GSSAPI: Value of ldapStatus 82 (Fri Mar 13 2009 13:35:07.089) ERROR>> LDAP BIND: Value of ldap failure status and text 82 Local error ============================================== Using klist, it is verified that a Kerberos ticket exists and has not expired. Besides this, what else should be done at the server's end, or at the client's end? Any set-up issue? (the client has SASL library and its GSSAPI plugin in place, already) Looking forward to help, Xu Qiang From hotz at jpl.nasa.gov Mon Mar 16 17:33:45 2009 From: hotz at jpl.nasa.gov (Henry B. Hotz) Date: Mon, 16 Mar 2009 14:33:45 -0700 Subject: SASL authentication In-Reply-To: References: Message-ID: <11A1CB8A-266F-41E4-880D-5D03703D81F8@jpl.nasa.gov> This is not the right list. I'd recommend an OpenLDAP list. (I'd be more specific, but I'm not active in that community.) That said, I've heard that a Windows DC will not accept an authenticated bind except over SSL/TLS. Period. Regardless of whether a SASL security layer is negotiated or not. If that's not it, then I'm sorry I can't help. On Mar 16, 2009, at 12:13 PM, krbdev-request at mit.edu wrote: > Send krbdev mailing list submissions to > krbdev at mit.edu > > To subscribe or unsubscribe via the World Wide Web, visit > https://mailman.mit.edu/mailman/listinfo/krbdev > or, via email, send a message with subject or body 'help' to > krbdev-request at mit.edu > > You can reach the person managing the list at > krbdev-owner at mit.edu > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of krbdev digest..." > > > Today's Topics: > > 1. SASL authentication (Xu, Qiang (FXSGSC)) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Mon, 16 Mar 2009 16:03:15 +0800 > From: "Xu, Qiang (FXSGSC)" > Subject: SASL authentication > To: "kerberos at mit.edu" , "krbdev at mit.edu" > > Message-ID: > > > > Content-Type: text/plain; charset="iso-8859-1" > > Hi, all: > > I am trying to do LDAP SASL binding to ADS in Windows 2003 server, > which is where KDC resides at the same time. > > Unfortunately, an error is confusing me: > ============================================== > (Fri Mar 13 2009 13:34:19.846) > > INFO>> SASL Login > (Fri Mar 13 2009 13:35:07.089) > > INFO>> SASL LDAP BIND with GSSAPI: Value of ldapStatus 82 > (Fri Mar 13 2009 13:35:07.089) > > ERROR>> LDAP BIND: Value of ldap failure status and text 82 Local > error > ============================================== > Using klist, it is verified that a Kerberos ticket exists and has > not expired. Besides this, what else should be done at the server's > end, or at the client's end? Any set-up issue? (the client has SASL > library and its GSSAPI plugin in place, already) > > Looking forward to help, > Xu Qiang > > > ------------------------------ > > _______________________________________________ > krbdev mailing list > krbdev at mit.edu > https://mailman.mit.edu/mailman/listinfo/krbdev > > > End of krbdev Digest, Vol 75, Issue 14 > ************************************** ------------------------------------------------------ The opinions expressed in this message are mine, not those of Caltech, JPL, NASA, or the US Government. Henry.B.Hotz at jpl.nasa.gov, or hbhotz at oxy.edu From paul.moore at centrify.com Mon Mar 16 17:57:44 2009 From: paul.moore at centrify.com (Paul Moore) Date: Mon, 16 Mar 2009 14:57:44 -0700 Subject: SASL authentication In-Reply-To: <11A1CB8A-266F-41E4-880D-5D03703D81F8@jpl.nasa.gov> References: <11A1CB8A-266F-41E4-880D-5D03703D81F8@jpl.nasa.gov> Message-ID: "That said, I've heard that a Windows DC will not accept an authenticated bind except over SSL/TLS. Period. Regardless of whether a SASL security layer is negotiated or not. If that's not it, then I'm sorry I can't help." Not so. GSS/SASL is its normal mode of operation. It is unusual to see an AD server with SSL turned on What it wont accept is plain text binds over unencrypted channels From rra at stanford.edu Mon Mar 16 18:46:54 2009 From: rra at stanford.edu (Russ Allbery) Date: Mon, 16 Mar 2009 15:46:54 -0700 Subject: SASL authentication In-Reply-To: <11A1CB8A-266F-41E4-880D-5D03703D81F8@jpl.nasa.gov> (Henry B. Hotz's message of "Mon\, 16 Mar 2009 14\:33\:45 -0700") References: <11A1CB8A-266F-41E4-880D-5D03703D81F8@jpl.nasa.gov> Message-ID: <87k56pgk69.fsf@windlord.stanford.edu> "Henry B. Hotz" writes: > That said, I've heard that a Windows DC will not accept an authenticated > bind except over SSL/TLS. Period. Regardless of whether a SASL > security layer is negotiated or not. This has now been fixed in a Microsoft hot fix, I believe. There was recent additional discussion in the kerberos at mit.edu mailing list. (Note that this specifically affected Windows 2008, not Windows 2003.) -- Russ Allbery (rra at stanford.edu) From hartmans at MIT.EDU Tue Mar 17 09:54:00 2009 From: hartmans at MIT.EDU (Sam Hartman) Date: Tue, 17 Mar 2009 09:54:00 -0400 (EDT) Subject: Enctype handling in client preauth2 system Message-ID: <20090317135400.2781E424A@carter-zimmerman.suchdamage.org> I'm implementing the encrypted challenge fast factor and I've run into what I believe is broken behavior in the client's handling of enctypes in the preauth loops spread between get_in_tkt.c and preauth2.c. Here's what happens today. krb5_get_init_creds has a local variable called etype that is initialized to 0. It's passed into krb5_do_preauth as a pointer. There, it is updated whenever a etype_info or etype_info2 is found. You would expect to find one of these both in a KDC preauth_required error or in a as reply. In an as reply, you'd expect only one entry, and you'd hope that entry corresponded to whatever the AS reply was actually encrypted in. This etype is passed into the internal preauth systems, but not into the plugins. The client_get_data procedure (a callback passed into plugins) has an option to get the etype that the as reply is actually encrypted in. It has no option to get the etype variable set by the etype-info2. Now, it's reasonable to assume in the as-reply case that these two etypes will be the same: if not, all sorts of stuff will break and you probably will not be able to decrypt the AS reply. Also, to get into that situation the KDC has to violate RFC 4120. However in the error case you want access to the etype_info2 so you know which client key to use. I propose to make the following changes: * Change the existing client_get_data call to return the etype tracked based on etype-info2 rather than the AS reply etype, so that it is useful in the error case. * Initialize the etype variable to the AS reply etype when we get the AS reply. That way, if you have no etype-info2 (which might happen for pkinit), it works correctly. --Sam From hartmans at painless-security.com Fri Mar 20 16:47:38 2009 From: hartmans at painless-security.com (Sam Hartman) Date: Fri, 20 Mar 2009 16:47:38 -0400 Subject: r21880: pkinit and k5-int.h Message-ID: r21879 introduced configuration macros into the pkinit sources for krb5.conf values that are used by pkinit. I think the general concept is fine, as discussed on jabber. However the definitions for these macros cannot live in the k5-int.h for the pkinit case. One of the goals of the pkinit plugin was to try and minimize internal dependencies and to use public interfaces where possible. We made an explicit decision that there was no good way to get pkinit ASN.1 encoders and decoders using public interfaces, so k5-int-pkinit.h was created. Rather than including k5-int.h in pkinit, the pkinit related configuration macros should be moved into a pkinit-specific header file. Probably a header in the pkinit sources would be better than k5-int-pkinit.h, but k5-int-pkinit.h would be better than k5-int.h. Reasons for doing this: 1) Consistency with explicit past decisions. 2) Eating our own dog food and trying as hard as we can to design pre-auth plugins the way we want others to do so so we can evaluate whether our interfaces are good enough 3) Establishing a modularity boundary; other parts of the code should not be looking at pkinit configuration parameters. From ghudson at MIT.EDU Sat Mar 21 00:35:46 2009 From: ghudson at MIT.EDU (Greg Hudson) Date: Sat, 21 Mar 2009 00:35:46 -0400 Subject: r21880: pkinit and k5-int.h In-Reply-To: References: Message-ID: <1237610146.6246.232.camel@ray> On Fri, 2009-03-20 at 16:47 -0400, Sam Hartman wrote: > One of the goals of the pkinit plugin was to try and minimize internal > dependencies and to use public interfaces where possible. We made an > explicit decision that there was no good way to get pkinit ASN.1 > encoders and decoders using public interfaces, so k5-int-pkinit.h was > created. No argument with your proposed change, but: pkinit_profile.c also uses k5-int.h and references context->profile. I assume it should be using krb5_get_profile? pkinit_accessor.c needs k5-int.h to get at the accessor structure for the aforementioned encoders; k5-int-pkinit.h is not sufficient. (The inclusion of k5-int.h in pkinit_profile.c and pkinit_accessor.c was what gave me the impression it would be okay to fix r21879 by including k5-int.h in other source files in that directory.) Is it okay use k5-platform.h in preauth plugins, under the theory that any plugin will have to deal with portability concerns in some fashion, and k5-platform is merely how we do so in our tree? (I have no specific use in mind at this time, but one might arise in the future.) From hartmans at painless-security.com Sat Mar 21 07:35:49 2009 From: hartmans at painless-security.com (Sam Hartman) Date: Sat, 21 Mar 2009 07:35:49 -0400 Subject: r21880: pkinit and k5-int.h In-Reply-To: <1237610146.6246.232.camel@ray> (Greg Hudson's message of "Sat\, 21 Mar 2009 00\:35\:46 -0400") References: <1237610146.6246.232.camel@ray> Message-ID: >>>>> "Greg" == Greg Hudson writes: Greg> On Fri, 2009-03-20 at 16:47 -0400, Sam Hartman wrote: >> One of the goals of the pkinit plugin was to try and minimize >> internal dependencies and to use public interfaces where >> possible. We made an explicit decision that there was no good >> way to get pkinit ASN.1 encoders and decoders using public >> interfaces, so k5-int-pkinit.h was created. Greg> No argument with your proposed change, but: Greg> pkinit_profile.c also uses k5-int.h and references Greg> context->profile. I assume it should be using Greg> krb5_get_profile? Yes.