From mohamed.chaari at orange-ftgroup.com Tue Jun 3 09:41:15 2008 From: mohamed.chaari at orange-ftgroup.com (mohamed.chaari@orange-ftgroup.com) Date: Tue, 3 Jun 2008 15:41:15 +0200 Subject: Messages format Message-ID: Hello, I want to add some fonctionnalities to kerberos, I would like to know where are defined the format of the messages (AP-REQ, AP-REP, TGS-REQ, TGS-REP...) Thanks, Regards From raeburn at MIT.EDU Wed Jun 4 09:56:14 2008 From: raeburn at MIT.EDU (Ken Raeburn) Date: Wed, 4 Jun 2008 09:56:14 -0400 Subject: Messages format In-Reply-To: References: Message-ID: On Jun 3, 2008, at 09:41, wrote: > Hello, > > I want to add some fonctionnalities to kerberos, I would like to know > where are defined the format of the messages (AP-REQ, AP-REP, TGS-REQ, > TGS-REP...) You mean the specifications? RFC 4120, at any IETF RFC mirror, has the ASN.1 specification of the messages. Or the code implementing it? In the MIT distribution, src/include/ krb5/krb5.hin and src/include/k5-int.h include the C data structures corresponding to various messages (and a bunch of other stuff), and src/lib/krb5/asn.1 has the code that converts between the C and network representations (but it's pretty ugly, hard to understand, and harder to modify). Ken From mohamed.chaari at orange-ftgroup.com Mon Jun 9 10:48:45 2008 From: mohamed.chaari at orange-ftgroup.com (mohamed.chaari@orange-ftgroup.com) Date: Mon, 9 Jun 2008 16:48:45 +0200 Subject: tgs files Message-ID: Hello, I want to modify the source code of TGS, I want to know in which file the TGS_REQ is created, I know after that in the src/kdc/do_tgs_req.c is done the treatment of the TGS_REQ et the creation of TGS_REP. But after, where is it treated the TGS_REP? Thanks. From jhutz at cmu.edu Tue Jun 10 21:48:08 2008 From: jhutz at cmu.edu (Jeffrey Hutzelman) Date: Tue, 10 Jun 2008 21:48:08 -0400 Subject: Proposed modifications to replay cache to prevent false positives In-Reply-To: <20080522193143.GM26388@Sun.COM> References: <20050602152141.C66A137010@arioch.imrryr.org> <1ceadc2255ade945fef537f9a3959d53@mit.edu> <482539BB.6080702@secure-endpoints.com> <20080520201624.GX26388@Sun.COM> <40A902FE-6807-416E-B1E8-C28C7D406383@mit.edu> <20080520224807.GG26388@Sun.COM> <20080522193143.GM26388@Sun.COM> Message-ID: <88D950C9F8090DBA0A49D0B4@sirius.fac.cs.cmu.edu> --On Thursday, May 22, 2008 02:31:43 PM -0500 Nicolas Williams wrote: > Yes. I know. I said "estimated" because the kernel can only tell you > how long it took to get to multi-user-server runlevel from the point > where it could start keeping time; the kernel can't tell you how long it > took the previous boot phases to complete (POST, BIOS, boot loaders, > ...). Maybe your kernel can do that, because your operating system has pulled into the kernel all sorts of machinery for managing services and the like which really has nothing to do with the kernel's primary tasks of managing memory, mediating access to devices, and scheduling the CPU(s). Most kernels have no idea what runlevel the system is at, because the whole concept of "runlevel" is one that belongs to a particular user-mode tool used in some systems. So they don't know when "runlevel 3" was entered; only init knows that. -- Jeff From jhutz at cmu.edu Tue Jun 10 22:24:08 2008 From: jhutz at cmu.edu (Jeffrey Hutzelman) Date: Tue, 10 Jun 2008 22:24:08 -0400 Subject: GSSAPI - context lifetime In-Reply-To: <87zlq7g1h8.fsf@windlord.stanford.edu> References: <9C71AD778A20DC47A9A1F89BFDD2C83B2367E2B0E5@ES05SNLNT.srn.sandia.gov> <87k5hcls8y.fsf@windlord.stanford.edu> <87zlq7g1h8.fsf@windlord.stanford.edu> Message-ID: --On Friday, May 30, 2008 10:12:35 AM -0700 Russ Allbery wrote: > Simon Wilkinson writes: > >> This issue appears from time to time on the OpenLDAP list. >> Unfortunately, Heimdal and MIT have different behaviours in this area - >> Heimdal allows gss_wrap() and unwrap() to be used within an expired >> context. The OpenLDAP code fails to handle the situation where these >> calls fail within the SASL layer, and hangs when attempting to perform >> connections with an expired context. Essentially, this means that MIT >> Kerberos cannot be used to back the GSSAPI SASL mechanism within their >> replication code, without requiring a server restart every time the GSS >> context expires. > > Yeah, the problem with SASL not knowing how to reauthenticate or see > expiration of sessions is a major problem, and I agree that this makes a > completely "formally" proper treatment of session expiration hard enough > that it may not be a good idea. There is nothing in the SASL specification which prohibits reauthentication. In fact, I have seen text in various places dealing with SASL security layers which covers the situation where a security layer being brought into use replaces an existing security layer, as might happen when a new security layer is brought into use following reauthentication. There is nothing in the SASL specification which prevents SASL framework implementations from informing the application of session expiration. In fact, there is nothing in the SASL specification which specifies anything at all about the interface between the SASL framework and applications. The behavior of applications like telnet and rsh is not to be emulated. A connection should not be allowed to persist forever, long after a user's employment has been terminated and his credentials revoked with prejudice, merely because it is an interactive session. Nor is it appropriate to base an argument on the behavior of SSH with public keys, for which there is no expiration mechanism. Generally, if credentials are valid only until a certain time, they should not be permitted to spawn sessions or actions which last beyond that time, except in unusual cases covered by specific policy. We have gone to great lengths on some occasions to correct bugs in which a TGS_REQ would result in tickets which expired later than the TGT used. Appropriate behavior for SSH, IMAP, HTTP, or any filesystem is to revoke access as soon as the user's credentials expire (note that SSH's gssapi and gssapi-with-mic userauth mechanisms do not do this, but that is because the SSH framework gives them control only when a connection is first established, not because behaving this way is a good idea). That said, the traditional model in GSS-API is for the mechanism to make a best effort to provide the requested service, and inform the caller of any state or potential problems such as replayed or out-of-sequence packets. This model calls for the mechanism to report failure only when it is genuinely unable to deliver the requested service, and not due to violation of some real or imagined policy or preference. I think it would be entirely consistent with this model for gss_Wrap and other per-message calls to return a successful but informative status code in this situation. However, as it turns out, GSS_S_CONTEXT_EXPIRED is a fatal status code. Only six "informative" status codes (those which indicate qualified success) are defined by RFC2743, including GSS_S_COMPLETE, GSS_S_CONTINUE_NEEDED (for context establishment), and four codes related to old, replayed, and out-of-sequence per-message tokens. Returning GSS_S_COMPLETE with a minor status code indicating the context is expired is Not An Option, because there is not and cannot be a minor status code with this meaning, for the simple reason that minor status codes are not standardized. Thus, there would be no way for an application which wishes to terminate the connection when a context expires (the correct behavior) to do so. I don't believe there is much wiggle room here. RFC2743 defines an error major_status code to be used by per-message operations when "context-related data items have expired, so that the requested operation cannot be performed". It does not actually require that this code be used, but it provides no other way to indicate this condition. So the only choices available to implementations are to indicate the condition by failing the operation with GSS_S_CONTEXT_EXPIRED, or ignore the problem and allow the operation to succeed with no indication that anything is wrong. Perhaps this is a suitable subject for discussion on the kitten WG mailing list. -- Jeff From jhutz at cmu.edu Tue Jun 10 22:37:01 2008 From: jhutz at cmu.edu (Jeffrey Hutzelman) Date: Tue, 10 Jun 2008 22:37:01 -0400 Subject: Messages format In-Reply-To: References: Message-ID: <605FD29FBE0E3977C36C5A2F@sirius.fac.cs.cmu.edu> --On Tuesday, June 03, 2008 03:41:15 PM +0200 mohamed.chaari at orange-ftgroup.com wrote: > I want to add some fonctionnalities to kerberos, I would like to know > where are defined the format of the messages (AP-REQ, AP-REP, TGS-REQ, > TGS-REP...) As Ken pointed out, the formats and semantics of core Kerberos messages are defined in RFC4120, available from . The Kerberos cryptographic framework is described in RFC3961. There are also a number of other documents which describe various extensions to the Kerberos protocol, including the AES enctypes (RFC3962), PKINIT (RFC4556, RFC4557), enctype negotiation (RFC4537), and others. There are also a number of additional extensions and changes currently being worked on by the IETF's Kerberos Working Group; a list of these is available at . If you are interested in helping to extend the Kerberos protocol, I encourage you to subscribe to the Kerberos Working Group mailing list at and to become active in the working group. However, bear in mind that the purpose of krb-wg is to define and standardize the Kerberos protocol, so questions about the details of MIT's implementation are more appropiate here. -- Jeffrey T. Hutzelman (N3NHS) Co-chair, IETF Kerberos Working Group Carnegie Mellon University - Pittsburgh, PA From daniel.atallah at gmail.com Wed Jun 11 11:56:00 2008 From: daniel.atallah at gmail.com (Daniel Atallah) Date: Wed, 11 Jun 2008 11:56:00 -0400 Subject: krb5_cc_default_name() can return NULL, but is passed directly to strcmp() Message-ID: I've been running into an issue where occasionally when there's a network change, I'm running into a crash because a NULL pointer is passed to strcmp(). To provide some background, I'm using the MIT Kerberos for Windows GSSAPI (version 3.2.2) functionality in the GSSAPI plugin for Cyrus-SASL. Immediately before the crash, an error popup is displayed saying: Internal credentials cache error (Kerberos error 196) krb5_cc_next_cred() failed The crash occurs as soon as I dismiss the popup. A partially complete stacktrace is below; I'm not sure why it isn't unwinding the last frames correctly to get to where the strcmp is actually called, I've seen this sometimes with the utility i'm using (exchndl.dll from the mingw-tools). I think it is somehow getting messed up by the leash dll being loaded dynamically. ------------------- Error occured on Tuesday, June 10, 2008 at 08:26:04. Windows Version 5.1 Build 2600 Service Pack 2 C:\devel\pidgin-devel\build\pidgin.exe caused an Access Violation at location 77c47740 in module C:\WINDOWS\system32\msvcrt.dll Reading from location 00000000. Registers: eax=00000000 ebx=06d3dc28 ecx=0022ea2c edx=00000000 esi=071642bc edi=0022eb2c eip=77c47740 esp=0022e9d4 ebp=0022eb2c iopl=0 nv up ei pl zr na po nc cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00210246 Call stack: C:\WINDOWS\system32\msvcrt.dll [7.0.2600.2180] 77C47740 C:\WINDOWS\system32\msvcrt.dll strcmp C:\devel\pidgin-devel\build\gssapi32.dll [1.6.3.16] 1C002BF1 C:\devel\pidgin-devel\build\gssapi32.dll acquire_init_cred c:\temp\kfw\src\athena\auth\krb5\src\lib\gssapi\krb5\acquire_cred.c:306 1C001FA5 C:\devel\pidgin-devel\build\gssapi32.dll krb5_gss_acquire_cred c:\temp\kfw\src\athena\auth\krb5\src\lib\gssapi\krb5\acquire_cred.c:560 1C001620 C:\devel\pidgin-devel\build\gssapi32.dll kg_get_defcred c:\temp\kfw\src\athena\auth\krb5\src\lib\gssapi\krb5\gssapi_krb5.c:148 1C00466C C:\devel\pidgin-devel\build\gssapi32.dll krb5_gss_init_sec_context c:\temp\kfw\src\athena\auth\krb5\src\lib\gssapi\krb5\init_sec_context.c:882 1C00A4CF C:\devel\pidgin-devel\build\gssapi32.dll k5glue_init_sec_context c:\temp\kfw\src\athena\auth\krb5\src\lib\gssapi\krb5\krb5_gss_glue.c:680 1C00D83C C:\devel\pidgin-devel\build\gssapi32.dll gss_init_sec_context c:\temp\kfw\src\athena\auth\krb5\src\lib\gssapi\mechglue\g_init_sec_context.c:225 C:\devel\pidgin-devel\build\sasl2\saslGSSAPI.dll [2.1.22.0] 01AD295A C:\devel\pidgin-devel\build\sasl2\saslGSSAPI.dll I was going to report this to the krb5-bugs list, but I couldn't find the krb5-send-pr program, so I figured I'd try here. If I should be reporting this in a different way, please let me know. Thanks, -D From kulg123 at gmail.com Thu Jun 12 05:28:25 2008 From: kulg123 at gmail.com (kul gupta) Date: Thu, 12 Jun 2008 14:58:25 +0530 Subject: GSSAPI+kerberose5 Message-ID: <2203f95e0806120228y6dde033dhaf41aa763f59d2e0@mail.gmail.com> Hello I am very new to GSSAPI and kerberose. There are certain queries .I will be highly thankful if u can help me out in clearing my doubts. I want to use GSSAPI with kerberose v5 for my client and server authentication when i check my system-Red Hat enterprise Linux 5.0, there is already kerberose 1.5.17 installed and also cyrus SASL 2.1.22 is there. 1 )I think that GSSAPI by defualt uses kerberose mechanism so i need not specify it explicilty Am i right?? 2)what are the pre-requisites for using GSSAPI in my application using kerbeose mechanism. 3) Please let me know in steps how to proceed for my application who wants to use GSSAPI with kerberose . I was going through the sunmicrosystems site where GSSAPI is explained with the example. http://docs.sun.com/app/docs/doc/816-4863/sampleprogs-1?a=view Can i go with that example of client and server with the version already installed in my system Thanks Regards Kul From kulg123 at gmail.com Sun Jun 15 11:48:41 2008 From: kulg123 at gmail.com (kul gupta) Date: Sun, 15 Jun 2008 21:18:41 +0530 Subject: help Message-ID: <2203f95e0806150848k10973896ie082f11431849df0@mail.gmail.com> I am very new to kerborose and GSSAPI I will highly appreciate for the guidance for the issues below- I am bit confused about cyrus SASL and GSSAPI I have an authentication server (AS) which is kerborised Client gets the TGT using -kinit Now i need to use GSSAPI for authentication using GSSAPI 1) DO i need to have cyrus SASL also ?? or only kerborose will do?? 2) When i tried to run the example provided by SUN , i am getting following errors- gssapi_ext.h- No such file directory gssapi-misc.h-No such file directory I also tried to search these files in my system(Red hat enterprise linux 5.0),but these files are not present. I will be highly thankful if u can help me out for the same . Regards Ruchita From mohamed.chaari at orange-ftgroup.com Mon Jun 16 11:04:19 2008 From: mohamed.chaari at orange-ftgroup.com (mohamed.chaari@orange-ftgroup.com) Date: Mon, 16 Jun 2008 17:04:19 +0200 Subject: kinit Message-ID: Hello, I want to know if using kinit I will have the services ticket or not. Thanks From kulg123 at gmail.com Wed Jun 18 00:23:56 2008 From: kulg123 at gmail.com (kul gupta) Date: Wed, 18 Jun 2008 09:53:56 +0530 Subject: help Message-ID: <2203f95e0806172123m65b60d87k438cad7a97961eb1@mail.gmail.com> Hello Thanks a lot for ur valuable guidance I am using-RedHatEnterprise Linux 5.0 and using Netbeans IDE to build the code and compiler is gcc ( for the code given in the SUN example) 1)There is AS server which is kerborized.I did the settings for the kerborized client also. 2)After obtaining the TGT (using kinit command from the client side),how should i proceed using the example given in SUN 3)I think mechanism used in GSSAPI by default is kerberos V5. So i need not specify it explicitly.?? Am i right. Can u please help me out in brief the steps i need to do for the same.. Please let me know to proceed. I will highly appreciate if someone can guide me on the same Thanks Ruchita From kulg123 at gmail.com Wed Jun 18 00:23:56 2008 From: kulg123 at gmail.com (kul gupta) Date: Wed, 18 Jun 2008 09:53:56 +0530 Subject: help Message-ID: <2203f95e0806172123m65b60d87k438cad7a97961eb1@mail.gmail.com> Hello Thanks a lot for ur valuable guidance I am using-RedHatEnterprise Linux 5.0 and using Netbeans IDE to build the code and compiler is gcc ( for the code given in the SUN example) 1)There is AS server which is kerborized.I did the settings for the kerborized client also. 2)After obtaining the TGT (using kinit command from the client side),how should i proceed using the example given in SUN 3)I think mechanism used in GSSAPI by default is kerberos V5. So i need not specify it explicitly.?? Am i right. Can u please help me out in brief the steps i need to do for the same.. Please let me know to proceed. I will highly appreciate if someone can guide me on the same Thanks Ruchita From mc at suse.de Wed Jun 18 04:43:33 2008 From: mc at suse.de (Michael Calmer) Date: Wed, 18 Jun 2008 10:43:33 +0200 Subject: krb5-1.6.4-beta1 is available In-Reply-To: References: Message-ID: <200806181043.39014.mc@suse.de> Hi, Am Dienstag, 25. M?rz 2008 schrieb Tom Yu: > MIT krb5-1.6.4-beta1 is now available for download from Since 3 month we have now Beta1. When will there be the final release? And an additional question. What is the status of 1.7 release? -- MFG Michael Calmer -------------------------------------------------------------------------- Michael Calmer SUSE LINUX Products GmbH, Maxfeldstr. 5, D-90409 Nuernberg T: +49 (0) 911 74053 0 F: +49 (0) 911 74053575 - e-mail: Michael.Calmer at suse.com -------------------------------------------------------------------------- SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG N?rnberg) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part. Url : http://mailman.mit.edu/pipermail/krbdev/attachments/20080618/ae38f430/attachment.bin From jaltman at secure-endpoints.com Wed Jun 18 11:19:00 2008 From: jaltman at secure-endpoints.com (Jeffrey Altman) Date: Wed, 18 Jun 2008 11:19:00 -0400 Subject: Any objections to applying the latest patch in 5924? Message-ID: <48592764.4020501@secure-endpoints.com> Please review the replay collision reduction patch in 5924. The original contribution was from Nik Conwell at Boston University. I've revised it to make it easier to read. I believe it should be committed and will do so after someone on the Consortium team reviews it. Jeffrey Altman -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3355 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.mit.edu/pipermail/krbdev/attachments/20080618/126402d9/smime.bin From tlyu at MIT.EDU Wed Jun 18 11:24:05 2008 From: tlyu at MIT.EDU (Tom Yu) Date: Wed, 18 Jun 2008 11:24:05 -0400 Subject: Any objections to applying the latest patch in 5924? In-Reply-To: <48592764.4020501@secure-endpoints.com> (Jeffrey Altman's message of "Wed, 18 Jun 2008 11:19:00 -0400") References: <48592764.4020501@secure-endpoints.com> Message-ID: Jeffrey Altman writes: > Please review the replay collision reduction patch in 5924. > The original contribution was from Nik Conwell at Boston University. > I've revised it to make it easier to read. I believe it should > be committed and will do so after someone on the Consortium team > reviews it. The patch adds a special meaning to a microseconds argument of -1 passed to krb5_set_real_time(). This is an API change. Who is calling this API, and will this cause problems for them? From jaltman at secure-endpoints.com Wed Jun 18 13:28:18 2008 From: jaltman at secure-endpoints.com (Jeffrey Altman) Date: Wed, 18 Jun 2008 13:28:18 -0400 Subject: Any objections to applying the latest patch in 5924? In-Reply-To: References: <48592764.4020501@secure-endpoints.com> Message-ID: <485945B2.2080306@secure-endpoints.com> Tom Yu wrote: > Jeffrey Altman writes: > >> Please review the replay collision reduction patch in 5924. >> The original contribution was from Nik Conwell at Boston University. >> I've revised it to make it easier to read. I believe it should >> be committed and will do so after someone on the Consortium team >> reviews it. > > The patch adds a special meaning to a microseconds argument of -1 > passed to krb5_set_real_time(). This is an API change. Who is > calling this API, and will this cause problems for them? A brief Google search reveals that krb5_set_real_time() is used internally to the krb5 libraries and was exported so that it can be called by Samba so that the real time can be set to the CIFS server time specified in an authentication failure response. Given its purpose I cannot imagine a use case in which a negative microseconds value would actually be valid? Are there any real world systems in which time is reported as S seconds U microseconds where U is negative? This bug is serious and is widely causing problems. At a minimum for Cornell, many users of modauthkerb, and my clients. I believe it should be fixed. 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/20080618/22f629f7/smime.bin From tlyu at MIT.EDU Wed Jun 18 13:46:28 2008 From: tlyu at MIT.EDU (Tom Yu) Date: Wed, 18 Jun 2008 13:46:28 -0400 Subject: please review draft krb5 API reference manual Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The MIT Kerberos Consortium has hired a contract technical writer, Elizabeth Stone, to improve the krb5 API documentation. The following is her review memo outlining the feedback we request on this documentation. Please send comments to her at . ==================== Greetings, This is a draft of the krb5 API reference manual, written in response to complaints about the available documentation. The intended audience is Kerberos application developers with varying degrees of familiarity with Kerberos. The review release files are in http://web.mit.edu/estone/www/. - --What does a newbie need to know? - --If a developer is Kerberizing an existing application, what information would make it easier? - --If a new developer is upgrading an application that was Kerberized by someone else 3 years ago, how can we help them? No-one wants to read documentation -- they want to get their information and go back to work. Nothing is obvious to the uninformed -- if you see information that would only make sense to an experienced Kerberos application developer, mark it. In general, review for technical accuracy and completeness. YOU DO NOT HAVE TO REVIEW THE ENTIRE THING. Let me know what parts you did review, and/or any topics you are particularly interested in. DEADLINE: June 25 I need your feedback -- if you can't make the deadline, please let me know when you can send your review comments. ABOUT THIS DRAFT This draft release contains the following files (which can be found at http://web.mit.edu/estone/www/): draftkrb5.hin Annotated header file KRB5API.doxyfile Doxyfile, used to generate output from source file html.zip HTML output, generated by the above files You can generate other output formats. Install doxgen, version 1.5.5 and above, on your computer and modify the input and output settings in KRB5API.doxyfile. The output might look REALLY ugly. Please note the glitches and return with your review comments. See doxygen.org for information on doxygen. WHAT TO REVIEW --Technical accuracy --Completeness (should there be more detail?) --Anything marked ?? --Anything on the ToDo list that isn't marked ers --Missing structure, #def, and field descriptions --Terminology accuracy and consistency (is the same entity consistently described by the same term?) You might find some content redundant -- it's probably intentional, and part of technical writing style. Comment it if you aren't sure. Would you find the following things useful? - --In Introduction, a concise description of the programming model-- or would a link to Kerberos site be enough? - --A glossary - --A link to external error code tables - --Deprecated fcns linked to replacement fcns WHAT TO IGNORE --Consistent format of doxygen comment blocks --Grouping and subgrouping in navigation tree --Links between #defs, fcn parameter descriptions, and structure field descriptions --Consistent typeface formatting. I will be using the following conventions: -parameters, flags, and fields in italics -#defs, error codes, fcn and structure names in courier font --Writing style/grammar of running text --Strict adherence to ASN.1 style --C++ terminology --ToDo items marked ers --Glossary entries REVIEW INPUT Mark your comments with references to the to fcn, structure, field, etc. You can use line numbers in the source file if you like. Please use any Windows-readable format -- flat text is fine. If you annotate the header file with your comments, please rename it before you send it back to me. THANK YOU! ers *You might find the following sites useful:* Kerberos Wiki http://k5wiki.kerberos.org/ Existing Kerberos documentation, http://web.mit.edu/kerberos/ Sun (GSS-API) http://docs.sun.com/app/docs/doc/816-4863 OpenVMS documentation http://h71000.www7.hp.com/doc/83final/BA554_90008/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (SunOS) iEYEARECAAYFAkhZSfcACgkQSO8fWy4vZo6yyQCgqPoBTNXrZtKJ3HsqdegfTA4S GRgAoN15ay9u1/Awd++G8vnd94Biq6h9 =+VX5 -----END PGP SIGNATURE----- From jaltman at secure-endpoints.com Wed Jun 18 14:23:18 2008 From: jaltman at secure-endpoints.com (Jeffrey Altman) Date: Wed, 18 Jun 2008 14:23:18 -0400 Subject: Ticket 5442 - Memory Leak in gss_accept_sec_context and minor_status destruction Message-ID: <48595296.2090702@secure-endpoints.com> I have updated ticket 5442 with a patch to gss_accept_sec_context() that addresses two issues that were originally reported in 1.4.x but are still present on the trunk. (a) In the case where 'cred_handle' != 'verifier_cred_handle'[1] krb5_gss_accept_sec_context() leaks the 'cred_handle' in the success case and the failure cases that result in returning from the function prior to reaching the end of the function. (b) The meaningful 'minor_status' return value is destroyed during the cleanup operations. The approach taken is to add a new 'exit:' label prior to the end of the function through which all function returns after reaching the 'fail:' label will goto. After 'exit:', the 'cred_handle' will be released and if there is a krb5_context 'context' to be freed, the error info will be saved and krb5_free_context() will be called. In the success case, the krb5_context is saved in the gss context and we now set 'context' to NULL to prevent it from being freed. In order to preserve the minor_status return code, a 'tmp_minor_status' variable is added that is used after the 'fail:' label in calls to krb5_gss_delete_sec_context() and krb5_gss_release_cred(). [1] If 'verifier_cred_handle' is non-NULL, then 'cred_handle' is set to the value of 'verifier_cred_handle'. I would be happy to commit this patch once it has received the review of Consortium staff members. 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/20080618/453e3b50/smime.bin From tlyu at MIT.EDU Wed Jun 18 14:44:58 2008 From: tlyu at MIT.EDU (Tom Yu) Date: Wed, 18 Jun 2008 14:44:58 -0400 Subject: Any objections to applying the latest patch in 5924? In-Reply-To: <485945B2.2080306@secure-endpoints.com> (Jeffrey Altman's message of "Wed, 18 Jun 2008 13:28:18 -0400") References: <48592764.4020501@secure-endpoints.com> <485945B2.2080306@secure-endpoints.com> Message-ID: Jeffrey Altman writes: > A brief Google search reveals that krb5_set_real_time() is used > internally to > the krb5 libraries and was exported so that it can be called by Samba > so that > the real time can be set to the CIFS server time specified in an > authentication > failure response. Is the call within the krb5 library not sufficient for the CIFS use? > Given its purpose I cannot imagine a use case in which a negative > microseconds > value would actually be valid? Are there any real world systems in > which time is > reported as S seconds U microseconds where U is negative? > > This bug is serious and is widely causing problems. At a minimum for > Cornell, > many users of modauthkerb, and my clients. I believe it should be > fixed. Go ahead and commit your change, and make a note that documentation needs to be updated. We should also fix the KDC side of this problem. From jaltman at secure-endpoints.com Wed Jun 18 14:55:03 2008 From: jaltman at secure-endpoints.com (Jeffrey Altman) Date: Wed, 18 Jun 2008 14:55:03 -0400 Subject: Any objections to applying the latest patch in 5924? In-Reply-To: References: <48592764.4020501@secure-endpoints.com> <485945B2.2080306@secure-endpoints.com> Message-ID: <48595A07.6030900@secure-endpoints.com> Tom Yu wrote: > Jeffrey Altman writes: > >> A brief Google search reveals that krb5_set_real_time() is used >> internally to >> the krb5 libraries and was exported so that it can be called by Samba >> so that >> the real time can be set to the CIFS server time specified in an >> authentication >> failure response. > > Is the call within the krb5 library not sufficient for the CIFS use? They are trying with the offset determined from the KDC but when that fails they call krb5_set_real_time() with the time presented by the CIFS Server. They then retry with the new offset value. >> Given its purpose I cannot imagine a use case in which a negative >> microseconds >> value would actually be valid? Are there any real world systems in >> which time is >> reported as S seconds U microseconds where U is negative? >> >> This bug is serious and is widely causing problems. At a minimum for >> Cornell, >> many users of modauthkerb, and my clients. I believe it should be >> fixed. > > Go ahead and commit your change, and make a note that documentation > needs to be updated. > We should also fix the KDC side of this problem. I will do so and note the documentation change in the ticket. (or should a new doc queue be created and a doc change request be inserted there? that is what we do for openafs) 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/20080618/7960af19/smime-0001.bin From jaltman at secure-endpoints.com Wed Jun 18 15:22:05 2008 From: jaltman at secure-endpoints.com (Jeffrey Altman) Date: Wed, 18 Jun 2008 15:22:05 -0400 Subject: Ticket 5895 - race conditions in memory ccaches Message-ID: <4859605D.3070509@secure-endpoints.com> Ticket 5895 discusses race conditions in krb5_mcc_initialize() and krb5_mcc_destroy(). I have reviewed the patch provided and have attached a revised version for review. I will be happy to commit this change after it has been reviewed by Consortium staff members. 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/20080618/e8c797dd/smime.bin From jaltman at secure-endpoints.com Wed Jun 18 16:33:01 2008 From: jaltman at secure-endpoints.com (Jeffrey Altman) Date: Wed, 18 Jun 2008 16:33:01 -0400 Subject: Proposal to change the meaning of -allow_tix +allow_svr aka KRB5_KDB_DISALLOW_ALL_TIX & !KRB5_KDB_DISALLOW_SVR Message-ID: <485970FD.9010109@secure-endpoints.com> I apologize for the cross-posting but I believe that in order for this proposal receive adequate feedback that it must be discussed among both the MIT Kerberos administrator and MIT Kerberos Developer communities. In the current implementation of the MIT KDC there are two principal policy flags that interact in what I believe is an undesirable way when applied to service principals. Copying from the Kerberos v5 System Administrator's Guide: *{-|+}allow_svr* The ?-allow_svr? flag prohibits the issuance of service tickets for this principal. ?+allow_svr? clears this flag. In effect, ?-allow_svr? sets the KRB5_KDB_DISALLOW_SVR flag on the principal in the database. *{-|+}allow_tix* The ?-allow_tix? option forbids the issuance of any tickets for this principal. ?+allow_tix? clears this flag. The default is ?+allow_tix?. In effect, ?-allow_tix? sets the KRB5_KDB_DISALLOW_ALL_TIX flag on the principal in the database. When a TGS or AS request is received by the KDC, under the current implementation the KDC will examine the client principal to determine whether or not +allow_tix is set. If not, it will reject the request. It also naturally checks the service principal to determine whether or not +allow_svr is set. If not, it will reject the request. However, the KDC will also check the service principal to determine it it is +allow_tix or not. If it is not, then the KDC will also reject the request. I believe that the meaning of allow_tix should be altered such that it only applies to the client in a TGS or AS request. This would permit -allow_tix to be applied to a service principal and ensure that no client ticket requests can be satisfied for that service principal while at the same time permitting other principals to obtain service tickets. Organizations that wish to disable the issuance of service tickets for the service principal would apply -allow_svr to the principal in addition to -allow_tix. I believe that making this change would permit a more robust security policy to be applied to service principals without requiring the additional of new flags that would have overlapping and conflicting meaning with the existing flags. Let the discussion begin. Jeffrey Altman Secure Endpoints Inc. -------------- 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/20080618/27478d35/smime.bin From raeburn at MIT.EDU Wed Jun 18 16:54:04 2008 From: raeburn at MIT.EDU (Ken Raeburn) Date: Wed, 18 Jun 2008 16:54:04 -0400 Subject: Proposal to change the meaning of -allow_tix +allow_svr aka KRB5_KDB_DISALLOW_ALL_TIX & !KRB5_KDB_DISALLOW_SVR In-Reply-To: <485970FD.9010109@secure-endpoints.com> References: <485970FD.9010109@secure-endpoints.com> Message-ID: On Jun 18, 2008, at 16:33, Jeffrey Altman wrote: > I believe that the meaning of allow_tix should be altered such that > it only applies to the client > in a TGS or AS request. This would permit -allow_tix to be applied > to a service principal > and ensure that no client ticket requests can be satisfied for that > service principal while at > the same time permitting other principals to obtain service tickets. > Organizations that wish to disable the issuance of service tickets > for the service principal > would apply -allow_svr to the principal in addition to -allow_tix. I think it should be pointed out that such a change would allow tickets to start being issued where currently they would not when the KDC software gets updated -- even if the latter really was the intent of the realm administrator. Because of that, we might instead want to create a new flag with the semantics Jeff wants, and leave the existing flag with its current (suboptimal) behavior. Ken From jaltman at secure-endpoints.com Wed Jun 18 17:01:59 2008 From: jaltman at secure-endpoints.com (Jeffrey Altman) Date: Wed, 18 Jun 2008 17:01:59 -0400 Subject: Ticket 5338: Race conditions in key rotation Message-ID: <485977C7.8060501@secure-endpoints.com> Ticket 5338 describes a race condition that occurs whenever a TGS key is rotated. In a multi-KDC environment, when a TGS key is updated there is going to be a period of time during which only the Master KDC is going to have a copy of the key. The slaves will not obtain a copy of the key until the Master has finished propagating its database. Depending upon the size of the database and the frequency of propagations (even assuming there is incremental propagation) there is only going to be some window during which a client could obtain a TGT from the Master and then try to present it to a slave and end up receiving a failure. In the current implementation the sendto_kdc() function will return a value indicating whether or not the master kdc was contacted. However, only the krb5_get_init_creds_password and krb5_get_init_creds_keytab functions will actually perform a retry against the KDC on failure. In order to address this race condition I propose that krb5_send_tgs() be modified to retry against the master KDC whenever there is an error and the error is not one of KRB5_KDC_UNREACH or KRB5_REALM_CANT_RESOLVE. If such as patch was written, would the Consortium accept it? Thanks 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/20080618/bdf73068/smime-0001.bin From Nicolas.Williams at sun.com Wed Jun 18 17:13:44 2008 From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Wed, 18 Jun 2008 16:13:44 -0500 Subject: Proposal to change the meaning of -allow_tix +allow_svr aka KRB5_KDB_DISALLOW_ALL_TIX & !KRB5_KDB_DISALLOW_SVR In-Reply-To: References: <485970FD.9010109@secure-endpoints.com> Message-ID: <20080618211343.GI2735@Sun.COM> On Wed, Jun 18, 2008 at 04:54:04PM -0400, Ken Raeburn wrote: > On Jun 18, 2008, at 16:33, Jeffrey Altman wrote: > > I believe that the meaning of allow_tix should be altered such that > > it only applies to the client > > in a TGS or AS request. This would permit -allow_tix to be applied > > to a service principal > > and ensure that no client ticket requests can be satisfied for that > > service principal while at > > the same time permitting other principals to obtain service tickets. > > Organizations that wish to disable the issuance of service tickets > > for the service principal > > would apply -allow_svr to the principal in addition to -allow_tix. > > I think it should be pointed out that such a change would allow > tickets to start being issued where currently they would not when the > KDC software gets updated -- even if the latter really was the intent > of the realm administrator. Because of that, we might instead want to > create a new flag with the semantics Jeff wants, and leave the > existing flag with its current (suboptimal) behavior. Or provide a migration script. From raeburn at MIT.EDU Wed Jun 18 17:23:05 2008 From: raeburn at MIT.EDU (Ken Raeburn) Date: Wed, 18 Jun 2008 17:23:05 -0400 Subject: Ticket 5338: Race conditions in key rotation In-Reply-To: <485977C7.8060501@secure-endpoints.com> References: <485977C7.8060501@secure-endpoints.com> Message-ID: On Jun 18, 2008, at 17:01, Jeffrey Altman wrote: > In order to address this race condition I propose that krb5_send_tgs() > be modified to retry against the master KDC whenever there is an > error and the error is not one of KRB5_KDC_UNREACH or > KRB5_REALM_CANT_RESOLVE. What's the actual error that would be returned in such a case? Wouldn't it make sense to do the retry only for one specific error? A better approach may be to finish up and implement a design that's been discussed before, which is to allow creation of a key in the database without enabling it for use, and then separately enabling it later. This would also be desirable for services like AFS where you need to distribute a new key to multiple servers before you can start using it. (This may also relate, at least a bit, to a project Will Fiveash is helping us with, on-the-fly master key rollover. There are enough special things about the master key that it may not be all that relevant though.) I think there's been some public discussion in archives somewhere, maybe in the context of set/change pw protocols. I don't recall if server-side (keytab) changes would be needed as well. Ken From jaltman at secure-endpoints.com Wed Jun 18 18:41:27 2008 From: jaltman at secure-endpoints.com (Jeffrey Altman) Date: Wed, 18 Jun 2008 18:41:27 -0400 Subject: Ticket 5338: Race conditions in key rotation In-Reply-To: References: <485977C7.8060501@secure-endpoints.com> Message-ID: <48598F17.4070901@secure-endpoints.com> Ken Raeburn wrote: > On Jun 18, 2008, at 17:01, Jeffrey Altman wrote: >> In order to address this race condition I propose that krb5_send_tgs() >> be modified to retry against the master KDC whenever there is an >> error and the error is not one of KRB5_KDC_UNREACH or >> KRB5_REALM_CANT_RESOLVE. > > What's the actual error that would be returned in such a case? KRB5KRB_ERR_GENERIC with the error text specifying a kvno not found. > Wouldn't it make sense to do the retry only for one specific error? I don't think so. I think that any misconfiguration of a slave kdc should result in the master being asked since the master's response is going to be definitive. > A better approach may be to finish up and implement a design that's > been discussed before, which is to allow creation of a key in the > database without enabling it for use, and then separately enabling it > later. This is absolutely a good long term project but it doesn't help the clients that are going to be stuck talking to old KDCs. The retry change is much smaller and doesn't require any server upgrades or key management process changes to take effect. I want to see the key rollover management changes but I think it is an orthogonal problem. Jeffrey Altman From elric at imrryr.org Thu Jun 19 01:59:45 2008 From: elric at imrryr.org (Roland Dowdeswell) Date: Thu, 19 Jun 2008 01:59:45 -0400 Subject: Ticket 5338: Race conditions in key rotation In-Reply-To: Your message of "Wed, 18 Jun 2008 17:23:05 EDT." Message-ID: <20080619055945.C9D2F37044@arioch.imrryr.org> On 1213824185 seconds since the Beginning of the UNIX epoch Ken Raeburn wrote: > >On Jun 18, 2008, at 17:01, Jeffrey Altman wrote: >> In order to address this race condition I propose that krb5_send_tgs() >> be modified to retry against the master KDC whenever there is an >> error and the error is not one of KRB5_KDC_UNREACH or >> KRB5_REALM_CANT_RESOLVE. > >What's the actual error that would be returned in such a case? >Wouldn't it make sense to do the retry only for one specific error? > >A better approach may be to finish up and implement a design that's >been discussed before, which is to allow creation of a key in the >database without enabling it for use, and then separately enabling it >later. This would also be desirable for services like AFS where you >need to distribute a new key to multiple servers before you can start >using it. (This may also relate, at least a bit, to a project Will >Fiveash is helping us with, on-the-fly master key rollover. There are >enough special things about the master key that it may not be all that >relevant though.) I think there's been some public discussion in >archives somewhere, maybe in the context of set/change pw protocols. >I don't recall if server-side (keytab) changes would be needed as well. So, this is going to be a bit of a long e-mail so let me apologise in advance. I think that I'm going to try to structure my thoughts into a few sections as there are a few rather distinct topics that are all intertwined. Failing back to the master on failures is not simply about key rotation. I have been thinking about just implementing the failover to the master at work but I have been holding off on it because I would rather see it implemented in the main release than maintain [yet another] independent patch. It's a little late, so this e-mail may be a bit conversational. Failing over the Master on all Failures --------------------------------------- Failing over to the master on failures is an easy and seamless way to provide a consistent view of a completely up to date Kerberos database at any time when the master is reachable. This is not merely an issue of solving a race here or there. It is about designing a system which with as little state as possible can present a view to its client libraries that allows changes to be effective immediately [almost all the time] without having the master KDC have to block changes until each of the slaves has accepted it. There is one case in which this is currently done. Password changes. It works. I proposed this in RT 5338 to solve the TGS key rotation race. It does this simply. But there are other changes that are made to the Kerberos database such as the addition of service principals which would benefit from failing back to the master in every case. If we implement this, then the addition of service keys will appear to be instant instead of having to suffer through propagation delays. How about passwords being expired? IIRC, I've seen this fail after my password change because the change has not yet propagated to the slave that I queried in the past. In fact, I would go so far as to say, that I would not need incremental propagation if this feature were implemented. It would probably be sufficient to sync the KDCs every 5 or 10 minutes or so given that important changes would appear to be instant. Or clock skew errors? Why should a runaway clock on a single slave cause potentially plant-wide semi-random outages if the rest of the KDCs are properly in sync? What happens when a slave gets a little corrupted? How about some level of DB corruption? Truncated database? Configuration errors? What if a misconfiguration causes the master to fail to propagate to the slave for some period of time? What if kpropd crashes? What if we put a slave into krb5.conf before we bring it live? What if a KDC from the wrong realm gets mis-set in our configuration? Etc. Failures on slaves should not be considered to be permanent errors given that we know up front that there is a more canonical source of truth just a few lines away in the configuration file... Given that errors on the KDC are actually quite rare in comparison to valid requests, I think that trying the master will not significantly or noticeably increase the load on the master. And I do not think that we should decide to try to enumerate the kinds of errors that will cause the clients to fail back to the master. If anything, we should fail back as a default and then enumerate errors that we believe to be fatal if a slave considers it to be fatal such as trying to renew a non-renewable ticket. Unforseen errors, though, should default back to giving the master a crack at it. In fact, the concept of failing back to the master on incorrect passwords was a great idea. The main failure was that only that was implemented---that is, the default was to consider slave errors to be permanent rather than defaulting to failing back to the most up to date DB on any error. TGS Key Rotation ---------------- So, the rotation of the TGS key is the specific case within key rotation where clients failing back to the master solves the issue. Although you could solve the problem by setting the key and then at some later date enabling it once you know that every slave has a new copy of the key, this is more complicated and less robust than simply failing back to the master on errors. E.g. let's say that I've got 20 slaves. What does the process actually look like? Well, let's see. I provision the new TGS key. Then I confirm that each and every one of the 20 slaves has the new key. What if one of them is down? Do I wait? Do I continue? What I do is suspend my automated TGS key rotation scheme and wait for human intervention. Unless I build in more complicated logic where if a slave reboots, it must somehow determine that it is out of sync and fail to start krb5kdc. This additional logic then adds its own issues which I need to grok in order to feel comfortable that I am now provided a KDC infrastructure that delivers the appropriate SLA to the plant. Honestly, I'd rather live with the current short race than start down this path. The KDC plant must be simple enough that if I am woken up at 4.15am with a production outage I can simply and efficiently reason about how it works before I get an espresso. ``Normal'' Service Key Rotation ------------------------------- Service key rotation is not related to failing back to the master on all Kerberos failures. For service key rotation, the answer is not to modify the KDC but rather change the behaviour of the key rotation to be: 1. client queries master KDC to determine highest kvno K, 2. client chooses new key, 3. client installs key in all relevent keytabs as kvno K, 4. client tells master KDC to update to new key. I don't see what real benefit there is in introducing the state of such a transaction to the KDC. It's simply a matter of getting the ordering correct. If you have keys on multiple hosts, step 0 will be for the hosts to chat with each other and co-ordinate the change. I am going to be putting this together at some point this year at work. Basically, it is just a lot simpler if you don't require that the KDC choose the keys. Let the kadmin client do it and the problem makes itself much easier to solve. The key to designing robust systems is playing keep-away with state. Keep the state on the client and the problem is straight--forward. Incremental Propagation ----------------------- I've been considering just using rsync instead. Obviously, one would need to lock the DB, copy it to a tmp file and then rsync it into its final location on the slaves. It seems a lot simpler than maintaining our own code to do it and is probably optimal `enough'. -- Roland Dowdeswell http://www.Imrryr.ORG/~elric/ From klausk at linux.vnet.ibm.com Thu Jun 19 09:16:16 2008 From: klausk at linux.vnet.ibm.com (Klaus Heinrich Kiwi) Date: Thu, 19 Jun 2008 10:16:16 -0300 Subject: Proposal to change the meaning of -allow_tix +allow_svr aka KRB5_KDB_DISALLOW_ALL_TIX & !KRB5_KDB_DISALLOW_SVR In-Reply-To: References: <485970FD.9010109@secure-endpoints.com> Message-ID: <1213881376.17827.101.camel@klausk.br.ibm.com> On Wed, 2008-06-18 at 16:54 -0400, Ken Raeburn wrote: > I think it should be pointed out that such a change would allow > tickets to start being issued where currently they would not when the > KDC software gets updated -- even if the latter really was the intent > of the realm administrator. Because of that, we might instead want to > create a new flag with the semantics Jeff wants, and leave the > existing flag with its current (suboptimal) behavior. Sorry if this question sounds silly, but how much of both these solutions are implementation specific? Wouldn't such a change require changes to the current RFC? -Klaus -- Klaus Heinrich Kiwi Linux Security Development, IBM Linux Technology Center From jaltman at secure-endpoints.com Thu Jun 19 09:34:50 2008 From: jaltman at secure-endpoints.com (Jeffrey Altman) Date: Thu, 19 Jun 2008 09:34:50 -0400 Subject: Proposal to change the meaning of -allow_tix +allow_svr aka KRB5_KDB_DISALLOW_ALL_TIX & !KRB5_KDB_DISALLOW_SVR In-Reply-To: <1213881376.17827.101.camel@klausk.br.ibm.com> References: <485970FD.9010109@secure-endpoints.com> <1213881376.17827.101.camel@klausk.br.ibm.com> Message-ID: <485A607A.2030102@secure-endpoints.com> Klaus Heinrich Kiwi wrote: > On Wed, 2008-06-18 at 16:54 -0400, Ken Raeburn wrote: >> I think it should be pointed out that such a change would allow >> tickets to start being issued where currently they would not when the >> KDC software gets updated -- even if the latter really was the intent >> of the realm administrator. Because of that, we might instead want to >> create a new flag with the semantics Jeff wants, and leave the >> existing flag with its current (suboptimal) behavior. > > Sorry if this question sounds silly, but how much of both these > solutions are implementation specific? Wouldn't such a change require > changes to the current RFC? Its not a silly question. The allow_tix flag is 100% implementation specific. There is no standardized KDC database format nor is there a standardized kadmin interface. 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/20080619/d2624f2f/smime-0001.bin From mohamed.chaari at orange-ftgroup.com Tue Jun 17 11:23:01 2008 From: mohamed.chaari at orange-ftgroup.com (mohamed.chaari@orange-ftgroup.com) Date: Tue, 17 Jun 2008 17:23:01 +0200 Subject: Tgs req Message-ID: Hello I'm working to add some funtionnalities to kerberos. I want to know if the tgs_req is sent to the KDC when using an application such as ftp or when using a funtion such as kinit. Thanks; From senseiwa at mac.com Tue Jun 17 13:45:53 2008 From: senseiwa at mac.com (Franco Milicchio) Date: Tue, 17 Jun 2008 19:45:53 +0200 Subject: kinit In-Reply-To: References: Message-ID: <1A1DFA64-71EB-4AE9-AD56-DEB79918ED84@mac.com> On Jun 16, 2008, at 5:04pm, mohamed.chaari at orange-ftgroup.com wrote: > Hello, > > I want to know if using kinit I will have the services ticket or not. The right mailing list is in CC, I suggest to move such questions there. And yes, kinit will give you a ticket, the initial ticket to be precise. Service tickets will be released if you use kerberized services, e.g. LDAP. From paul.moore at centrify.com Fri Jun 20 12:45:05 2008 From: paul.moore at centrify.com (Paul Moore) Date: Fri, 20 Jun 2008 09:45:05 -0700 Subject: kinit In-Reply-To: <1A1DFA64-71EB-4AE9-AD56-DEB79918ED84@mac.com> References: <1A1DFA64-71EB-4AE9-AD56-DEB79918ED84@mac.com> Message-ID: Or do kinit -S -----Original Message----- From: krbdev-bounces at mit.edu [mailto:krbdev-bounces at mit.edu] On Behalf Of Franco Milicchio Sent: Tuesday, June 17, 2008 10:46 AM To: mohamed.chaari at orange-ftgroup.com; krbdev at mit.edu Cc: kerberos at mit.edu Subject: Re: kinit On Jun 16, 2008, at 5:04pm, mohamed.chaari at orange-ftgroup.com wrote: > Hello, > > I want to know if using kinit I will have the services ticket or not. The right mailing list is in CC, I suggest to move such questions there. And yes, kinit will give you a ticket, the initial ticket to be precise. Service tickets will be released if you use kerberized services, e.g. LDAP. From kulg123 at gmail.com Mon Jun 23 00:51:12 2008 From: kulg123 at gmail.com (kul gupta) Date: Mon, 23 Jun 2008 10:21:12 +0530 Subject: Kinit programatically?? Message-ID: <2203f95e0806222151g53570af2nec3f2fe17a46958b@mail.gmail.com> hello Thanks I m using MIT kerberose. I will appreciate if someone can help me how to proceed to ahieve the "Kinit" programatically. The user has entered -username and password through stdin. How can i get the TGT programatically?(using GSS-API) so as to proceed further .?? On 6/20/08, Tadoori (EXT), Vilas wrote: > > Kul, > > I would suggest you to down load the source code of MIT kerberos > > http://web.mit.edu/Kerberos/dist/ > > I would also recommend the following reading for your understanding this is > more on JAAS which is an security option that includes gssapi and also > java methods that include java and gssapi examples. > Here the methods used does not require you to specify the kerberos mech. > > > http://java.sun.com/javase/6/docs/technotes/guides/security/jgss/lab/part1.html > > Mind you they are completly on java but you will come to know how your > question can be answered. I would suggest you to read and you will get your > answer. > > > Regards > V. > > > ------------------------------ > *From:* kul gupta [mailto:kulg123 at gmail.com] > *Sent:* Friday, June 20, 2008 10:34 AM > *To:* Tadoori (EXT), Vilas > *Subject:* Re: Kerberos Digest, Vol 66, Issue 13 > > > hello > > The Example given in the SUN runs fine. > But I need to explicitly mention the mechanism name as -Kerberos _v5 > when i m not mentioning the name of the mechanism in the command line, its > giving error - gss_inquire _credentials > > My doubt is - that when i read the file mec.conf ,the mechanism specified > is Kerberos > > Then why it is not taking it automatically.?? > > > On 6/19/08, kul gupta wrote: >> >> Hello >> Thanks a lot for ur valuable time and guidance >> >> It helped me >> The example code there for both client and server is build succesfully >> now >> >> There are some basic doubts.Can u please help me in that. >> >> 1) I have a client application ( gss-client code given in SUN example ) >> and Server application code (gss-server code given in SUN example ). Both >> are build successfully >> >> 2) a) First step should be- that server application should be up to >> provide the kerborized service.Am i Right?? >> when i run the server application after taking TGT ,some error regarding >> gss_acquire _cred is coming.?? >> b) I am not getting what should i provide in the service_name on both >> client and server side?? >> c)When this much is done then only i should proceed with Client >> application?? >> (Again i need to do kinit and then run the client application so as to >> connect with the server application???) >> >> Can u please brief me the steps as how to proceed with it. >> It will really help me in clearing my baisc things on GSSAPI >> >> Thanks >> kul >> >> >> >> On 6/18/08, Tadoori (EXT), Vilas wrote: >>> >>> Hello Kul, >>> >>> I am not sure about the RHEL V5.0. I have modifed the code so that it >>> runs on the Solaris version. >>> u need to find out if the gssapi header files are installed at all on >>> your machine. >>> >>> you may find out using the linux command find /usr -name '*gss*' >>> you are looking for libraries like >>> >>> /usr/lib/gss >>> /usr/lib/gss/gsscred_clean >>> /usr/lib/gss/gssd >>> /usr/lib/libgss.so >>> /usr/include/gssapi >>> /usr/include/gssapi/gssapi.h >>> /usr/include/gssapi/gssapi_ext.h >>> the header files like gssapi_ext.h would be missing in linux because >>> these are sun specific examples which would run only on a sun o/s >>> >>> >>> Also ensure that u are linking your code with the gss libraries at run >>> time some thing like the below which is >>> >>> if you are using linux(rhel or suse) and c >>> gcc -o -l< the gsslibrary path> >>> >>> the syntax for c++ will be diff >>> g++ -o -l< the gsslibrary path> >>> >>> In my case in solaris i use the following which is >>> >>> cc testc.c -o test -lgss -O >>> >>> if you see the libraries is similar to the dir structure as above " >>> /usr/lib/gss" >>> >>> The final thing is how would you load your libraries in the run time? >>> you should check the env variable "LD_LIBRARY_PATH" >>> check the same using echo$LD_LIBRARY_PATH >>> >>> If you can see your gssapi libraries set in the path you would not face >>> any issues compiling the same. >>> >>> >>> I am not sure if I have answered your questions on this. >>> >>> Some of the code in the examples have been customised accordingly by >>> sun...so there is a great possibility that the code might break on other O/s >>> please read the rfc for gssapi v2 to ensure that you are using only those >>> functions , structures that are defined there... the rfc is 2744. >>> >>> >>> thanks >>> v. >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> ------------------------------ >>> *From:* kul gupta [mailto:kulg123 at gmail.com] >>> *Sent:* Tuesday, June 17, 2008 9:50 AM >>> *To:* Tadoori (EXT), Vilas >>> *Subject:* Re: Kerberos Digest, Vol 66, Issue 13 >>> >>> >>> Hello Vilas >>> >>> Thanks a lot for ur valuable guidance and time. >>> >>> I am using-RedHatEnterprise Linux 5.0 and using Netbeans IDE to build the >>> code and compiler is gcc ( for the code given in the SUN example) >>> >>> 1)There is AS server which is kerborized.I did the settings for the >>> kerborized client also. >>> >>> 2)After obtaining the TGT (using kinit command from the client side),how >>> should i proceed using the example given in SUN >>> >>> 3)I think mechanism used in GSSAPI by default is kerberos V5. So i need >>> not specify it explicitly.?? >>> Am i right. >>> >>> Can u please help me out in brief the steps i need to do for the same.. >>> Please let me know to proceed. >>> >>> On 6/16/08, Tadoori (EXT), Vilas wrote: >>>> >>>> Hello kul, >>>> >>>> You do not need an cyrus SASL and SASL is a diff framework altogether. >>>> All you need is a keberos server for the same. >>>> It would be really wonderful if you can give some information more about >>>> your architecture. >>>> Also it would be helpful if you can tell on which platform are you >>>> comipiling the Sun examples. >>>> There are lot many things that we need to find out first before >>>> answering the question. >>>> >>>> >>>> Regards >>>> V. >>>> >>>> >>>> -----Original Message----- >>>> From: kerberos-bounces at mit.edu [mailto:kerberos-bounces at mit.edu] On >>>> Behalf Of kerberos-request at mit.edu >>>> Sent: Sunday, June 15, 2008 9:41 PM >>>> To: kerberos at mit.edu >>>> Subject: Kerberos Digest, Vol 66, Issue 13 >>>> >>>> Send Kerberos mailing list submissions to >>>> kerberos at mit.edu >>>> >>>> To subscribe or unsubscribe via the World Wide Web, visit >>>> https://mailman.mit.edu/mailman/listinfo/kerberos >>>> or, via email, send a message with subject or body 'help' to >>>> kerberos-request at mit.edu >>>> >>>> You can reach the person managing the list at >>>> kerberos-owner at mit.edu >>>> >>>> When replying, please edit your Subject line so it is more specific than >>>> "Re: Contents of Kerberos digest..." >>>> >>>> >>>> Today's Topics: >>>> >>>> 1. help (kul gupta) >>>> >>>> >>>> ---------------------------------------------------------------------- >>>> >>>> Message: 1 >>>> Date: Sun, 15 Jun 2008 21:18:41 +0530 >>>> From: "kul gupta" >>>> Subject: help >>>> To: kerberos at mit.edu, krbdev at mit.edu >>>> Message-ID: >>>> <2203f95e0806150848k10973896ie082f11431849df0 at mail.gmail.com> >>>> Content-Type: text/plain; charset=ISO-8859-1 >>>> >>>> I am very new to kerborose and GSSAPI >>>> I will highly appreciate for the guidance for the issues below- I am bit >>>> confused about cyrus SASL and GSSAPI >>>> >>>> I have an authentication server (AS) which is kerborised Client gets the >>>> TGT using -kinit Now i need to use GSSAPI for authentication using >>>> GSSAPI >>>> >>>> 1) DO i need to have cyrus SASL also ?? or only kerborose will do?? >>>> >>>> 2) When i tried to run the example provided by SUN , i am getting >>>> following >>>> errors- >>>> gssapi_ext.h- No such file directory >>>> gssapi-misc.h-No such file directory >>>> >>>> I also tried to search these files in my system(Red hat enterprise linux >>>> 5.0),but these files are not present. >>>> >>>> I will be highly thankful if u can help me out for the same . >>>> >>>> Regards >>>> Ruchita >>>> >>>> >>>> ------------------------------ >>>> >>>> _______________________________________________ >>>> Kerberos mailing list >>>> Kerberos at mit.edu >>>> https://mailman.mit.edu/mailman/listinfo/kerberos >>>> >>>> >>>> End of Kerberos Digest, Vol 66, Issue 13 >>>> **************************************** >>>> >>>> ________________________________________________ >>>> Kerberos mailing list Kerberos at mit.edu >>>> https://mailman.mit.edu/mailman/listinfo/kerberos >>>> >>> >>> >> > From rra at stanford.edu Mon Jun 23 12:14:34 2008 From: rra at stanford.edu (Russ Allbery) Date: Mon, 23 Jun 2008 09:14:34 -0700 Subject: Kinit programatically?? In-Reply-To: <2203f95e0806222151g53570af2nec3f2fe17a46958b@mail.gmail.com> (kul gupta's message of "Mon\, 23 Jun 2008 10\:21\:12 +0530") References: <2203f95e0806222151g53570af2nec3f2fe17a46958b@mail.gmail.com> Message-ID: <87skv4f7rp.fsf@windlord.stanford.edu> "kul gupta" writes: > hello > Thanks > I m using MIT kerberose. > I will appreciate if someone can help me how to proceed to ahieve the > "Kinit" programatically. > > > The user has entered -username and password through stdin. > How can i get the TGT programatically?(using GSS-API) so as to proceed > further .?? You cannot get a TGT using GSSAPI. GSSAPI has no facility for initial authentication. For an example of many different types of authentication using the native Kerberos API, take a look at: http://www.eyrie.org/~eagle/software/kstart/ If you already have the password in hand, you probably want the krb5_get_init_creds_password function, but there's some setup that you have to do first and you probably want to store the credentials in a ticket cache afterwards. -- Russ Allbery (rra at stanford.edu) From paul.moore at centrify.com Mon Jun 23 12:44:21 2008 From: paul.moore at centrify.com (Paul Moore) Date: Mon, 23 Jun 2008 09:44:21 -0700 Subject: Kinit programatically?? In-Reply-To: <2203f95e0806222151g53570af2nec3f2fe17a46958b@mail.gmail.com> References: <2203f95e0806222151g53570af2nec3f2fe17a46958b@mail.gmail.com> Message-ID: U cannot get tgt with GSS Either System("kinit ....") Or Call Krb5_get_in_tkt_passwd (I think that's the correct name) -----Original Message----- From: krbdev-bounces at mit.edu [mailto:krbdev-bounces at mit.edu] On Behalf Of kul gupta Sent: Sunday, June 22, 2008 9:51 PM To: Tadoori (EXT), Vilas Cc: krbdev at mit.edu; kerberos at mit.edu Subject: Kinit programatically?? hello Thanks I m using MIT kerberose. I will appreciate if someone can help me how to proceed to ahieve the "Kinit" programatically. The user has entered -username and password through stdin. How can i get the TGT programatically?(using GSS-API) so as to proceed further .?? On 6/20/08, Tadoori (EXT), Vilas wrote: > > Kul, > > I would suggest you to down load the source code of MIT kerberos > > http://web.mit.edu/Kerberos/dist/ > > I would also recommend the following reading for your understanding > this is more on JAAS which is an security option that includes > gssapi and also java methods that include java and gssapi examples. > Here the methods used does not require you to specify the kerberos mech. > > > http://java.sun.com/javase/6/docs/technotes/guides/security/jgss/lab/p > art1.html > > Mind you they are completly on java but you will come to know how your > question can be answered. I would suggest you to read and you will > get your answer. > > > Regards > V. > > > ------------------------------ > *From:* kul gupta [mailto:kulg123 at gmail.com] > *Sent:* Friday, June 20, 2008 10:34 AM > *To:* Tadoori (EXT), Vilas > *Subject:* Re: Kerberos Digest, Vol 66, Issue 13 > > > hello > > The Example given in the SUN runs fine. > But I need to explicitly mention the mechanism name as -Kerberos _v5 > when i m not mentioning the name of the mechanism in the command line, > its giving error - gss_inquire _credentials > > My doubt is - that when i read the file mec.conf ,the mechanism > specified is Kerberos > > Then why it is not taking it automatically.?? > > > On 6/19/08, kul gupta wrote: >> >> Hello >> Thanks a lot for ur valuable time and guidance >> >> It helped me >> The example code there for both client and server is build >> succesfully now >> >> There are some basic doubts.Can u please help me in that. >> >> 1) I have a client application ( gss-client code given in SUN example >> ) and Server application code (gss-server code given in SUN example >> ). Both are build successfully >> >> 2) a) First step should be- that server application should be up to >> provide the kerborized service.Am i Right?? >> when i run the server application after taking TGT ,some error >> regarding gss_acquire _cred is coming.?? >> b) I am not getting what should i provide in the service_name on both >> client and server side?? >> c)When this much is done then only i should proceed with Client >> application?? >> (Again i need to do kinit and then run the client application so as >> to connect with the server application???) >> >> Can u please brief me the steps as how to proceed with it. >> It will really help me in clearing my baisc things on GSSAPI >> >> Thanks >> kul >> >> >> >> On 6/18/08, Tadoori (EXT), Vilas wrote: >>> >>> Hello Kul, >>> >>> I am not sure about the RHEL V5.0. I have modifed the code so that >>> it runs on the Solaris version. >>> u need to find out if the gssapi header files are installed at all >>> on your machine. >>> >>> you may find out using the linux command find /usr -name '*gss*' >>> you are looking for libraries like >>> >>> /usr/lib/gss >>> /usr/lib/gss/gsscred_clean >>> /usr/lib/gss/gssd >>> /usr/lib/libgss.so >>> /usr/include/gssapi >>> /usr/include/gssapi/gssapi.h >>> /usr/include/gssapi/gssapi_ext.h >>> the header files like gssapi_ext.h would be missing in linux because >>> these are sun specific examples which would run only on a sun o/s >>> >>> >>> Also ensure that u are linking your code with the gss libraries at >>> run time some thing like the below which is >>> >>> if you are using linux(rhel or suse) and c gcc -o >> output file> -l< the gsslibrary path> >>> >>> the syntax for c++ will be diff >>> g++ -o -l< the gsslibrary path> >>> >>> In my case in solaris i use the following which is >>> >>> cc testc.c -o test -lgss -O >>> >>> if you see the libraries is similar to the dir structure as above " >>> /usr/lib/gss" >>> >>> The final thing is how would you load your libraries in the run time? >>> you should check the env variable "LD_LIBRARY_PATH" >>> check the same using echo$LD_LIBRARY_PATH >>> >>> If you can see your gssapi libraries set in the path you would not >>> face any issues compiling the same. >>> >>> >>> I am not sure if I have answered your questions on this. >>> >>> Some of the code in the examples have been customised accordingly by >>> sun...so there is a great possibility that the code might break on >>> other O/s please read the rfc for gssapi v2 to ensure that you are >>> using only those functions , structures that are defined there... the rfc is 2744. >>> >>> >>> thanks >>> v. >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> ------------------------------ >>> *From:* kul gupta [mailto:kulg123 at gmail.com] >>> *Sent:* Tuesday, June 17, 2008 9:50 AM >>> *To:* Tadoori (EXT), Vilas >>> *Subject:* Re: Kerberos Digest, Vol 66, Issue 13 >>> >>> >>> Hello Vilas >>> >>> Thanks a lot for ur valuable guidance and time. >>> >>> I am using-RedHatEnterprise Linux 5.0 and using Netbeans IDE to >>> build the code and compiler is gcc ( for the code given in the SUN >>> example) >>> >>> 1)There is AS server which is kerborized.I did the settings for the >>> kerborized client also. >>> >>> 2)After obtaining the TGT (using kinit command from the client >>> side),how should i proceed using the example given in SUN >>> >>> 3)I think mechanism used in GSSAPI by default is kerberos V5. So i >>> need not specify it explicitly.?? >>> Am i right. >>> >>> Can u please help me out in brief the steps i need to do for the same.. >>> Please let me know to proceed. >>> >>> On 6/16/08, Tadoori (EXT), Vilas wrote: >>>> >>>> Hello kul, >>>> >>>> You do not need an cyrus SASL and SASL is a diff framework altogether. >>>> All you need is a keberos server for the same. >>>> It would be really wonderful if you can give some information more >>>> about your architecture. >>>> Also it would be helpful if you can tell on which platform are you >>>> comipiling the Sun examples. >>>> There are lot many things that we need to find out first before >>>> answering the question. >>>> >>>> >>>> Regards >>>> V. >>>> >>>> >>>> -----Original Message----- >>>> From: kerberos-bounces at mit.edu [mailto:kerberos-bounces at mit.edu] On >>>> Behalf Of kerberos-request at mit.edu >>>> Sent: Sunday, June 15, 2008 9:41 PM >>>> To: kerberos at mit.edu >>>> Subject: Kerberos Digest, Vol 66, Issue 13 >>>> >>>> Send Kerberos mailing list submissions to >>>> kerberos at mit.edu >>>> >>>> To subscribe or unsubscribe via the World Wide Web, visit >>>> https://mailman.mit.edu/mailman/listinfo/kerberos >>>> or, via email, send a message with subject or body 'help' to >>>> kerberos-request at mit.edu >>>> >>>> You can reach the person managing the list at >>>> kerberos-owner at mit.edu >>>> >>>> When replying, please edit your Subject line so it is more specific >>>> than >>>> "Re: Contents of Kerberos digest..." >>>> >>>> >>>> Today's Topics: >>>> >>>> 1. help (kul gupta) >>>> >>>> >>>> ------------------------------------------------------------------- >>>> --- >>>> >>>> Message: 1 >>>> Date: Sun, 15 Jun 2008 21:18:41 +0530 >>>> From: "kul gupta" >>>> Subject: help >>>> To: kerberos at mit.edu, krbdev at mit.edu >>>> Message-ID: >>>> >>>> <2203f95e0806150848k10973896ie082f11431849df0 at mail.gmail.com> >>>> Content-Type: text/plain; charset=ISO-8859-1 >>>> >>>> I am very new to kerborose and GSSAPI I will highly appreciate for >>>> the guidance for the issues below- I am bit confused about cyrus >>>> SASL and GSSAPI >>>> >>>> I have an authentication server (AS) which is kerborised Client >>>> gets the TGT using -kinit Now i need to use GSSAPI for >>>> authentication using GSSAPI >>>> >>>> 1) DO i need to have cyrus SASL also ?? or only kerborose will do?? >>>> >>>> 2) When i tried to run the example provided by SUN , i am getting >>>> following >>>> errors- >>>> gssapi_ext.h- No such file directory gssapi-misc.h-No such file >>>> directory >>>> >>>> I also tried to search these files in my system(Red hat enterprise >>>> linux 5.0),but these files are not present. >>>> >>>> I will be highly thankful if u can help me out for the same . >>>> >>>> Regards >>>> Ruchita >>>> >>>> >>>> ------------------------------ >>>> >>>> _______________________________________________ >>>> Kerberos mailing list >>>> Kerberos at mit.edu >>>> https://mailman.mit.edu/mailman/listinfo/kerberos >>>> >>>> >>>> End of Kerberos Digest, Vol 66, Issue 13 >>>> **************************************** >>>> >>>> ________________________________________________ >>>> Kerberos mailing list Kerberos at mit.edu >>>> https://mailman.mit.edu/mailman/listinfo/kerberos >>>> >>> >>> >> > _______________________________________________ krbdev mailing list krbdev at mit.edu https://mailman.mit.edu/mailman/listinfo/krbdev From jaltman at secure-endpoints.com Mon Jun 23 16:09:56 2008 From: jaltman at secure-endpoints.com (Jeffrey Altman) Date: Mon, 23 Jun 2008 16:09:56 -0400 Subject: Ticket 5338: Race conditions in key rotation In-Reply-To: <20080619055945.C9D2F37044@arioch.imrryr.org> References: <20080619055945.C9D2F37044@arioch.imrryr.org> Message-ID: <48600314.7080506@secure-endpoints.com> Roland Dowdeswell wrote: > So, this is going to be a bit of a long e-mail so let me apologise > in advance. I think that I'm going to try to structure my thoughts > into a few sections as there are a few rather distinct topics that > are all intertwined. Failing back to the master on failures is > not simply about key rotation. I have been thinking about just > implementing the failover to the master at work but I have been > holding off on it because I would rather see it implemented in the > main release than maintain [yet another] independent patch. > > It's a little late, so this e-mail may be a bit conversational. > > Failing over the Master on all Failures > --------------------------------------- > > Failing over to the master on failures is an easy and seamless way > to provide a consistent view of a completely up to date Kerberos > database at any time when the master is reachable. This is not > merely an issue of solving a race here or there. It is about > designing a system which with as little state as possible can > present a view to its client libraries that allows changes to be > effective immediately [almost all the time] without having the > master KDC have to block changes until each of the slaves has > accepted it. > > ... much deleted ... In summary, failing over to the master is an easy stateless way of addressing any number of potential errors that can be the result of a configuration error, a software bug, a network error, etc. Many of the configuration errors that can occur result in the Generic Error being sent to the client. The client therefore would have no ability to enumerate them even if doing so was the right idea. Enumerating specific errors for which a client should fail over makes it impossible to support fail over in older clients for new errors that may be introduced in the future. I am going to write a patch to introduce fail over to the master for all tgs requests. I will add it to ticket 5338 and it can then be evaluated for inclusion. Jeffrey Altman Secure Endpoints Inc. From raeburn at MIT.EDU Mon Jun 23 17:47:24 2008 From: raeburn at MIT.EDU (Ken Raeburn) Date: Mon, 23 Jun 2008 17:47:24 -0400 Subject: Ticket 5338: Race conditions in key rotation In-Reply-To: <20080619055945.C9D2F37044@arioch.imrryr.org> References: <20080619055945.C9D2F37044@arioch.imrryr.org> Message-ID: <16DF6E18-2E0A-4742-810C-D9CB6F937CFF@MIT.EDU> On Jun 19, 2008, at 01:59, Roland Dowdeswell wrote: > What happens when a slave gets a little corrupted? How about some > level of DB corruption? Truncated database? Configuration errors? > What if a misconfiguration causes the master to fail to propagate > to the slave for some period of time? If the slave KDC notices corruption it should either report a server error that causes the client to keep trying other KDCs, or it should just stay silent. A little like you might get with DNS. If a DNS server has old data, or quietly corrupted data, what do you do about it? Do you implement all your applications or client libraries to check other DNS servers for the same domain if you get back no-such-host errors, just in case the data is out of date? What if you get back an address, but it's the wrong one? Should Firefox try multiple DNS servers, and try connecting to web servers at all the addresses returned (versus, say, looking for the first reachable address from the list provided by one DNS server)? There are probably various things we could to try to make the MIT implementation more resistant to corruption in slave database. Maybe have the master double-check the number of records in the dump file against some heuristic before transmitting via kprop, or have an extra record in the database (which would have to be kept in sync!) with a count of the number of principals. Maybe the slave should go offline if the database hasn't been updated in some configurable amount of time. Maybe we should provide scripts (anyone want to contribute?) that email the admins or sound other alarms if database propagation fails for longer than a certain amount of time. Maybe slave update time should be made accessible via SNMP for query by nagios or other monitoring tools. If the slave database gets corrupted but the master is okay, ideally that's an issue that should be fixed in the next propagation. If the corruption is in the master database, falling back to the master won't help. Most of the times I've seen database corruption bugs, they've been in the random updates done on the master, not loading a database on a slave. Though one or two have resulted in incorrect dump files for propagation that omit or duplicate entries, while the master can still access all the entries by name, at least for a little while longer. > What if kpropd crashes? Then any other slave should have accurate data; we don't need to jump to the master KDC, when we could distribute the load. > What > if we put a slave into krb5.conf before we bring it live? With the KDC process not running, the client will get no response (or a port-unreachable error), and will move on to another server in fairly short time. If the KDC process is started up with an empty database, the KDC wouldn't be able to handle the client's AS requests, or decrypt the TGS requests, and we might have a problem. Though I'm not sure where to draw the line between administrator screw-ups we should try to compensate for, and administrator screw-ups (or malicious actions) where we should just throw up our hands and say, "you need to fix this first". > What if > a KDC from the wrong realm gets mis-set in our configuration? Interesting... I'm not certain, but I can guess: For an AS-REQ, it probably would get an error saying the client principal was unknown. For a TGS-REQ, the (wrong) KDC wouldn't have a database entry for the indicated (TGS) principal, and would probably return a KRB-ERROR saying so. But if you're going to presuppose configuration errors, why assume that the listing for the master KDC will be correct? Also, in this case, we could presumably succeed by trying *any* other KDC, i.e., ignore the error and continue with our existing heuristics (that can be tweaked in site-specific ways via plugins to order KDCs by proximity). I'd certainly support changes to better detect certain configuration errors, or make it harder for them to cause problems, but I don't think the blanket response to anything amiss should be to double the network traffic and focus all the extra traffic on one server. > Etc. What if the slave KDC doesn't have the latest update regarding the authorization data a user should get for service X. If service X reports an authorization error, should we go back and talk to the master KDC just in case? > Failures on slaves should not be considered to be permanent errors > given that we know up front that there is a more canonical source > of truth just a few lines away in the configuration file... I'm sure there's any number of failures relating to an out-of-date database that could result in problems for the client, some of which may be noticed in the Kerberos protocol exchange, and some may not be noticed until later. All the problems relating to corruption, client or DNS configuration errors, etc., can be addressed by talking to another KDC; there's no need to use the master KDC specifically, and in some environments there may be a good reason not to when another slave is available. It's only when changes on the master haven't propagated that going directly to the master is the right answer. In the long term, I'd rather see the synchronization problem addressed well, so that the clients don't have to do any of this sort of thing. Incremental propagation support will help, though Sun's implementation that I'm looking at integrating uses a periodic polling model, not an instantaneous push model. However it should cut down the delay needed for propagation, so you can say, e.g., "after a new service is registered, you may have to wait 30 seconds for the information to propagate before you can authenticate to it". (Actually, in the long term, I'd like to see a multi-master type arrangement where we don't even have a distinguished "master KDC". But failing that, immediate propagation of all changes seems like a very desirable substitute.) In the short term ... yeah, maybe some "reasonable" failure cases don't have sufficient information, and we should consider retrying for now. But if we do this, I really hope we consider it a temporary workaround we intend to dispense with, or at least disable by default, in a few releases. And I'm still not convinced it should be the rule rather than the exception. > Incremental Propagation > ----------------------- > > I've been considering just using rsync instead. Obviously, one > would need to lock the DB, copy it to a tmp file and then rsync it > into its final location on the slaves. It seems a lot simpler than > maintaining our own code to do it and is probably optimal `enough'. I've long suspected that for a large database with infrequent changes, it would be much more efficient than kprop. Had rsync been around when kprop was written, it probably would've been the way to go. If you try it, do let us know if you encounter any interesting issues. Ken From Nicolas.Williams at sun.com Mon Jun 23 18:00:35 2008 From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Mon, 23 Jun 2008 17:00:35 -0500 Subject: Ticket 5338: Race conditions in key rotation In-Reply-To: <48600314.7080506@secure-endpoints.com> References: <20080619055945.C9D2F37044@arioch.imrryr.org> <48600314.7080506@secure-endpoints.com> Message-ID: <20080623220034.GE2735@Sun.COM> On Mon, Jun 23, 2008 at 04:09:56PM -0400, Jeffrey Altman wrote: > I am going to write a patch to introduce fail over to the master > for all tgs requests. I will add it to ticket 5338 and it can > then be evaluated for inclusion. Note: failover needs to not happen if a master is not defined... I know, it seems obvious... But also, it may be a good idea to make it optional, or to make failover be more of a "try another KDC" option. The client's behaviour shouldn't prevent/complicate the possibility of having kadmind instances running on all the KDCs nor multi-master replication. From Nicolas.Williams at sun.com Mon Jun 23 18:03:31 2008 From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Mon, 23 Jun 2008 17:03:31 -0500 Subject: Ticket 5338: Race conditions in key rotation In-Reply-To: <20080619055945.C9D2F37044@arioch.imrryr.org> References: <20080619055945.C9D2F37044@arioch.imrryr.org> Message-ID: <20080623220331.GF2735@Sun.COM> On Thu, Jun 19, 2008 at 01:59:45AM -0400, Roland Dowdeswell wrote: > Failing over to the master on failures is an easy and seamless way > to provide a consistent view of a completely up to date Kerberos > database at any time when the master is reachable. This is not > merely an issue of solving a race here or there. It is about > designing a system which with as little state as possible can > present a view to its client libraries that allows changes to be > effective immediately [almost all the time] without having the > master KDC have to block changes until each of the slaves has > accepted it. > > There is one case in which this is currently done. Password changes. > It works. > > I proposed this in RT 5338 to solve the TGS key rotation race. It > does this simply. It would help too if krb5kdc were multi-threaded, otherwise clients can time out if too many hit the master at once, and meanwhile the master is not maxing either its CPU nor its I/O. Nico -- From jaltman at secure-endpoints.com Mon Jun 23 18:13:31 2008 From: jaltman at secure-endpoints.com (Jeffrey Altman) Date: Mon, 23 Jun 2008 18:13:31 -0400 Subject: Ticket 5338: Race conditions in key rotation In-Reply-To: <20080623220034.GE2735@Sun.COM> References: <20080619055945.C9D2F37044@arioch.imrryr.org> <48600314.7080506@secure-endpoints.com> <20080623220034.GE2735@Sun.COM> Message-ID: <4860200B.5080904@secure-endpoints.com> Nicolas Williams wrote: > On Mon, Jun 23, 2008 at 04:09:56PM -0400, Jeffrey Altman wrote: >> I am going to write a patch to introduce fail over to the master >> for all tgs requests. I will add it to ticket 5338 and it can >> then be evaluated for inclusion. > > Note: failover needs to not happen if a master is not defined... > > I know, it seems obvious... > > But also, it may be a good idea to make it optional, or to make failover > be more of a "try another KDC" option. > > The client's behaviour shouldn't prevent/complicate the possibility of > having kadmind instances running on all the KDCs nor multi-master > replication. In MIT Kerberos a KDC server running kadmind is not necessarily a master. The master notion is only defined if the master_kdc is explicitly configured. If "master_kdc" is not defined, then the failover to master functionality is not used. 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/20080623/8a2ad2b0/smime.bin From raeburn at MIT.EDU Mon Jun 23 19:16:42 2008 From: raeburn at MIT.EDU (Ken Raeburn) Date: Mon, 23 Jun 2008 19:16:42 -0400 Subject: Ticket 5338: Race conditions in key rotation In-Reply-To: <20080623220331.GF2735@Sun.COM> References: <20080619055945.C9D2F37044@arioch.imrryr.org> <20080623220331.GF2735@Sun.COM> Message-ID: On Jun 23, 2008, at 18:03, Nicolas Williams wrote: > It would help too if krb5kdc were multi-threaded, otherwise clients > can > time out if too many hit the master at once, and meanwhile the > master is > not maxing either its CPU nor its I/O. We've gotten requests (and arguments) both pro and con... Certainly we're going to need to address the fact that talking to an LDAP server or other database back end may not be instantaneous. And other possible extensions being discussed at the IETF will also require the KDC to wait for some external service. Most sites seem to have no problem with one (often cheap or outdated) machine servicing all KDC requests using a db2 database, but there are probably cases at larger sites where that's not true. I have no idea if CPU power, disk bandwidth, or network bandwidth would be the likely bottlenecks. Single-threaded processing power doesn't seem to be increasing very quickly any more though. I would guess that PKINIT would add a bit to the CPU load, though obviously only for the relatively infrequent AS-REQ exchanges. On the flip side, there's the argument that going from single-threaded code to multi-threaded is likely to introduce race conditions into existing code if you're not *extremely* careful, and they'll be hard to spot. Using a multi-process model could conceivably work, but also requires some careful re-architecting, though without as much risk of memory-corrupting race conditions. We do have a patch sitting on a branch in the subversion repository at MIT, which makes part of the KDC multithreaded, specifically, allowing multiple parallel queries to an LDAP server to be in progress. Unfortunately, I haven't had time to exercise it much. If you (or anyone else) would like to take a look, it's at svn://anonsvn.mit.edu/ krb5/branches/mt-kdc/. Ken From raeburn at MIT.EDU Tue Jun 24 01:17:27 2008 From: raeburn at MIT.EDU (Ken Raeburn) Date: Tue, 24 Jun 2008 01:17:27 -0400 Subject: incremental propagation code Message-ID: <38993564-A855-473F-8185-E69E31D74AA2@mit.edu> Hi. I've just merged in to the trunk of the MIT krb5 repository some changes based on Sun's incremental propagation code. It should be in time for tonight's nightly snapshot. Sun's code was based on an older release of the MIT code, before the Database Abstraction Layer was set up. So I've had to do a bit of work on the code to get it integrated. There are some rough edges at the moment, and some configuration changes from Sun's original implementation, which I've tried to document, but I think it's ready for some outside testing, if anyone's feeling adventurous. There are several options that need to be specified in the config files of the master and slave for incremental propagation to be enabled. The protocol works by adding a new RPC service, with the server in kadmind, and the client side run in kpropd. Incremental changes are passed over the RPC protocol, and if the slave database is too far out of date, the slave tells kadmind to fire up kprop to send a full database dump, after which incremental propagation is resumed. On the master side, all the programs that change the database also write their changes to an update log first, so the information can be carried to the slaves. I've made some notes on how to use it in doc/install.texinfo, and some other miscellaneous notes and observations in doc/iprop-notes.txt. If you get a chance to try it out in the next 2-3 weeks or so, please let me know the results, good or bad.... Ken From elric at imrryr.org Tue Jun 24 02:30:11 2008 From: elric at imrryr.org (Roland Dowdeswell) Date: Tue, 24 Jun 2008 02:30:11 -0400 Subject: Ticket 5338: Race conditions in key rotation In-Reply-To: Your message of "Mon, 23 Jun 2008 17:47:24 EDT." <16DF6E18-2E0A-4742-810C-D9CB6F937CFF@MIT.EDU> Message-ID: <20080624063011.0D52B37044@arioch.imrryr.org> On 1214257644 seconds since the Beginning of the UNIX epoch Ken Raeburn wrote: > >On Jun 19, 2008, at 01:59, Roland Dowdeswell wrote: >> What happens when a slave gets a little corrupted? How about some >> level of DB corruption? Truncated database? Configuration errors? >> What if a misconfiguration causes the master to fail to propagate >> to the slave for some period of time? > >If the slave KDC notices corruption it should either report a server >error that causes the client to keep trying other KDCs, or it should >just stay silent. A little like you might get with DNS. Yes, in a perfect world. I'm not convinced that is what we're in. >If a DNS server has old data, or quietly corrupted data, what do you >do about it? >Do you implement all your applications or client libraries to check >other DNS servers for the same domain if you get back no-such-host >errors, just in case the data is out of date? What if you get back an >address, but it's the wrong one? Should Firefox try multiple DNS >servers, and try connecting to web servers at all the addresses >returned (versus, say, looking for the first reachable address from >the list provided by one DNS server)? I do not think that the DNS example is a good mirror of how a Kerberos infrastructure should work. For one, the problem set that is trying to be addressed is quite different, the general use cases are different. Given that in general, when you are requesting service tickets, you have already not only successfully located the server but also built up a TCP connection to it, I think that you have a much firmer idea that your request for a service ticket _should_ succeed. If you simply request a random DNS name based on user input then you do not. >There are probably various things we could to try to make the MIT >implementation more resistant to corruption in slave database. Maybe >have the master double-check the number of records in the dump file >against some heuristic before transmitting via kprop, or have an extra >record in the database (which would have to be kept in sync!) with a >count of the number of principals. Maybe the slave should go offline >if the database hasn't been updated in some configurable amount of >time. Maybe we should provide scripts (anyone want to contribute?) >that email the admins or sound other alarms if database propagation >fails for longer than a certain amount of time. Maybe slave update >time should be made accessible via SNMP for query by nagios or other >monitoring tools. There are various things that you could do. I would not be terribly excited about slaves programatically deciding to go offline, however, just because they haven't been updated in some amount of time. In the event of a network partition that could be disastrous. I would rather have them continue to serve stale data, detect the situation, deal with it manually, and in the meantime have all of the clients do something reasonable when that slave returns errors. Again, my point is that I would trust the logic that we put into the slaves less than a simple fail back to the master. The failback ensures that all we'll get is an insignificant extra network/KDC load on the master while we have time to address the issue. Or more to the point, how do I answer the question: What is a reasonable configuration for the time after which a slave will automatically go offline if it has not received an update? I don't think that has a good answer. It depends a lot on what kind of disasters you expect. It also has some unfortunate dependencies on the disasters that you do not expect. Those are generally the ones that actually occur in practice. >If the slave database gets corrupted but the master is okay, ideally >that's an issue that should be fixed in the next propagation. If the >corruption is in the master database, falling back to the master won't >help. Most of the times I've seen database corruption bugs, they've >been in the random updates done on the master, not loading a database >on a slave. Though one or two have resulted in incorrect dump files >for propagation that omit or duplicate entries, while the master can >still access all the entries by name, at least for a little while >longer. Granted, the master may be more likely to have some corruption issues. >> What if kpropd crashes? > >Then any other slave should have accurate data; we don't need to jump >to the master KDC, when we could distribute the load. Sure, but how exactly do we determine the difference between: 1. kpropd crashed, and 2. new data exists on the master? Given that both have the same symptoms, I don't think that we can. So the safe path---the path that causes the least overall (network and KDC) load---is to fail back to the master. >> What >> if we put a slave into krb5.conf before we bring it live? > >With the KDC process not running, the client will get no response (or >a port-unreachable error), and will move on to another server in >fairly short time. > >If the KDC process is started up with an empty database, the KDC >wouldn't be able to handle the client's AS requests, or decrypt the >TGS requests, and we might have a problem. Though I'm not sure where >to draw the line between administrator screw-ups we should try to >compensate for, and administrator screw-ups (or malicious actions) >where we should just throw up our hands and say, "you need to fix this >first". > >> What if >> a KDC from the wrong realm gets mis-set in our configuration? > >Interesting... I'm not certain, but I can guess: For an AS-REQ, it >probably would get an error saying the client principal was unknown. >For a TGS-REQ, the (wrong) KDC wouldn't have a database entry for the >indicated (TGS) principal, and would probably return a KRB-ERROR >saying so. > >But if you're going to presuppose configuration errors, why assume >that the listing for the master KDC will be correct? That was just an example. I'm not presupposing that the master will be correct but I think that it would not be difficult to make a case that it is more likely that the master is correct at any given point in time. >Also, in this case, we could presumably succeed by trying *any* other >KDC, i.e., ignore the error and continue with our existing heuristics >(that can be tweaked in site-specific ways via plugins to order KDCs >by proximity). Sure, but again, we already know that in general the master will be correct. >I'd certainly support changes to better detect certain configuration >errors, or make it harder for them to cause problems, but I don't >think the blanket response to anything amiss should be to double the >network traffic and focus all the extra traffic on one server. I don't think that we're talking about an amazing amount of additional load or traffic here. So, let's set some expectations here on how much additional load we're talking about with some data. This is the middle of the night, so I'm just going to look at one of our KDCs rather than do a full analysis of the lot. And, I'll limit it to about five days. The KDC processed 11941961 requests and returned 181659 errors. (I'm ignoring PREAUTH_NEEDED and PREAUTH_FAILED as the former aren't errors and the latter fail back to the master already.) Maybe this warrants additional study as I didn't delve into the actual causes of the errors or study a long enough period of time. But: 181659 / 11941961 * 100 = 1.5% I think that I'm willing to accept a 1.5% increase on the load of the master and network in exchange for having a more robust environment. Also, I was suggesting that we default to failing back if we have not analysed the error and determined that it is permanent. That is, if we prove to ourselves that a particular error is permanent, then we should make it so. But the default for errors that we have not analysed should not be permanent. An example of a permanent errors might be `ticket not forwardable' or `ticket not renewable'. Those do not depend on data in the slave's database and so we can presume that if the slave successfully decrypted the ticket and decided to return those errors then it is right. A lot of the other errors, however, are obviously things about which the slave could simply be out of date: {server|client} not found, expired passwords, decrypt intergrity check failed, client locked out, bad encryption type, ... >> Etc. > >What if the slave KDC doesn't have the latest update regarding the >authorization data a user should get for service X. If service X >reports an authorization error, should we go back and talk to the >master KDC just in case? Different problem. I'm talking about KDC errors at the moment. There is always going to be a race here because the request for access to resources must necessarily occur at some point after the ticket is obtained from the KDC and presented to the server. Also, Kerberos caches tickets which exacerbates this issue. >> Failures on slaves should not be considered to be permanent errors >> given that we know up front that there is a more canonical source >> of truth just a few lines away in the configuration file... > >I'm sure there's any number of failures relating to an out-of-date >database that could result in problems for the client, some of which >may be noticed in the Kerberos protocol exchange, and some may not be >noticed until later. > >All the problems relating to corruption, client or DNS configuration >errors, etc., can be addressed by talking to another KDC; there's no >need to use the master KDC specifically, and in some environments >there may be a good reason not to when another slave is available. >It's only when changes on the master haven't propagated that going >directly to the master is the right answer. Sure. I just think that you can't as the client generally determine what the problem is. The master is right there waiting to give you the up to date notion of what the universe looks like, though. You'll eventually have to get there for a large class of errors before you are convinced that you're done with your quest. So, it might as well be next. >In the long term, I'd rather see the synchronization problem addressed >well, so that the clients don't have to do any of this sort of thing. >Incremental propagation support will help, though Sun's implementation >that I'm looking at integrating uses a periodic polling model, not an >instantaneous push model. However it should cut down the delay needed >for propagation, so you can say, e.g., "after a new service is >registered, you may have to wait 30 seconds for the information to >propagate before you can authenticate to it". (Actually, in the long >term, I'd like to see a multi-master type arrangement where we don't >even have a distinguished "master KDC". But failing that, immediate >propagation of all changes seems like a very desirable substitute.) Incremental propagation does not solve race conditions. It just makes one runner a little faster but the underlying issue still exists. I'm not convinced that I would like to have a multi-master scheme, it seems that it would add complexity for little additional value. >In the short term ... yeah, maybe some "reasonable" failure cases >don't have sufficient information, and we should consider retrying for >now. But if we do this, I really hope we consider it a temporary >workaround we intend to dispense with, or at least disable by default, >in a few releases. And I'm still not convinced it should be the rule >rather than the exception. -- Roland Dowdeswell http://www.Imrryr.ORG/~elric/ From Nicolas.Williams at sun.com Tue Jun 24 03:09:18 2008 From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Tue, 24 Jun 2008 02:09:18 -0500 Subject: Ticket 5338: Race conditions in key rotation In-Reply-To: References: <20080619055945.C9D2F37044@arioch.imrryr.org> <20080623220331.GF2735@Sun.COM> Message-ID: <20080624070918.GJ2735@Sun.COM> On Mon, Jun 23, 2008 at 07:16:42PM -0400, Ken Raeburn wrote: > On Jun 23, 2008, at 18:03, Nicolas Williams wrote: > >It would help too if krb5kdc were multi-threaded, otherwise clients > >can time out if too many hit the master at once, and meanwhile the > >master is not maxing either its CPU nor its I/O. > > We've gotten requests (and arguments) both pro and con... > > [...] > > On the flip side, there's the argument that going from single-threaded > code to multi-threaded is likely to introduce race conditions into > existing code if you're not *extremely* careful, and they'll be hard > to spot. Using a multi-process model could conceivably work, but also > requires some careful re-architecting, though without as much risk of > memory-corrupting race conditions. Personally I'd prefer that you implement a single-threaded-but-async KDC first. Threading that will be easier, but at least you'll be abe to max out (or get close to maxing out) one CPU and all the I/O that can drive. This mostly means breaking up a couple of functions around all kdb operations. From kulg123 at gmail.com Tue Jun 24 07:08:58 2008 From: kulg123 at gmail.com (kul gupta) Date: Tue, 24 Jun 2008 16:38:58 +0530 Subject: Help - Kerberos Message-ID: <2203f95e0806240408p11d93076j625528e2a1af298d@mail.gmail.com> Hi I am using MIT kerberos for authentication. Currently the client needs to do kinit (or call krb5_get_init_creds_password()) to get the TGT in which it direcly communicates with KDC. The envoirnment is that i dont want to make client directly communicate with the KDC and still want to achieve kerberos authentication. Are there any ways in which I can achieve this. How can i implement Authorization(giving access to specific service for a client) I will really appreciate your help.. Thanks and Regards kul From jaltman at secure-endpoints.com Tue Jun 24 09:00:34 2008 From: jaltman at secure-endpoints.com (Jeffrey Altman) Date: Tue, 24 Jun 2008 09:00:34 -0400 Subject: Ticket 5338: Race conditions in key rotation In-Reply-To: References: <20080619055945.C9D2F37044@arioch.imrryr.org> <20080623220331.GF2735@Sun.COM> Message-ID: <4860EFF2.6010205@secure-endpoints.com> Ken Raeburn wrote: > Certainly we're going to need to address the fact that talking to an > LDAP server or other database back end may not be instantaneous. And > other possible extensions being discussed at the IETF will also > require the KDC to wait for some external service. To give you some idea of the types of delays you should be prepared for. When I was working on the KCA code we found that Active Directory could take as long as 60 seconds to respond to an LDAP query requesting the display name associated with a Kerberos principal under certain load conditions. Not only did the KCA have to become threaded but it had to become stateful in order to permit threads to queue up requests, send queries to the LDAP server, and then be re-purposed until such time as the query results were available. Blocking threads on the LDAP query simply will not scale. To ensure reasonable performance caused by multiple requests for the same user logging into multiple machines at the beginning of the day, LDAP responses were cached for five minutes. This was necessary in order to avoid overwhelming the LDAP servers. 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/20080624/43cfd02a/smime.bin From jaltman at secure-endpoints.com Tue Jun 24 09:06:03 2008 From: jaltman at secure-endpoints.com (Jeffrey Altman) Date: Tue, 24 Jun 2008 09:06:03 -0400 Subject: Ticket 5338: Race conditions in key rotation In-Reply-To: <20080624063011.0D52B37044@arioch.imrryr.org> References: <20080624063011.0D52B37044@arioch.imrryr.org> Message-ID: <4860F13B.6020307@secure-endpoints.com> Roland Dowdeswell wrote: > Also, I was suggesting that we default to failing back if we have > not analysed the error and determined that it is permanent. That > is, if we prove to ourselves that a particular error is permanent, > then we should make it so. But the default for errors that we have > not analysed should not be permanent. An example of a permanent > errors might be `ticket not forwardable' or `ticket not renewable'. > Those do not depend on data in the slave's database and so we can > presume that if the slave successfully decrypted the ticket and > decided to return those errors then it is right. Actually, forwardable and renewable errors do depend on the policy flags in the service principal entry. Therefore, they cannot be considered permanent. I looked through the errors and I do not think there are any errors that can be considered to be permanent. 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/20080624/824e2a57/smime.bin From raeburn at MIT.EDU Tue Jun 24 09:30:12 2008 From: raeburn at MIT.EDU (Ken Raeburn) Date: Tue, 24 Jun 2008 09:30:12 -0400 Subject: Ticket 5338: Race conditions in key rotation In-Reply-To: <20080624070918.GJ2735@Sun.COM> References: <20080619055945.C9D2F37044@arioch.imrryr.org> <20080623220331.GF2735@Sun.COM> <20080624070918.GJ2735@Sun.COM> Message-ID: <53744920-000E-4E4C-AD35-CD6B654BAE23@MIT.EDU> On Jun 24, 2008, at 03:09, Nicolas Williams wrote: > Personally I'd prefer that you implement a single-threaded-but-async > KDC > first. Threading that will be easier, but at least you'll be abe to > max > out (or get close to maxing out) one CPU and all the I/O that can > drive. > > This mostly means breaking up a couple of functions around all kdb > operations. And calls to get preauth information, which may be stored in external databases, and which may be implemented within plugins. And calls to get authorization data... okay, we haven't implemented that yet, but again, there would potentially be long-running calls performed from within a plugin. And OCSP calls to check certificates presented in PKINIT (which is implemented as a plugin). And message exchanges to remote KDCs for PKCROSS, draft-kamada-krb-client-friendly-cross, whatever. And there's the assumption that you can make all these other things play nicely with an async event loop that they don't even get to manage. For remote-KDC interactions it's easy, but I don't see a way in the async OpenLDAP API, for example, to get a list of file descriptors on which async LDAP operations are pending. You could spin some of these off into separate threads or processes that manage their own multiple async actions through whatever mechanisms are appropriate, and pass the data back to the main thread through a single unified async management mechanism; that would be a bit more limited than what Novell contributed, but perhaps simpler to analyze. Ken From Nicolas.Williams at sun.com Tue Jun 24 12:08:02 2008 From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Tue, 24 Jun 2008 11:08:02 -0500 Subject: Ticket 5338: Race conditions in key rotation In-Reply-To: <53744920-000E-4E4C-AD35-CD6B654BAE23@MIT.EDU> References: <20080619055945.C9D2F37044@arioch.imrryr.org> <20080623220331.GF2735@Sun.COM> <20080624070918.GJ2735@Sun.COM> <53744920-000E-4E4C-AD35-CD6B654BAE23@MIT.EDU> Message-ID: <20080624160802.GN2735@Sun.COM> On Tue, Jun 24, 2008 at 09:30:12AM -0400, Ken Raeburn wrote: > On Jun 24, 2008, at 03:09, Nicolas Williams wrote: > >Personally I'd prefer that you implement a single-threaded-but-async > >KDC first. Threading that will be easier, but at least you'll be abe > >to max out (or get close to maxing out) one CPU and all the I/O that > >can drive. > > > >This mostly means breaking up a couple of functions around all kdb > >operations. > > And calls to get preauth information, which may be stored in external > databases, and which may be implemented within plugins. And calls to Today that's all part of the KDB. > get authorization data... okay, we haven't implemented that yet, but No, you haven't. It'd be nice, but it'd be even nicer if you add it the right way (with a callback / event registration) so that the public interfaces you add don't prevent this design. > again, there would potentially be long-running calls performed from > within a plugin. And OCSP calls to check certificates presented in > PKINIT (which is implemented as a plugin). And message exchanges to Of course. It's worth doing. > remote KDCs for PKCROSS, draft-kamada-krb-client-friendly-cross, > whatever. Right, PKCROSS doesn't have any KDC-KDC message exchanges, while the latter does. > And there's the assumption that you can make all these other things > play nicely with an async event loop that they don't even get to > manage. For remote-KDC interactions it's easy, but I don't see a way No such assumption. If you begin by reducing the number of synchronous sleep points you win a lot. You can do this piecemeal, over time, rather than having to do this all at once. > in the async OpenLDAP API, for example, to get a list of file > descriptors on which async LDAP operations are pending. You could > spin some of these off into separate threads or processes that manage Yes, you need to have helper threads for things like libldap. It's not a big deal. (In this case the helper thread blocks in ldap_result(), and arranges for event dispatching based on the message IDs of the LDAP results.) > their own multiple async actions through whatever mechanisms are > appropriate, and pass the data back to the main thread through a > single unified async management mechanism; that would be a bit more > limited than what Novell contributed, but perhaps simpler to analyze. Right, that's how these helper threads would work. Yes, it's *much* simpler to analyze because everything part of the system can be single threaded and the only interesting synchronization points are the ones by which: a) events are queued up that, b) helper threads signal the dispatch thread (both trivial things). Later you can multi-thread the parts of the KDC that do the krb5 work while adding a big lock around the KDB and other plugins. Later you can make the KDB and plugins thread-safe and remove the big locks. A design that allows you to do the work piecemeal has a lot going for it, IMO. Nico -- From Nicolas.Williams at sun.com Tue Jun 24 12:24:38 2008 From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Tue, 24 Jun 2008 11:24:38 -0500 Subject: Ticket 5338: Race conditions in key rotation In-Reply-To: <20080624160802.GN2735@Sun.COM> References: <20080619055945.C9D2F37044@arioch.imrryr.org> <20080623220331.GF2735@Sun.COM> <20080624070918.GJ2735@Sun.COM> <53744920-000E-4E4C-AD35-CD6B654BAE23@MIT.EDU> <20080624160802.GN2735@Sun.COM> Message-ID: <20080624162437.GQ2735@Sun.COM> Also, a design where you have: - worker threads that never block (because async) - helper threads for event dispatching allows you to match worker thread counts to CPU counts, and so keep contention to a minimum. Whereas simply multi-threading the KDC means that sometimes you may have many threads on the run queues. How big a deal this is depends on how much time will be spent blocking on I/O while processing any one request. From jhutz at cmu.edu Tue Jun 24 12:31:03 2008 From: jhutz at cmu.edu (Jeffrey Hutzelman) Date: Tue, 24 Jun 2008 12:31:03 -0400 Subject: Proposal to change the meaning of -allow_tix +allow_svr aka KRB5_KDB_DISALLOW_ALL_TIX & !KRB5_KDB_DISALLOW_SVR In-Reply-To: <200806182059.m5IKxYLQ028542@toasties.srv.cs.cmu.edu> References: <485970FD.9010109@secure-endpoints.com> <200806182059.m5IKxYLQ028542@toasties.srv.cs.cmu.edu> Message-ID: <2750DB3DE540171113F09501@sirius.fac.cs.cmu.edu> --On Wednesday, June 18, 2008 04:54:04 PM -0400 Ken Raeburn wrote: > On Jun 18, 2008, at 16:33, Jeffrey Altman wrote: >> I believe that the meaning of allow_tix should be altered such that >> it only applies to the client >> in a TGS or AS request. This would permit -allow_tix to be applied >> to a service principal >> and ensure that no client ticket requests can be satisfied for that >> service principal while at >> the same time permitting other principals to obtain service tickets. >> Organizations that wish to disable the issuance of service tickets >> for the service principal >> would apply -allow_svr to the principal in addition to -allow_tix. > > I think it should be pointed out that such a change would allow > tickets to start being issued where currently they would not when the > KDC software gets updated -- even if the latter really was the intent > of the realm administrator. Because of that, we might instead want to > create a new flag with the semantics Jeff wants, and leave the > existing flag with its current (suboptimal) behavior. I don't consider the current behavior of -allow_tix to be suboptimal. Its effect is to completely and totally disable a principal for all uses, which is a desirable thing to be able to do from an administrative point of view, separately from the ability to specify "this principal can only be used as a client" (-allow_svr) or "this principal can only be used as a service (the new flag Jeff is asking about). Note that there is a justification for having -allow_svr without -allow_clt. The former, when used with a policy requiring the use of preauth, prevents an attacker from asking the KDC for ciphertext to be used in a long-term attack against a principal's key. This is particularly useful for principals belonging to human users, whose keys are often derived from passwords with fairly low entropy. While -allow_clt may be a useful policy for administrative purposes, it doesn't serve the same kind of security goal. -- Jeff From jhutz at cmu.edu Tue Jun 24 12:41:44 2008 From: jhutz at cmu.edu (Jeffrey Hutzelman) Date: Tue, 24 Jun 2008 12:41:44 -0400 Subject: Ticket 5338: Race conditions in key rotation In-Reply-To: <200806182241.m5IMf4bY002032@toasties.srv.cs.cmu.edu> References: <485977C7.8060501@secure-endpoints.com> <200806182241.m5IMf4bY002032@toasties.srv.cs.cmu.edu> Message-ID: <81B673EB674BDD5405DC6D5D@sirius.fac.cs.cmu.edu> --On Wednesday, June 18, 2008 06:41:27 PM -0400 Jeffrey Altman wrote: > Ken Raeburn wrote: >> On Jun 18, 2008, at 17:01, Jeffrey Altman wrote: >>> In order to address this race condition I propose that krb5_send_tgs() >>> be modified to retry against the master KDC whenever there is an >>> error and the error is not one of KRB5_KDC_UNREACH or >>> KRB5_REALM_CANT_RESOLVE. >> >> What's the actual error that would be returned in such a case? > > KRB5KRB_ERR_GENERIC with the error text specifying a kvno not found. > >> Wouldn't it make sense to do the retry only for one specific error? > > I don't think so. I think that any misconfiguration of a slave kdc > should result in the master being asked since the master's response is > going to be definitive. The presumption here is that there _is_ a "master" which is "more definitive". IMHO, it is better here to fix the behavior of the KDC than to introduce the expectation that in order to get proper results, clients must implement a behavior which is not documented in any standard. In the case of key rollover, whether it's the master key or the TGS key or some other service's key, I believe the correct approach is to allow new keys to be registered in the KDB without being used to issue new tickets until the change has reached everyone that needs to know about it. If I tell you "no", that means "no", not "go ask mommy and see if she gives you an answer you like more". -- Jeff From jaltman at secure-endpoints.com Tue Jun 24 12:46:31 2008 From: jaltman at secure-endpoints.com (Jeffrey Altman) Date: Tue, 24 Jun 2008 12:46:31 -0400 Subject: Ticket 5338: Race conditions in key rotation In-Reply-To: <81B673EB674BDD5405DC6D5D@sirius.fac.cs.cmu.edu> References: <485977C7.8060501@secure-endpoints.com> <200806182241.m5IMf4bY002032@toasties.srv.cs.cmu.edu> <81B673EB674BDD5405DC6D5D@sirius.fac.cs.cmu.edu> Message-ID: <486124E7.4080302@secure-endpoints.com> Jeffrey Hutzelman wrote: > The presumption here is that there _is_ a "master" which is "more > definitive". For MIT Kerberos the introduction of "master_kdc" says exactly that. There is in fact a master and that master is more definitive. That is how the clients already work when it comes to AS requests. Our proposal is to extend that behavior to TGS requests. If there is no defined master, then there is no master to fallback to. 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/20080624/03559274/smime.bin From Nicolas.Williams at sun.com Tue Jun 24 12:58:44 2008 From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Tue, 24 Jun 2008 11:58:44 -0500 Subject: Ticket 5338: Race conditions in key rotation In-Reply-To: <486124E7.4080302@secure-endpoints.com> References: <485977C7.8060501@secure-endpoints.com> <200806182241.m5IMf4bY002032@toasties.srv.cs.cmu.edu> <81B673EB674BDD5405DC6D5D@sirius.fac.cs.cmu.edu> <486124E7.4080302@secure-endpoints.com> Message-ID: <20080624165844.GT2735@Sun.COM> On Tue, Jun 24, 2008 at 12:46:31PM -0400, Jeffrey Altman wrote: > Jeffrey Hutzelman wrote: > >The presumption here is that there _is_ a "master" which is "more > >definitive". > For MIT Kerberos the introduction of "master_kdc" says exactly that. > There is in fact a master and that master is more definitive. That is > how the clients already work when it comes to AS requests. Our > proposal is to extend that behavior to TGS requests. > > If there is no defined master, then there is no master to fallback to. I think this has to default to off. TGS requests usually outnumber AS requests by a fair amount. I don't think the client should begin to behave in a way that seriously challenges the KDC infrastructure performance assumptions made by sysadmins in the past. Nico -- From hotz at jpl.nasa.gov Tue Jun 24 13:04:36 2008 From: hotz at jpl.nasa.gov (Henry B. Hotz) Date: Tue, 24 Jun 2008 10:04:36 -0700 Subject: Ticket 5338: Race conditions in key rotation In-Reply-To: References: Message-ID: <71D21849-E3FD-4E69-874D-FCD45BC41F94@jpl.nasa.gov> On Jun 23, 2008, at 11:30 PM, krbdev-request at mit.edu wrote: >> In the long term, I'd rather see the synchronization problem >> addressed >> well, so that the clients don't have to do any of this sort of thing. >> Incremental propagation support will help, though Sun's >> implementation >> that I'm looking at integrating uses a periodic polling model, not an >> instantaneous push model. However it should cut down the delay >> needed >> for propagation, so you can say, e.g., "after a new service is >> registered, you may have to wait 30 seconds for the information to >> propagate before you can authenticate to it". (Actually, in the long >> term, I'd like to see a multi-master type arrangement where we don't >> even have a distinguished "master KDC". But failing that, immediate >> propagation of all changes seems like a very desirable substitute.) > > Incremental propagation does not solve race conditions. It just > makes one runner a little faster but the underlying issue still > exists. > > I'm not convinced that I would like to have a multi-master scheme, > it seems that it would add complexity for little additional value. As a practical matter incremental propagation (a la Heimdal, sorry) makes these issues moot, as long as it's reliable enough. If it fails, it should most likely to be due to a network problem, which is exactly what the slave is there to mitigate in my case. I would imagine there are other institutions where you might want a fail_if_stale threshold on a slave. Fail-to-master seems reasonable, but it seems like mitigation rather than solution. ------------------------------------------------------ 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 elric at imrryr.org Tue Jun 24 13:47:32 2008 From: elric at imrryr.org (Roland Dowdeswell) Date: Tue, 24 Jun 2008 13:47:32 -0400 Subject: Ticket 5338: Race conditions in key rotation In-Reply-To: Your message of "Tue, 24 Jun 2008 11:58:44 CDT." <20080624165844.GT2735@Sun.COM> Message-ID: <20080624174732.EA63837044@arioch.imrryr.org> On 1214326724 seconds since the Beginning of the UNIX epoch Nicolas Williams wrote: > >On Tue, Jun 24, 2008 at 12:46:31PM -0400, Jeffrey Altman wrote: >> Jeffrey Hutzelman wrote: >> >The presumption here is that there _is_ a "master" which is "more >> >definitive". >> For MIT Kerberos the introduction of "master_kdc" says exactly that. >> There is in fact a master and that master is more definitive. That is >> how the clients already work when it comes to AS requests. Our >> proposal is to extend that behavior to TGS requests. >> >> If there is no defined master, then there is no master to fallback to. > >I think this has to default to off. TGS requests usually outnumber AS >requests by a fair amount. I don't think the client should begin to >behave in a way that seriously challenges the KDC infrastructure >performance assumptions made by sysadmins in the past. >From my quick analysis of our traffic, only 1.5% of the requests will be retried on the master. I'm reasonably convinced that our master will be able to deal with a 1.5% usage spike, granted it might slow down a bit but I'm not sure if it will be a measurable amount. My guess would be that most sysadmins provision master KDCs that can deal with a 1.5% usage increase without falling over. As I said in my previous e-mail, the 1.5% is only based on a few days of usage. And maybe it is a small site, we only get a few million {AS,TGS}_REQs a day. Are there any other examples that we can consider where this would cause more than a few percentage points of additional load? -- Roland Dowdeswell http://www.Imrryr.ORG/~elric/ From elric at imrryr.org Tue Jun 24 13:56:20 2008 From: elric at imrryr.org (Roland Dowdeswell) Date: Tue, 24 Jun 2008 13:56:20 -0400 Subject: Ticket 5338: Race conditions in key rotation In-Reply-To: Your message of "Tue, 24 Jun 2008 10:04:36 PDT." <71D21849-E3FD-4E69-874D-FCD45BC41F94@jpl.nasa.gov> Message-ID: <20080624175620.4620E37465@arioch.imrryr.org> On 1214327076 seconds since the Beginning of the UNIX epoch "Henry B. Hotz" wrote: > >> Incremental propagation does not solve race conditions. It just >> makes one runner a little faster but the underlying issue still >> exists. >> >> I'm not convinced that I would like to have a multi-master scheme, >> it seems that it would add complexity for little additional value. > >As a practical matter incremental propagation (a la Heimdal, sorry) >makes these issues moot, as long as it's reliable enough. If it >fails, it should most likely to be due to a network problem, which is >exactly what the slave is there to mitigate in my case. I would >imagine there are other institutions where you might want a >fail_if_stale threshold on a slave. An example of a case which incremental propagation does not not mitigate is changing your TGS key if you round robin between KDCs in a random order. If you get kvno 7 from the first slave and then present it to another slave which has only kvno 6 then you will get a failure. A lot of environments will use the TGT immediately after it is obtained in order to get AFS tokens. So, your window is a few milliseconds. >Fail-to-master seems reasonable, but it seems like mitigation rather >than solution. You can prove that failing to the master would solve the race as long as the master is available pretty trivially. -- Roland Dowdeswell http://www.Imrryr.ORG/~elric/ From tlyu at MIT.EDU Tue Jun 24 15:48:12 2008 From: tlyu at MIT.EDU (Tom Yu) Date: Tue, 24 Jun 2008 15:48:12 -0400 Subject: authorization data plug-in interface Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Apple, Inc. has contributed a KDC plug-in interface for inserting authorization data into tickets. It is revision 19834 in the users/austinj/authdata_plugin directory of the subversion repository. For anonymous access to this part of the repository, you may use the subversion URL svn://anonsvn.mit.edu/krb5/users/austinj/authdata_plugin Please review this contribution. We are interested in feedback on both the code and on whether the interface meets your needs. - -- Tom Yu Development Manager MIT Kerberos Consortium -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (SunOS) iEYEARECAAYFAkhhT4MACgkQSO8fWy4vZo7/5wCfchwxdAzmk26KNe9kgynKAH0d /cAAoMoWwhhNXCorrPiQdiTvgewB74W5 =Wo8C -----END PGP SIGNATURE----- From Nicolas.Williams at sun.com Tue Jun 24 18:33:19 2008 From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Tue, 24 Jun 2008 17:33:19 -0500 Subject: Ticket 5338: Race conditions in key rotation In-Reply-To: <20080624175620.4620E37465@arioch.imrryr.org> References: <71D21849-E3FD-4E69-874D-FCD45BC41F94@jpl.nasa.gov> <20080624175620.4620E37465@arioch.imrryr.org> Message-ID: <20080624223319.GC2735@Sun.COM> On Tue, Jun 24, 2008 at 01:56:20PM -0400, Roland Dowdeswell wrote: > An example of a case which incremental propagation does not not > mitigate is changing your TGS key if you round robin between KDCs > in a random order. If you get kvno 7 from the first slave and then > present it to another slave which has only kvno 6 then you will > get a failure. A lot of environments will use the TGT immediately > after it is obtained in order to get AFS tokens. So, your window > is a few milliseconds. IMO the correct way to handle this is to first add a new key _disabled_ (the key, not the principal) so that the key is not used when _issuing_ TGTs but it's still available for decrypting TGTs encrypted in that key, wait for replication, then mark the key enabled and replicate. This way when the first KDC (the master) starts using the new TGS key all the other KDCs will have it already and will be able to decrypt the new TGTs. Nico -- From elric at imrryr.org Tue Jun 24 21:56:36 2008 From: elric at imrryr.org (Roland Dowdeswell) Date: Tue, 24 Jun 2008 21:56:36 -0400 Subject: Ticket 5338: Race conditions in key rotation In-Reply-To: Your message of "Tue, 24 Jun 2008 17:33:19 CDT." <20080624223319.GC2735@Sun.COM> Message-ID: <20080625015636.32A6137044@arioch.imrryr.org> On 1214346799 seconds since the Beginning of the UNIX epoch Nicolas Williams wrote: > >On Tue, Jun 24, 2008 at 01:56:20PM -0400, Roland Dowdeswell wrote: >> An example of a case which incremental propagation does not not >> mitigate is changing your TGS key if you round robin between KDCs >> in a random order. If you get kvno 7 from the first slave and then >> present it to another slave which has only kvno 6 then you will >> get a failure. A lot of environments will use the TGT immediately >> after it is obtained in order to get AFS tokens. So, your window >> is a few milliseconds. > >IMO the correct way to handle this is to first add a new key _disabled_ >TGTs but it's still available for decrypting TGTs encrypted in that key, >wait for replication, then mark the key enabled and replicate. > >This way when the first KDC (the master) starts using the new TGS key >all the other KDCs will have it already and will be able to decrypt the >new TGTs. Sure, that was my first thought as well. It is the obvious answer. When I sat down and thought about it for quite a while, though, that didn't seem as good as failing back to the master. Perhaps one could get a better system with a hybrid model... And a rather important point is that I am specifically talking about client behaviour here. Not KDC behaviour. Let's not make the mistake of assuming that either: 1. the client libraries versions are in sync with the KDC version, or 2. that this decision should be made by the KDC infrastructure. So, as a client here is your flow: 1. you got a TGT with kvno 7 from a slave, 2. there was mutual auth involved---so you know that you got it from a _real_ slave, 3. you present it to another slave and it does not work, 4. now, you _know_ that there exists a slave for which this request would actually work, 5. and yet you decide to fail... Given 4, why exactly does 5 make sense? By this, I mean: ``please provide me with a justification as to why I should suffer a production outage which might cost a substantial amount of money because a client decided to fail when it can be demonstrated that it had or should have had enough information to avert the problem''. I do not think that this logic changes substantially if you attempt to keep the KDCs in sync. You might still have problems and a relatively inexpensive mechanism either failing back to the master to trying another slave would improve the odds of success. For each step in the process, care should be taken to ensure that simple steps to improve the odds are actually taken. -- Roland Dowdeswell http://www.Imrryr.ORG/~elric/ From Mark.Phalan at Sun.COM Wed Jun 25 06:30:04 2008 From: Mark.Phalan at Sun.COM (Mark Phalan) Date: Wed, 25 Jun 2008 12:30:04 +0200 Subject: supported/used salt types Message-ID: <1214389804.7312.40.camel@zup> src/lib/krb5/krb/str_conv.c implies the following salt-types are supported: "normal" "v4" "norealm" "onlyrealm" "special" "afs3" Which of these is actually used/useful? Would it be fair to say that "normal" and "afs3" are the only ones that are in regular use? Cheers, -Mark From kulg123 at gmail.com Wed Jun 25 07:34:18 2008 From: kulg123 at gmail.com (kul gupta) Date: Wed, 25 Jun 2008 17:04:18 +0530 Subject: GSSAPI + IAKERB Message-ID: <2203f95e0806250434t4e7ecdcfu9b87ccde3497c248@mail.gmail.com> Hello I was going through IAKERB and have some doubts I will be highly thankful if anyone can clear my doubts. 1) Can someone please explain me the scenerio for using IAKERB.? 2) I have to go fopr GSSAPI for IAKERB implementation?? 3) Is there any sample code available for the same? Thanks kul From jason.gerfen at scl.utah.edu Wed Jun 25 09:11:12 2008 From: jason.gerfen at scl.utah.edu (Jason Gerfen) Date: Wed, 25 Jun 2008 07:11:12 -0600 Subject: krb5.conf and db options Message-ID: <486243F0.7090902@scl.utah.edu> I read the man page regarding the section on dbmodules and would like some clarification. Is these directory options used by the KDC only? Or can the client utilize these options for something other retrieving stashed passwords? Thanks -- Jas From raeburn at MIT.EDU Wed Jun 25 11:28:49 2008 From: raeburn at MIT.EDU (Ken Raeburn) Date: Wed, 25 Jun 2008 11:28:49 -0400 Subject: krb5.conf and db options In-Reply-To: <486243F0.7090902@scl.utah.edu> References: <486243F0.7090902@scl.utah.edu> Message-ID: On Jun 25, 2008, at 09:11, Jason Gerfen wrote: > I read the man page regarding the section on dbmodules and would like > some clarification. > > Is these directory options used by the KDC only? Or can the client > utilize these options for something other retrieving stashed > passwords? Anything that directly accesses the database -- krb5kdc, kadmind, kadmin.local, etc -- would use this information to find out how to access the database. Client-side programs like kpasswd or kadmin do not use it; they talk to servers running on the KDC. Ken From jhutz at cmu.edu Wed Jun 25 12:18:50 2008 From: jhutz at cmu.edu (Jeffrey Hutzelman) Date: Wed, 25 Jun 2008 12:18:50 -0400 Subject: Ticket 5338: Race conditions in key rotation In-Reply-To: <200806250157.m5P1vjsb023611@grapenut.srv.cs.cmu.edu> References: <200806250157.m5P1vjsb023611@grapenut.srv.cs.cmu.edu> Message-ID: <099B089344A016E12CE32A9E@sirius.fac.cs.cmu.edu> --On Tuesday, June 24, 2008 09:56:36 PM -0400 Roland Dowdeswell wrote: > On 1214346799 seconds since the Beginning of the UNIX epoch > Nicolas Williams wrote: >> > >> On Tue, Jun 24, 2008 at 01:56:20PM -0400, Roland Dowdeswell wrote: >>> An example of a case which incremental propagation does not not >>> mitigate is changing your TGS key if you round robin between KDCs >>> in a random order. If you get kvno 7 from the first slave and then >>> present it to another slave which has only kvno 6 then you will >>> get a failure. A lot of environments will use the TGT immediately >>> after it is obtained in order to get AFS tokens. So, your window >>> is a few milliseconds. >> >> IMO the correct way to handle this is to first add a new key _disabled_ >> TGTs but it's still available for decrypting TGTs encrypted in that key, >> wait for replication, then mark the key enabled and replicate. >> >> This way when the first KDC (the master) starts using the new TGS key >> all the other KDCs will have it already and will be able to decrypt the >> new TGTs. > > Sure, that was my first thought as well. It is the obvious answer. > When I sat down and thought about it for quite a while, though, > that didn't seem as good as failing back to the master. Perhaps > one could get a better system with a hybrid model... > > And a rather important point is that I am specifically talking about > client behaviour here. Not KDC behaviour. Let's not make the mistake > of assuming that either: > > 1. the client libraries versions are in sync with > the KDC version, or > > 2. that this decision should be made by the KDC > infrastructure. > > So, as a client here is your flow: > > 1. you got a TGT with kvno 7 from a slave, > > 2. there was mutual auth involved---so you know that you > got it from a _real_ slave, > > 3. you present it to another slave and it does not work, > > 4. now, you _know_ that there exists a slave for which this > request would actually work, No, you don't. The service principal may not exist. It may be disabled. There may be no mutually-supported enctype. _Your_ principal may be expired. Or any of a number of other things might be wrong, which the KDC may tell you about with an appropriate error code. "No, you are not allowed to have a ticket" means you are not allowed to have a ticket, not "go ask mommy if she will give you one". The issue here is that you are proposing that the answer to a set of KDC's not presenting a consistent view of the realm is not to fix the KDC's, but to require clients to query multiple KDC's and compare their responses, which is not what the protocol specification says. -- Jeff From jhutz at cmu.edu Wed Jun 25 12:26:32 2008 From: jhutz at cmu.edu (Jeffrey Hutzelman) Date: Wed, 25 Jun 2008 12:26:32 -0400 Subject: supported/used salt types In-Reply-To: <200806251034.m5PAY6tj028275@grapenut.srv.cs.cmu.edu> References: <200806251034.m5PAY6tj028275@grapenut.srv.cs.cmu.edu> Message-ID: --On Wednesday, June 25, 2008 12:30:04 PM +0200 Mark Phalan wrote: > > src/lib/krb5/krb/str_conv.c implies the following salt-types are > supported: > > "normal" > "v4" > "norealm" > "onlyrealm" > "special" > "afs3" > > > Which of these is actually used/useful? Would it be fair to say that > "normal" and "afs3" are the only ones that are in regular use? I think it's fair to say that "norealm" and "onlyrealm" are more or less never used. The others are all used... - "normal" is the default salt string based on principal name and realm, and is or should be the most widely used case - "v4" is an empty salt string. This is used to produce keys which are used to answer requests from Kerberos 4 clients, and also on keys imported during a conversion from a Kerberos 4 database. - "special", IIRC, is the salt type used when the actual salt string is explicitly contained in the KDB. This is used when a principal is renamed, such that the actual salt string used to generate its key is no longer as that generated by the "normal" method. - "afs3" is the salt string used by the AFS kaserver and its clients. It consists of the realm name forced to lower case, but also indicates use of an alternate string-to-key algorithm for DES keys (and should be invalid on any other enctypes). -- Jeff From jhutz at cmu.edu Wed Jun 25 12:33:18 2008 From: jhutz at cmu.edu (Jeffrey Hutzelman) Date: Wed, 25 Jun 2008 12:33:18 -0400 Subject: GSSAPI + IAKERB In-Reply-To: <200806251158.m5PBw2eT025506@raisinbran.srv.cs.cmu.edu> References: <200806251158.m5PBw2eT025506@raisinbran.srv.cs.cmu.edu> Message-ID: <526C046F05EEC2A94531131F@sirius.fac.cs.cmu.edu> --On Wednesday, June 25, 2008 05:04:18 PM +0530 kul gupta wrote: > Hello > > I was going through IAKERB and have some doubts > I will be highly thankful if anyone can clear my doubts. > > 1) Can someone please explain me the scenerio for using IAKERB.? Take a look at section 1 of draft-ietf-krb-wg-iakerb-00.txt, available from . Note that the older draft-ietf-cat-iakerb document has not been touched in several years, and is superceded by the krb-wg document. > 2) I have to go fopr GSSAPI for IAKERB implementation?? Yes, IAKERB is a GSS-API mechanism. > 3) Is there any sample code available for the same? Probably not; the new IAKERB document is still in the first stages of development. If anyone knows of an implementation of this, please speak up. If you have comments on IAKERB, please address them to the IETF Kerberos working group mailing list, ietf-krb-wg at anl.gov (this is an open list; subscribe at ). -- Jeffrey T. Hutzelman (N3NHS) Co-chair, IETF Kerberos Working Group Carnegie Mellon University - Pittsburgh, PA From elric at imrryr.org Wed Jun 25 12:47:01 2008 From: elric at imrryr.org (Roland Dowdeswell) Date: Wed, 25 Jun 2008 12:47:01 -0400 Subject: Ticket 5338: Race conditions in key rotation In-Reply-To: Your message of "Wed, 25 Jun 2008 12:18:50 EDT." <099B089344A016E12CE32A9E@sirius.fac.cs.cmu.edu> Message-ID: <20080625164701.B8C1A374F4@arioch.imrryr.org> On 1214410730 seconds since the Beginning of the UNIX epoch Jeffrey Hutzelman wrote: > >No, you don't. The service principal may not exist. It may be disabled. >There may be no mutually-supported enctype. _Your_ principal may be >expired. Or any of a number of other things might be wrong, which the KDC >may tell you about with an appropriate error code. > >"No, you are not allowed to have a ticket" means you are not allowed to >have a ticket, not "go ask mommy if she will give you one". It is true that it is not guaranteed that the master will not also return an error. Given that the KRB_ERROR message is not encrypted, all the client really knows is that some random entity on the internet has just told them to go away... >The issue here is that you are proposing that the answer to a set of KDC's >not presenting a consistent view of the realm is not to fix the KDC's, but >to require clients to query multiple KDC's and compare their responses, >which is not what the protocol specification says. Really? Are we talking about RFC 4120? Please point me to the section of that document where it specifies what the client behaviour should be when it receives an error from a slave KDC? I did find the following section in the RFC: 3.1.6. Receipt of KRB_ERROR Message If the reply message type is KRB_ERROR, then the client interprets it as an error and performs whatever application-specific tasks are necessary for recovery. I am not actually convinced that ``recovery'' does not preclude trying another KDC just to make sure. In fact, given that the MIT Kerberos libraries currently do fail back to the master upon the receipt of certain KRB_ERRORs in certain situations, I can be pretty sure that it has at least in the past not been interpreted in such a way. So, how is this in violation of the standards again? We also have: 5.9. Error Message Specification This section specifies the format for the KRB_ERROR message. The fields included in the message are intended to return as much information as possible about an error. It is not expected that all the information required by the fields will be available for all types of errors. If the appropriate information is not available when the message is composed, the corresponding field will be left out of the message. Note that because the KRB_ERROR message is not integrity protected, it is quite possible for an intruder to synthesize or modify it. In particular, this means that the client SHOULD NOT use any fields in this message for security-critical purposes, such as setting a system clock or generating a fresh authenticator. The message can be useful, however, for advising a user on the reason for some failure. So, now we know that we are not supposed to use the KRB_ERROR message for security critical purposes. That makes me a little less likely to agree with you. -- Roland Dowdeswell http://www.Imrryr.ORG/~elric/ From jaltman at secure-endpoints.com Wed Jun 25 13:06:53 2008 From: jaltman at secure-endpoints.com (Jeffrey Altman) Date: Wed, 25 Jun 2008 13:06:53 -0400 Subject: Ticket 5338: Race conditions in key rotation In-Reply-To: <099B089344A016E12CE32A9E@sirius.fac.cs.cmu.edu> References: <200806250157.m5P1vjsb023611@grapenut.srv.cs.cmu.edu> <099B089344A016E12CE32A9E@sirius.fac.cs.cmu.edu> Message-ID: <48627B2D.40806@secure-endpoints.com> Jeffrey Hutzelman wrote: >> 1. the client libraries versions are in sync with >> the KDC version, or >> >> 2. that this decision should be made by the KDC >> infrastructure. >> >> So, as a client here is your flow: >> >> 1. you got a TGT with kvno 7 from a slave, >> >> 2. there was mutual auth involved---so you know that you >> got it from a _real_ slave, >> >> 3. you present it to another slave and it does not work, >> >> 4. now, you _know_ that there exists a slave for which this >> request would actually work, > > > No, you don't. The service principal may not exist. It may be disabled. > There may be no mutually-supported enctype. _Your_ principal may be > expired. Or any of a number of other things might be wrong, which the KDC > may tell you about with an appropriate error code. Slave KDC 1 from which I received a TGT with kvno N certainly knows the key associated with kvno N. If I went back to Slave KDC 1 and presented the TGT as part of a request it is not going to come back and tell me KRB5_GENERIC see error text to then find "key version number not found". > "No, you are not allowed to have a ticket" means you are not allowed to > have a ticket, not "go ask mommy if she will give you one". The worst part about this situation is that the client really has no idea why the ticket wasn't issued. The client is not getting an error that explains the reason at all. It is getting a KRB5_GENERIC error. > The issue here is that you are proposing that the answer to a set of KDC's > not presenting a consistent view of the realm is not to fix the KDC's, but > to require clients to query multiple KDC's and compare their responses, > which is not what the protocol specification says. The protocol specification doesn't say anything about the subject of master/slave, primary/secondary, or multi-master distributed KDC implementations. It doesn't say that clients MUST, SHOULD, SHOULD NOT, or MUST NOT contact the Master/Primary KDC after a client request fails. The only reference to "fatal" errors are in conjunction with the TCP support which states that a client MUST NOT treat a connection break as a fatal. The only references to "retry" are related to pre-auth methods that the client SHOULD retry and KRB_ERR_RESPONSE_TOO_BIG that is a hint to the client to retry but doesn't say so explicitly. In fact, in section 3.1.6 discussion what a client should do in response to a KRB_ERROR message, it states that the client interprets it as an error and performs "whatever application-specific tasks are necessary for recovery." Perhaps you are interpreting to mean that the krb5 library must pass the error to the calling application and it is the application's responsibility to decide whether or not to retry. However, that is not how I interpret this. The library is part of the application and its job is to handle Kerberos errors internally so that the application can succeed at the task it is attempting to accomplish. If that means retrying, so be it. The KDC deployment architecture selected by an implementation is an implementation specific detail that is independent of the protocol specification. Inconsistencies in the deployment of the implementation specific database are addressed in an implementation specific manner. The MIT clients already do contact the Master/Primary KDC if one is defined for the realm when the client's AS request fails for any reason. This is done explicitly because of the fact that Slave/Secondary KDCs might not have an up to date view of the world. This definition is specified either via the use of the "master_kdc" entry in the realm section of the krb5.conf (the profile) or in DNS SRV records. Nico has commented to say that fail over for AS requests are ok and TGS requests are not because the volume of AS requests is lower than that for TGS requests. In a properly configured realm, the number of failures are going to be small compared to the overall volume of requests to the slaves. This assumption has been verified in real world production realms. If you have data that disputes this, please provide it. The problem here is that no matter what you say a KDC based solution should be, there is no transactional mechanism that you can put in place on an error prone network that will result in all copies of the database being consistent all of the time. By adding additional transactional complexity you can reduce the opportunities for inconsistency but you do so at the cost of the increase in complexity and the expose to failure that the complexity introduces. I certainly do not believe that as a practical matter a client should ask all of known KDCs in turn for an answer if it doesn't get a successful response. However, turning to the known authoritative database to answer the question is perfectly reasonable when it is known that such an authoritative database exists. 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/20080625/eb5459e4/smime-0001.bin From rra at stanford.edu Wed Jun 25 13:06:20 2008 From: rra at stanford.edu (Russ Allbery) Date: Wed, 25 Jun 2008 10:06:20 -0700 Subject: supported/used salt types In-Reply-To: <1214389804.7312.40.camel@zup> (Mark Phalan's message of "Wed\, 25 Jun 2008 12\:30\:04 +0200") References: <1214389804.7312.40.camel@zup> Message-ID: <874p7hqwab.fsf@windlord.stanford.edu> Mark Phalan writes: > src/lib/krb5/krb/str_conv.c implies the following salt-types are > supported: > > "normal" > "v4" > "norealm" > "onlyrealm" > "special" > "afs3" > > Which of these is actually used/useful? Would it be fair to say that > "normal" and "afs3" are the only ones that are in regular use? "v4", which means no salt, is also in regular use and is very useful for certain types of Kerberos v4 migrations. -- Russ Allbery (rra at stanford.edu) From elric at imrryr.org Wed Jun 25 13:59:26 2008 From: elric at imrryr.org (Roland Dowdeswell) Date: Wed, 25 Jun 2008 13:59:26 -0400 Subject: Default enctypes for principals and policies. Message-ID: <20080625175926.15DCB374F4@arioch.imrryr.org> I'd like to offer a quick proposal. I'd like to extend kadmin such that default encryption types can be added to principals and policies so that when changed via either kadmin or kpasswd they would override the system wide default. It turns out that in a number of cases, certain principals may require lower security encryption types such as rc4-hmac than the norm. -- Roland Dowdeswell http://www.Imrryr.ORG/~elric/ From jhutz at cmu.edu Wed Jun 25 15:11:53 2008 From: jhutz at cmu.edu (Jeffrey Hutzelman) Date: Wed, 25 Jun 2008 15:11:53 -0400 (EDT) Subject: Ticket 5338: Race conditions in key rotation In-Reply-To: <48627B2D.40806@secure-endpoints.com> Message-ID: On Wed, 25 Jun 2008, Jeffrey Altman wrote: > The worst part about this situation is that the client really has no > idea why the ticket wasn't issued. The client is not getting an error > that explains the reason at all. It is getting a KRB5_GENERIC error. Yes, I agree that's a problem. > > The issue here is that you are proposing that the answer to a set of KDC's > > not presenting a consistent view of the realm is not to fix the KDC's, but > > to require clients to query multiple KDC's and compare their responses, > > which is not what the protocol specification says. > > The protocol specification doesn't say anything about the subject of > master/slave, primary/secondary, or multi-master distributed KDC > implementations. It doesn't say that clients MUST, SHOULD, SHOULD NOT, > or MUST NOT contact the Master/Primary KDC after a client request fails. No, it doesn't. The key point here is that the spec does not say that clients respond to an error by trying another KDC, so a correct KDC implementation should not depend on that behavior. IMHO, a correct KDC implementation provides a consistent view of the KDB and does not produce spurious errors as a result of a change having been made on one server's copy of the KDB and not another. Note that I don't actually object to a client implementation trying other KDC's. I think it's a bit of a waste, because in 14 years of being a KDC operator using multiple implementations, I cannot ever recall a situation in which we've had a failure because a slave was "broken" and the master was not. We did once have occasional complaints about password changes not propagating quickly enough; we resolved that problem by using Heimdal's incremental propagation, but I can think of other ways to solve the same issue with other KDC's. Note that this is not perfect, and could be done better, but it's never been a problem for us. Still, as you and another poster point out, there is nothing prohibits clients from trying another KDC. There simply is also nothing that requires them to do so, and so what I object to is changing client behavior instead of improving the KDC. > In fact, in section 3.1.6 discussion what a client should do in response > to a KRB_ERROR message, it states that the client interprets it as an > error and performs "whatever application-specific tasks are necessary > for recovery." Perhaps you are interpreting to mean that the krb5 > library must pass the error to the calling application and it is the > application's responsibility to decide whether or not to retry. Actually, my interpretation is that the KRB_ERROR means the Kerberos operation has failed and the library should pass the error to the calling application which then decides what to do next, such as trying another method, or using different credentials, or giving up. I personally don't see "the Kerberos library always retries with another KDC" as an applicaiton-specific task necessary for recovery. However, I don't interpret that section as prohibiting the proposed behavior; I just don't think it is relevant. > The KDC deployment architecture selected by an implementation is an > implementation specific detail that is independent of the protocol > specification. Correct. > Inconsistencies in the deployment of the implementation > specific database are addressed in an implementation specific manner. Yes. In the implementation of the database/KDC/etc, not in the clients, which are not specific to the implementation-specific database. > The MIT clients already do contact the Master/Primary KDC if one is > defined for the realm when the client's AS request fails for any reason. > This is done explicitly because of the fact that Slave/Secondary KDCs > might not have an up to date view of the world. And that's fine, but it's not an excuse for not improving the KDC. > Nico has commented to say that fail over for AS requests are ok and TGS > requests are not because the volume of AS requests is lower than that > for TGS requests. I don't really buy the performance arguments for not doing this. Unless you are doing something bizarre, the number of failures due to legitimate clients is small compared to the number of successful requests, and a non-legitimate client (attacker) is going to do whatever benefits him most, no mater what we decide. > The problem here is that no matter what you say a KDC based solution > should be, there is no transactional mechanism that you can put in place > on an error prone network that will result in all copies of the database > being consistent all of the time. No, but it is possible to design a mechanism in which only servers with a correct database provide service. The original Ubik design does this; only servers which are a member of a quorum may provide _any_ service. Modern AFS relaxes this requirement and allows servers to provide read-only service when not a member of a quorum, because the databases were judged to change slowly enough and in ways that made it better to servce out-of-date data than none at all. It is also possible to use a different metric, such as requiring a quorum of >75% of servers to change the database, and requiring presence of at least 25% of servers to provide service. This allows service without a quorum of servers, and even in multiple zones of a partitioned network, while insuring that no server provides service with out-of-date data. It is also possible to achieve this goal by using an LDAP or RDBMS backend, in which case all KDC's provide the same answers because they are all using the same database (this punts the replication problem to the LDAP or RDBMS subsystem, but both of those have examples of servers which solve this problem). Incidentally, I can easily imagine a scenario in which the proposed change makes things worse, rather than better. Over the next few months, we are planning on transitioning to a model in which the advertised KDC addresses are anycast addresses, with the routes managed by an automatic process which insures they are always handled by KDC's which are functional. This will enable us to more evenly balance load, and also means that once a KDC has failed (or if we want to remove it from service for maintenance), it can be removed from the pool and client requests will always go to a KDC that is up. Now, this will still be a fixed-master system, so the kadmin service will have to be advertised with the master's real name and address. If the master goes down, then kadmin, password-changing, and other services that require modifying the database will be unavailable. However, most clients will not notice because their requests will be routed to another KDC. Until you introduce this change, which causes clients to try the advertised master for every KRB5KDC_ERR_S_PRINCIPAL_UNKNOWN they get during aklog. Now, instead of logins happening as quickly as if there were no server down, they happen as slowly as if we didn't have the anycast pool to begin with. -- Jeff From Mark.Phalan at Sun.COM Wed Jun 25 15:44:14 2008 From: Mark.Phalan at Sun.COM (Mark Phalan) Date: Wed, 25 Jun 2008 21:44:14 +0200 Subject: supported/used salt types In-Reply-To: References: <200806251034.m5PAY6tj028275@grapenut.srv.cs.cmu.edu> Message-ID: <1214423054.7312.55.camel@zup> On Wed, 2008-06-25 at 12:26 -0400, Jeffrey Hutzelman wrote: > --On Wednesday, June 25, 2008 12:30:04 PM +0200 Mark Phalan > wrote: > > > > > src/lib/krb5/krb/str_conv.c implies the following salt-types are > > supported: > > > > "normal" > > "v4" > > "norealm" > > "onlyrealm" > > "special" > > "afs3" > > > > > > Which of these is actually used/useful? Would it be fair to say that > > "normal" and "afs3" are the only ones that are in regular use? > > I think it's fair to say that "norealm" and "onlyrealm" are more or less > never used. The others are all used... > > - "normal" is the default salt string based on principal name and realm, > and is or should be the most widely used case > - "v4" is an empty salt string. This is used to produce keys which are > used to answer requests from Kerberos 4 clients, and also on keys > imported during a conversion from a Kerberos 4 database. > - "special", IIRC, is the salt type used when the actual salt string is > explicitly contained in the KDB. This is used when a principal is > renamed, such that the actual salt string used to generate its key > is no longer as that generated by the "normal" method. Is there a standard way to rename a principal? kadmin doesn't seem to offer an option... > - "afs3" is the salt string used by the AFS kaserver and its clients. > It consists of the realm name forced to lower case, but also indicates > use of an alternate string-to-key algorithm for DES keys (and should > be invalid on any other enctypes). > Thanks for the useful info! -Mark From Mark.Phalan at Sun.COM Wed Jun 25 15:44:29 2008 From: Mark.Phalan at Sun.COM (Mark Phalan) Date: Wed, 25 Jun 2008 21:44:29 +0200 Subject: supported/used salt types In-Reply-To: <874p7hqwab.fsf@windlord.stanford.edu> References: <1214389804.7312.40.camel@zup> <874p7hqwab.fsf@windlord.stanford.edu> Message-ID: <1214423069.7312.57.camel@zup> On Wed, 2008-06-25 at 10:06 -0700, Russ Allbery wrote: > Mark Phalan writes: > > > src/lib/krb5/krb/str_conv.c implies the following salt-types are > > supported: > > > > "normal" > > "v4" > > "norealm" > > "onlyrealm" > > "special" > > "afs3" > > > > Which of these is actually used/useful? Would it be fair to say that > > "normal" and "afs3" are the only ones that are in regular use? > > "v4", which means no salt, is also in regular use and is very useful for > certain types of Kerberos v4 migrations. Ok. Thanks, -M From jaltman at secure-endpoints.com Wed Jun 25 15:49:28 2008 From: jaltman at secure-endpoints.com (Jeffrey Altman) Date: Wed, 25 Jun 2008 15:49:28 -0400 Subject: Ticket 5338: Race conditions in key rotation In-Reply-To: References: Message-ID: <4862A148.5090007@secure-endpoints.com> Jeffrey Hutzelman wrote: > Now, this will still be a fixed-master system, so the kadmin service will > have to be advertised with the master's real name and address. If the > master goes down, then kadmin, password-changing, and other services that > require modifying the database will be unavailable. However, most clients > will not notice because their requests will be routed to another KDC. Note that admin_server and master_kdc in MIT kerberos are independent concepts. admin_server is the list of machines that provide administrative and password change services. master_kdc is the list of servers that are authoritative. They do not have to be the same and in a multi-master world, it is possible that either all or none of the KDCs could be in the master_kdc list. > Until you introduce this change, which causes clients to try the > advertised master for every KRB5KDC_ERR_S_PRINCIPAL_UNKNOWN they get > during aklog. Now, instead of logins happening as quickly as if there > were no server down, they happen as slowly as if we didn't have the > anycast pool to begin with. This is not true. The delay when a server is down is the timeout waiting for any response not the time necessary to get KRB5KDC_ERR_S_PRINCIPAL_UNKNOWN and retry. -------------- 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/20080625/984de3d1/smime-0001.bin From Nicolas.Williams at sun.com Wed Jun 25 16:00:24 2008 From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Wed, 25 Jun 2008 15:00:24 -0500 Subject: New proposal (Re: Ticket 5338: Race conditions in key rotation) In-Reply-To: <20080625015636.32A6137044@arioch.imrryr.org> References: <20080624223319.GC2735@Sun.COM> <20080625015636.32A6137044@arioch.imrryr.org> Message-ID: <20080625200024.GY2735@Sun.COM> I don't oppose the proposed client behavior (fallback to master KDC on generic TGS errors) provided: 1) it's optional, defaulting to off, and 2) a) either you produce an update to RFC4120 describing this normatively OR b) you also produce, prior to or concurrently with (1), support for two-phase commits of new keys for the krbtgt principals (this is also useful for host principals used in clustered systems). I doubt very much that you could get KRB-WG and IETF consensus such a change to RFC4120 anytime soon. Therefore I strongly recomment that you pursue both: (1) and (2b). I can help scope out and design (2b), but don't have cycles for coding, debugging, testing. The good news is that (2b) is mostly about making changes in kadm5 code, with very little impact on krb5kdc, and easy to test. Nico -- From Nicolas.Williams at sun.com Wed Jun 25 16:14:28 2008 From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Wed, 25 Jun 2008 15:14:28 -0500 Subject: New proposal (Re: Ticket 5338: Race conditions in key rotation) In-Reply-To: <20080625200024.GY2735@Sun.COM> References: <20080624223319.GC2735@Sun.COM> <20080625015636.32A6137044@arioch.imrryr.org> <20080625200024.GY2735@Sun.COM> Message-ID: <20080625201428.GZ2735@Sun.COM> On Wed, Jun 25, 2008 at 03:00:24PM -0500, Nicolas Williams wrote: > I doubt very much that you could get KRB-WG and IETF consensus such a > change to RFC4120 anytime soon. Therefore I strongly recomment that you > pursue both: (1) and (2b). As for the rationale: - I understand that in some environments it's easier to update the clients than the KDCs, but that's not always the case (it's almost always technically, if not politically, easier to update the KDCs). Thus a client-side fix can be very desirable in some cases. - However, I believe a client-side fix here, particularly one that lets the KDC implementor off the hook, creates pressure on other client implementors to adopt the same fix. That would be a backdoor change to a standards track Internet protocol. - Therefore I propose that you either make that change to the protocol through normal channels (i.e., publis a new standards track RFC updating the old one), or that you provide a KDC-side solution so that other client implementors have a way out of having to implement this behavior. Nico -- From jhutz at cmu.edu Wed Jun 25 16:15:59 2008 From: jhutz at cmu.edu (Jeffrey Hutzelman) Date: Wed, 25 Jun 2008 16:15:59 -0400 Subject: Ticket 5338: Race conditions in key rotation In-Reply-To: <200806251949.m5PJnAIS019577@raisinbran.srv.cs.cmu.edu> References: <200806251949.m5PJnAIS019577@raisinbran.srv.cs.cmu.edu> Message-ID: <7319CF6426F98F8EDFF9DAD9@sirius.fac.cs.cmu.edu> --On Wednesday, June 25, 2008 03:49:28 PM -0400 Jeffrey Altman wrote: > This is not true. The delay when a server is down is the timeout waiting > for any response > not the time necessary to get KRB5KDC_ERR_S_PRINCIPAL_UNKNOWN and retry. Without your change, the delay when a server is down is the same as the delay when a server is not down, which is the time necessary to get KRB5KDC_ERR_S_PRINCIPAL_UNKNOWN and move on to try the next service principal name. There is no timeout because the routing configuration guarantees the request does not go to the server that is down. With your change, the delay is the time to get KRB5KDC_ERR_S_PRINCIPAL_UNKNOWN from a working server, plus the time to timeout the request to the admin server, which is down. Unless, of course, I'm misreading your earlier statement that > This definition is specified either via the use of the "master_kdc" entry > in the realm section of the krb5.conf (the profile) or in DNS SRV records. -- Jeff From steve.terapak at jackinthebox.com Tue Jun 24 16:07:57 2008 From: steve.terapak at jackinthebox.com (Steve Terapak) Date: Tue, 24 Jun 2008 13:07:57 -0700 Subject: last kfw samples Message-ID: Hi there -- I am attempting to do some interop with microsoft kerberos libs (SSPI) and would like to see the latest examples for Kerberos for Windows. Steve Terapak From mohamed.chaari at orange-ftgroup.com Wed Jun 25 05:09:50 2008 From: mohamed.chaari at orange-ftgroup.com (mohamed.chaari@orange-ftgroup.com) Date: Wed, 25 Jun 2008 11:09:50 +0200 Subject: GSSAPI Message-ID: Hello, I'm interested to study the security of kerberos V5. I have seen the code, I would like to know if the use of GSSAPI is optionnal or basic in the communication betweew client and server application. If it is basic, why not using the Ksession as a basic key to encrypt messages? Also, I would like if communication between a client and the KDC is encrypted. If it is the case, how it is done? Thanks. From raeburn at MIT.EDU Wed Jun 25 17:08:23 2008 From: raeburn at MIT.EDU (Ken Raeburn) Date: Wed, 25 Jun 2008 17:08:23 -0400 Subject: supported/used salt types In-Reply-To: <1214423054.7312.55.camel@zup> References: <200806251034.m5PAY6tj028275@grapenut.srv.cs.cmu.edu> <1214423054.7312.55.camel@zup> Message-ID: <51B5E65E-09AE-4E9D-B882-6D9956A5DD25@mit.edu> On Jun 25, 2008, at 15:44, Mark Phalan wrote: >> - "special", IIRC, is the salt type used when the actual salt >> string is >> explicitly contained in the KDB. This is used when a principal is >> renamed, such that the actual salt string used to generate its key >> is no longer as that generated by the "normal" method. > > Is there a standard way to rename a principal? kadmin doesn't seem to > offer an option... The functionality exists in the library; I don't know how well tested it is. But glancing at the server side code, it just errors out if the "normal" salt type is used, rather than fixing the salt. I think there's a patch floating around to make it available via kadmin. It would make sense to fix this up to DTRT in the normal salt case and (separately) make it accessible from kadmin in the release... (And take as reiterated here my desire for a "random" salt type that generates a new, long, random string on each password change, to confound key dictionary generation attacks.) Ken From William.Fiveash at sun.com Wed Jun 25 17:12:48 2008 From: William.Fiveash at sun.com (Will Fiveash) Date: Wed, 25 Jun 2008 16:12:48 -0500 Subject: kadmind memory leaks in recent MIT krb code Message-ID: <20080625211248.GA11011@sun.com> While testing my mkey keytab changes I discovered that kadmind was leaking memory. My branch is based on revision 20367 of the trunk. The leaks fall into one of the following: ADDR BUFADDR TIMESTAMP THREAD CACHE LASTLOG CONTENTS 81b2da0 81b09c8 8e11e41922dd9 1 8178a90 80c35dc 0 libumem.so.1`umem_cache_alloc_debug+0x14f libumem.so.1`umem_cache_alloc+0x144 libumem.so.1`umem_alloc+0xc5 libumem.so.1`malloc+0x27 libc.so.1`strdup+0x28 libkrb5support.so.0.1`krb5int_get_error+0x190 libkrb5.so.3.3`krb5_get_error_message+0x28 get_policy_2_svc+0x1b4 kadm_1+0x615 libgssrpc.so.4.0`gssrpc_svc_getreqset+0x2a0 kadm_svc_run+0xe5 main+0xd27 _start+0x80 It looks like there are a number of places calling krb5_get_error_message() that are not freeing the returned error string. ============================================================================= ADDR BUFADDR TIMESTAMP THREAD CACHE LASTLOG CONTENTS 818e718 818b640 8e2eb8f39eb39 1 8178390 80cbed8 0 libumem.so.1`umem_cache_alloc_debug+0x14f libumem.so.1`umem_cache_alloc+0x144 libumem.so.1`umem_alloc+0xc5 libumem.so.1`malloc+0x27 libgssapi_krb5.so.2.2`gss_add_cred+0x23b libgssapi_krb5.so.2.2`gss_acquire_cred+0x11e libgssrpc.so.4.0`gssrpc__svcauth_gss+0x47f libgssrpc.so.4.0`gssrpc__authenticate+0x8d libgssrpc.so.4.0`gssrpc_svc_getreqset+0x132 kadm_svc_run+0xe5 main+0xd27 _start+0x80 Not sure what the exact cause is as malloc() is called in several places in gss_add_cred(). ======================================================================== The overall stats look like: CACHE LEAKED BUFCTL CALLER 08178a90 2140 081b2da0 libc.so.1`strdup+0x28 08178a90 710 08202978 libc.so.1`strdup+0x28 0817b010 710 081b3718 libc.so.1`strdup+0x28 0817b010 709 081b7900 libc.so.1`strdup+0x28 0817b390 6497 081aa948 libgssapi_krb5.so.2.2`gss_acquire_cred+0xb7 08178390 6497 0818e718 libgssapi_krb5.so.2.2`gss_add_cred+0x23b 08178390 6497 0818e6a0 libgssapi_krb5.so.2.2`gss_add_cred+0x253 08178710 6497 08193b68 libgssapi_krb5.so.2.2`gss_add_cred+0x2e0 08178390 2 08d58230 libgssrpc.so.4.0`gssrpc__svcauth_gss+0x98 0817c010 2 081d0b10 libgssrpc.so.4.0`gssrpc__svcauth_gss+0xb1 08178710 1 08196ec0 libkrb5.so.3.3`krb5_ktfile_resolve+0x1c ------------------------------------------------------------------------ Total 30262 buffers, 823864 bytes Are these leaks known or should I open bugs? -- Will Fiveash Sun Microsystems Inc. http://opensolaris.org/os/project/kerberos/ From jaltman at secure-endpoints.com Wed Jun 25 17:51:08 2008 From: jaltman at secure-endpoints.com (Jeffrey Altman) Date: Wed, 25 Jun 2008 17:51:08 -0400 Subject: Ticket 5338: Race conditions in key rotation In-Reply-To: <7319CF6426F98F8EDFF9DAD9@sirius.fac.cs.cmu.edu> References: <200806251949.m5PJnAIS019577@raisinbran.srv.cs.cmu.edu> <7319CF6426F98F8EDFF9DAD9@sirius.fac.cs.cmu.edu> Message-ID: <4862BDCC.7070001@secure-endpoints.com> Jeffrey Hutzelman wrote: > --On Wednesday, June 25, 2008 03:49:28 PM -0400 Jeffrey Altman > wrote: > >> This is not true. The delay when a server is down is the timeout >> waiting >> for any response >> not the time necessary to get KRB5KDC_ERR_S_PRINCIPAL_UNKNOWN and retry. > > Without your change, the delay when a server is down is the same as > the delay when a server is not down, which is the time necessary to > get KRB5KDC_ERR_S_PRINCIPAL_UNKNOWN and move on to try the next > service principal name. There is no timeout because the routing > configuration guarantees the request does not go to the server that is > down. Then why did you raise the issue of the timeout when the server was down? > > With your change, the delay is the time to get > KRB5KDC_ERR_S_PRINCIPAL_UNKNOWN from a working server, plus the time > to timeout the request to the admin server, which is down. > > > Unless, of course, I'm misreading your earlier statement that > >> This definition is specified either via the use of the "master_kdc" >> entry >> in the realm section of the krb5.conf (the profile) or in DNS SRV >> records. Its not the admin_server unless your master_kdc and admin_server records are pointing to the same machines. But yes, if the master_kdc is down there will be an added delay with this logic. Of course, we really need to find a better way to obtain afs service tickets that doesn't involved N best guesses to figure out what the correct realm should be and what the correct principal format should be. Is it afs at REALM or afs/cell at REALM and with rxk5 or rxgk some additional principal name form? But this is getting severely off topic. -------------- 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/20080625/2ad065f7/smime-0001.bin From jhutz at cmu.edu Wed Jun 25 18:24:54 2008 From: jhutz at cmu.edu (Jeffrey Hutzelman) Date: Wed, 25 Jun 2008 18:24:54 -0400 Subject: Ticket 5338: Race conditions in key rotation In-Reply-To: <200806252150.m5PLoXQu028632@grapenut.srv.cs.cmu.edu> References: <200806251949.m5PJnAIS019577@raisinbran.srv.cs.cmu.edu> <7319CF6426F98F8EDFF9DAD9@sirius.fac.cs.cmu.edu> <200806252150.m5PLoXQu028632@grapenut.srv.cs.cmu.edu> Message-ID: <0107E27B5C8589CD0D00AF09@sirius.fac.cs.cmu.edu> --On Wednesday, June 25, 2008 05:51:08 PM -0400 Jeffrey Altman wrote: > Its not the admin_server unless your master_kdc and admin_server records > are pointing to the same > machines. I'm sorry, what records are those? I have SRV records for _KERBEROS._TCP _KERBEROS._UDP _KPASSWD._UDP _KRB524._UDP Which of these records does the MIT code use, and does your proposal use, for identifying the "master" KDC in the absence of configuration in krb5.conf? -- Jeff From jaltman at secure-endpoints.com Wed Jun 25 18:58:12 2008 From: jaltman at secure-endpoints.com (Jeffrey Altman) Date: Wed, 25 Jun 2008 18:58:12 -0400 Subject: Ticket 5338: Race conditions in key rotation In-Reply-To: <0107E27B5C8589CD0D00AF09@sirius.fac.cs.cmu.edu> References: <200806251949.m5PJnAIS019577@raisinbran.srv.cs.cmu.edu> <7319CF6426F98F8EDFF9DAD9@sirius.fac.cs.cmu.edu> <200806252150.m5PLoXQu028632@grapenut.srv.cs.cmu.edu> <0107E27B5C8589CD0D00AF09@sirius.fac.cs.cmu.edu> Message-ID: <4862CD84.7080107@secure-endpoints.com> Jeffrey Hutzelman wrote: > --On Wednesday, June 25, 2008 05:51:08 PM -0400 Jeffrey Altman > wrote: > >> Its not the admin_server unless your master_kdc and admin_server records >> are pointing to the same >> machines. > > I'm sorry, what records are those? > > I have SRV records for > _KERBEROS._TCP > _KERBEROS._UDP > _KPASSWD._UDP > _KRB524._UDP > > Which of these records does the MIT code use, and does your proposal > use, for identifying the "master" KDC in the absence of configuration > in krb5.conf? _kerberos-master._udp. _kerberos-master._tcp. See http://web.mit.edu/kerberos/krb5-1.6/krb5-1.6.3/doc/krb5-admin.html#Hostnames-for-KDCs -------------- 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/20080625/1d1aa1c1/smime.bin From William.Fiveash at sun.com Wed Jun 25 19:14:15 2008 From: William.Fiveash at sun.com (Will Fiveash) Date: Wed, 25 Jun 2008 18:14:15 -0500 Subject: need codereview for krb consortium masterkey keytab stash project Message-ID: <20080625231415.GA26989@sun.com> I'm requesting a code review of the changes I made to implement the Masterkey Keytab Stash project. The project page is: http://k5wiki.kerberos.org/wiki/Projects/Masterkey_Keytab_Stash The subversion branch is krb5/branches/mkey_keytab. The RT ticket is 5993. Please send comments to this list as well as William.Fiveash at sun.com. Deadline for comments is July 11, 2008. -- Will Fiveash Sun Microsystems Inc. http://opensolaris.org/os/project/kerberos/ From Nicolas.Williams at sun.com Wed Jun 25 19:31:11 2008 From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Wed, 25 Jun 2008 18:31:11 -0500 Subject: need codereview for krb consortium masterkey keytab stash project In-Reply-To: <20080625231415.GA26989@sun.com> References: <20080625231415.GA26989@sun.com> Message-ID: <20080625233111.GN2735@Sun.COM> On Wed, Jun 25, 2008 at 06:14:15PM -0500, Will Fiveash wrote: > I'm requesting a code review of the changes I made to implement the > Masterkey Keytab Stash project. The project page is: > > http://k5wiki.kerberos.org/wiki/Projects/Masterkey_Keytab_Stash > > The subversion branch is krb5/branches/mkey_keytab. > The RT ticket is 5993. > > Please send comments to this list as well as William.Fiveash at sun.com. > Deadline for comments is July 11, 2008. Is there no way to generate a "webrev"? From William.Fiveash at sun.com Wed Jun 25 20:27:12 2008 From: William.Fiveash at sun.com (Will Fiveash) Date: Wed, 25 Jun 2008 19:27:12 -0500 Subject: need codereview for krb consortium masterkey keytab stash project In-Reply-To: <20080625233111.GN2735@Sun.COM> References: <20080625231415.GA26989@sun.com> <20080625233111.GN2735@Sun.COM> Message-ID: <20080626002712.GB26989@sun.com> On Wed, Jun 25, 2008 at 06:31:11PM -0500, Nicolas Williams wrote: > On Wed, Jun 25, 2008 at 06:14:15PM -0500, Will Fiveash wrote: > > I'm requesting a code review of the changes I made to implement the > > Masterkey Keytab Stash project. The project page is: > > > > http://k5wiki.kerberos.org/wiki/Projects/Masterkey_Keytab_Stash > > > > The subversion branch is krb5/branches/mkey_keytab. > > The RT ticket is 5993. > > > > Please send comments to this list as well as William.Fiveash at sun.com. > > Deadline for comments is July 11, 2008. > > Is there no way to generate a "webrev"? This is a subversion repository and I was told that normally people use the svn diff facilities to review. On my Mac I use svnX which uses the Filemerge app to display the diffs. If you have a way for people to easily generate a webrev in a svn branch I'm all ears. -- Will Fiveash Sun Microsystems Inc. http://opensolaris.org/os/project/kerberos/ From elric at imrryr.org Thu Jun 26 03:02:45 2008 From: elric at imrryr.org (Roland Dowdeswell) Date: Thu, 26 Jun 2008 03:02:45 -0400 Subject: New proposal (Re: Ticket 5338: Race conditions in key rotation) In-Reply-To: Your message of "Wed, 25 Jun 2008 15:14:28 CDT." <20080625201428.GZ2735@Sun.COM> Message-ID: <20080626070245.6674837449@arioch.imrryr.org> On 1214424868 seconds since the Beginning of the UNIX epoch Nicolas Williams wrote: > > - Therefore I propose that you either make that change to the protocol > through normal channels (i.e., publis a new standards track RFC > updating the old one), or that you provide a KDC-side solution so > that other client implementors have a way out of having to implement > this behavior. A poor man's solution to the TGS key issue would be: 1. if you receive a TGS_REQ with a TGT with a kvno higher than you have, then you know: i. the client has authenticated the KDC from which it received the TGT, ii. therefore, there exists a KDC which has the key unless there is a client bug, iii. some client libraries will experience a fatal error if you return KRB_ERROR, and 2. you can simply fail to respond with the knowledge that in most cases the client will eventually find the correct KDC. I'm less fond of this than client side logic but as you point out it might be preferable to have a KDC-side solution. It has ``issues''. In conjunction with the aforementioned transactional logic, this would be reasonable. But, the transactional logic by itself begs too many questions in my opinion to be robust. I do not think that there are reasonable semantics for network partitions. Obviously, just having slaves turn themselves off if they haven't heard from the master for a while defeats one of the main purposes of having slaves: that they can respond when the master is not reachable. This is a very small subset of ``KDCs that have not been propagated to stop responding''. It is more ``KDCs fail to respond to exactly one kind of request which they can demonstrate that they do not have a good answer to''. Given that failing on UDP to a lack of a response takes a bit of time, it would probably make sense to define an error which mandates the immediate failover. That would require modifications to the client-side libraries. -- Roland Dowdeswell http://www.Imrryr.ORG/~elric/ From raeburn at MIT.EDU Thu Jun 26 09:52:04 2008 From: raeburn at MIT.EDU (Ken Raeburn) Date: Thu, 26 Jun 2008 09:52:04 -0400 Subject: New proposal (Re: Ticket 5338: Race conditions in key rotation) In-Reply-To: <20080626070245.6674837449@arioch.imrryr.org> References: <20080626070245.6674837449@arioch.imrryr.org> Message-ID: <831121AF-FFD7-46E0-90B3-D2E9E1F3DE4F@mit.edu> > Obviously, > just having slaves turn themselves off if they haven't heard from > the master for a while defeats one of the main purposes of having > slaves: that they can respond when the master is not reachable. True. On the other hand, if slave propagations can be blocked (e.g., an attacker sniffing packets sends a RST each time the propagation starts up), then the attacker can ensure that the slave won't see password changes, but will still issue tickets, giving an attacker more time for online attacks on users' keys. Even if it's an old password by the time it gets cracked, and not directly useful on a server other than that slave, the attacker will still be able to get valid credentials, including password-changing credentials, from the slave. The outdated slave will also fail to implement any new restrictions (shorter ticket lifetimes, changes to authorization data, etc) that may have been imposed, which may be bad from an administrative perspective. So there are some arguments in favor of not running the slave on old data indefinitely, at least automatically. > Given that failing on UDP to a lack of a response takes a bit of > time, it would probably make sense to define an error which mandates > the immediate failover. That would require modifications to the > client-side libraries. KDC_ERR_SVC_UNAVAILABLE? From kulg123 at gmail.com Thu Jun 26 10:54:40 2008 From: kulg123 at gmail.com (kul gupta) Date: Thu, 26 Jun 2008 20:24:40 +0530 Subject: windows+KDC+Lib files Message-ID: <2203f95e0806260754j6462fd04i67b94f2a30c057d5@mail.gmail.com> Hi I am trying to build a kerberos client on windows os and KDC (MIT kerberos) lying on a linux server. I am trying to use the kerberos krb5_get_init_creds_password() but i am not able to find the lib files for the with the MIT kerberos windows installation. where can i get the lib files for the kerberos libs on windows or is there any way i can call kerberos api. How should i configure kerberos client on windows i.e how to do krb5.conf setting Thanks and Regards kul From elric at imrryr.org Thu Jun 26 11:26:09 2008 From: elric at imrryr.org (Roland Dowdeswell) Date: Thu, 26 Jun 2008 11:26:09 -0400 Subject: New proposal (Re: Ticket 5338: Race conditions in key rotation) In-Reply-To: Your message of "Thu, 26 Jun 2008 09:52:04 EDT." <831121AF-FFD7-46E0-90B3-D2E9E1F3DE4F@mit.edu> Message-ID: <20080626152609.C585D3752F@arioch.imrryr.org> On 1214488324 seconds since the Beginning of the UNIX epoch Ken Raeburn wrote: > >> Given that failing on UDP to a lack of a response takes a bit of >> time, it would probably make sense to define an error which mandates >> the immediate failover. That would require modifications to the >> client-side libraries. > >KDC_ERR_SVC_UNAVAILABLE? If this is a standards change, let me suggest that errors be encoded in a way similar to SMTP with an explicit statement from the KDC about whether the error be permanent or transient. That way, future errors can be dealt with by legacy clients in a decent way. -- Roland Dowdeswell http://www.Imrryr.ORG/~elric/ From raeburn at MIT.EDU Thu Jun 26 12:18:03 2008 From: raeburn at MIT.EDU (Ken Raeburn) Date: Thu, 26 Jun 2008 12:18:03 -0400 Subject: New proposal (Re: Ticket 5338: Race conditions in key rotation) In-Reply-To: <20080626152609.C585D3752F@arioch.imrryr.org> References: <20080626152609.C585D3752F@arioch.imrryr.org> Message-ID: <0378AABF-1F4C-4ABE-AC8B-180573F53B88@MIT.EDU> On Jun 26, 2008, at 11:26, Roland Dowdeswell wrote: >> KDC_ERR_SVC_UNAVAILABLE? > > If this is a standards change, let me suggest that errors be encoded > in a way similar to SMTP with an explicit statement from the KDC > about whether the error be permanent or transient. That way, future > errors can be dealt with by legacy clients in a decent way. No, it's in RFC 4120, though not well defined there. I believe Microsoft is already using it, and the current MIT client code should treat it as an indication to try another KDC. (And of course I expect the Microsoft client code does so as well.) From Mark.Phalan at Sun.COM Thu Jun 26 12:21:20 2008 From: Mark.Phalan at Sun.COM (Mark Phalan) Date: Thu, 26 Jun 2008 18:21:20 +0200 Subject: kadmind memory leaks in recent MIT krb code In-Reply-To: <20080625211248.GA11011@sun.com> References: <20080625211248.GA11011@sun.com> Message-ID: On 25 Jun 2008, at 23:12, Will Fiveash wrote: > While testing my mkey keytab changes I discovered that kadmind was > leaking memory. My branch is based on revision 20367 of the trunk. > > The leaks fall into one of the following: > > ADDR BUFADDR TIMESTAMP THREAD > CACHE LASTLOG CONTENTS > 81b2da0 81b09c8 8e11e41922dd9 1 > 8178a90 80c35dc 0 > libumem.so.1`umem_cache_alloc_debug+0x14f > libumem.so.1`umem_cache_alloc+0x144 > libumem.so.1`umem_alloc+0xc5 > libumem.so.1`malloc+0x27 > libc.so.1`strdup+0x28 > libkrb5support.so.0.1`krb5int_get_error+0x190 > libkrb5.so.3.3`krb5_get_error_message+0x28 > get_policy_2_svc+0x1b4 > kadm_1+0x615 > libgssrpc.so.4.0`gssrpc_svc_getreqset+0x2a0 > kadm_svc_run+0xe5 > main+0xd27 > _start+0x80 > > It looks like there are a number of places calling > krb5_get_error_message() that are not freeing the returned error > string. Yup, I found (and fixed) a whole bunch of these when doing the 1.6.3 resync with our code. I'll turn it into a patch and file a bug. > > > = > = > = > = > = > = > = > ====================================================================== > > ADDR BUFADDR TIMESTAMP THREAD > CACHE LASTLOG CONTENTS > 818e718 818b640 8e2eb8f39eb39 1 > 8178390 80cbed8 0 > libumem.so.1`umem_cache_alloc_debug+0x14f > libumem.so.1`umem_cache_alloc+0x144 > libumem.so.1`umem_alloc+0xc5 > libumem.so.1`malloc+0x27 > libgssapi_krb5.so.2.2`gss_add_cred+0x23b > libgssapi_krb5.so.2.2`gss_acquire_cred+0x11e > libgssrpc.so.4.0`gssrpc__svcauth_gss+0x47f > libgssrpc.so.4.0`gssrpc__authenticate+0x8d > libgssrpc.so.4.0`gssrpc_svc_getreqset+0x132 > kadm_svc_run+0xe5 > main+0xd27 > _start+0x80 > > Not sure what the exact cause is as malloc() is called in several > places > in gss_add_cred(). I'm not sure if I saw this one. -Mark From elric at imrryr.org Thu Jun 26 14:48:14 2008 From: elric at imrryr.org (Roland Dowdeswell) Date: Thu, 26 Jun 2008 14:48:14 -0400 Subject: New proposal (Re: Ticket 5338: Race conditions in key rotation) In-Reply-To: Your message of "Thu, 26 Jun 2008 12:18:03 EDT." <0378AABF-1F4C-4ABE-AC8B-180573F53B88@MIT.EDU> Message-ID: <20080626184814.1AA6D3752F@arioch.imrryr.org> On 1214497083 seconds since the Beginning of the UNIX epoch Ken Raeburn wrote: > >On Jun 26, 2008, at 11:26, Roland Dowdeswell wrote: >>> KDC_ERR_SVC_UNAVAILABLE? >> >> If this is a standards change, let me suggest that errors be encoded >> in a way similar to SMTP with an explicit statement from the KDC >> about whether the error be permanent or transient. That way, future >> errors can be dealt with by legacy clients in a decent way. > >No, it's in RFC 4120, though not well defined there. I believe >Microsoft is already using it, and the current MIT client code should >treat it as an indication to try another KDC. (And of course I expect >the Microsoft client code does so as well.) Well, that does sound like a good response in the the case that the KDC actually knows that there exists a different KDC that can answer the request. -- Roland Dowdeswell http://www.Imrryr.ORG/~elric/ From deengert at anl.gov Fri Jun 27 11:21:25 2008 From: deengert at anl.gov (Douglas E. Engert) Date: Fri, 27 Jun 2008 10:21:25 -0500 Subject: pkinit and AD 2008 Message-ID: <48650575.6040209@anl.gov> I am trying to use krb5-pkinit krb5-1.6.dfsg.3~beta1-2ubuntu1 with a Windows AD 2008 server as the KDC. When using kinit it appears that all goes well and a AS-REP with pa-data-type (17) is returned by the KDC as reported by wireshark, but then kinit falls back to prompting for a password. No error messages are produced. I have tried building the pkinit.so with debugging turned on, but this does not show much either. The smart card being used works with XP and Vista client to AD 2008. The card has a subjectAltName that does not match the user or realm, but has something like <11 digit number>@FEDIDCARD.GOV for the UPN. Windows AD 2008 can handle this by changing the userPrincipalName in user account. So has anyone tested pkinit clients against AD 2008, with the SAN not matching the kerberos principal name? Is there any additional debugging to turn on for pkinit that could show why it fails after receiving the AS-REP? The enc-part of the AS-REP is encrypted in aes256-cts-hmac-sha1-96 (18) A snippet of the krb5.conf: [realms] ANL.GOV = { # first two for testbed kdc = test2.anl.gov:88 pkinit_kdc_hostname = TEST2.anl.gov pkinit_eku_checking = none # or kpKDC for RFC 4556 will try none for now # will assume the next 2 are not for 2008 # pkinit_win2k = yes pkinit_win2k_require_binding = false pkinit_cert_match = msScLogin pkinit_pool = DIR:/opt/smartcard/pool.certdir pkinit_anchors = DIR:/opt/smartcard/trusted.certdir } -- Douglas E. Engert Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444 From aglo at citi.umich.edu Fri Jun 27 12:05:41 2008 From: aglo at citi.umich.edu (Olga Kornievskaia) Date: Fri, 27 Jun 2008 12:05:41 -0400 Subject: pkinit and AD 2008 In-Reply-To: <48650575.6040209@anl.gov> References: <48650575.6040209@anl.gov> Message-ID: <48650FD5.7020501@citi.umich.edu> Can you post the debugging pkinit output that you do get? I think there are several possibilities for the failure: 1. AS_REP coming back from windows is somehow broken and pkinit is failing to decode it. We should be able to see such message if pkinit debugging is on. 2. If we have pasted decoding AS_REP, we can fail if we didn't find an acceptable SAN in KDC's certificate. I believe it is possible to turn off KDC's SAN checking. 3. dnsName in the KDC's certificate doesn't match the hostname specified in your krb5.conf. Since in you have pkinit_win2k =yes, you should have pkinit_kdc_hostname. I'm not sure if anybody ever tested pkinit with Windows AD. Who knows what kind of bugs were introduced in that version. Douglas E. Engert wrote: > I am trying to use krb5-pkinit krb5-1.6.dfsg.3~beta1-2ubuntu1 with > a Windows AD 2008 server as the KDC. When using kinit it appears that > all goes well and a AS-REP with pa-data-type (17) is returned by the > KDC as reported by wireshark, but then kinit falls back to prompting > for a password. No error messages are produced. > > I have tried building the pkinit.so with debugging turned on, but this > does not show much either. > > The smart card being used works with XP and Vista client to AD 2008. > The card has a subjectAltName that does not match the user or realm, > but has something like <11 digit number>@FEDIDCARD.GOV for the UPN. > > Windows AD 2008 can handle this by changing the userPrincipalName > in user account. > > So has anyone tested pkinit clients against AD 2008, with the SAN > not matching the kerberos principal name? > > Is there any additional debugging to turn on for pkinit that could > show why it fails after receiving the AS-REP? > > The enc-part of the AS-REP is encrypted in aes256-cts-hmac-sha1-96 (18) > > A snippet of the krb5.conf: > [realms] > ANL.GOV = { > # first two for testbed > kdc = test2.anl.gov:88 > pkinit_kdc_hostname = TEST2.anl.gov > pkinit_eku_checking = none > # or kpKDC for RFC 4556 will try none for now > # will assume the next 2 are not for 2008 > # pkinit_win2k = yes > pkinit_win2k_require_binding = false > pkinit_cert_match = msScLogin > pkinit_pool = DIR:/opt/smartcard/pool.certdir > pkinit_anchors = DIR:/opt/smartcard/trusted.certdir > } > > From aglo at citi.umich.edu Fri Jun 27 12:26:11 2008 From: aglo at citi.umich.edu (Olga Kornievskaia) Date: Fri, 27 Jun 2008 12:26:11 -0400 Subject: pkinit and AD 2008 In-Reply-To: <48650FD5.7020501@citi.umich.edu> References: <48650575.6040209@anl.gov> <48650FD5.7020501@citi.umich.edu> Message-ID: <486514A3.3040104@citi.umich.edu> Kevin just told me that Window AD 2008 is Longhorn and we did test against early releases of it. Longhorn had bugs so we had a work around "?pkinit_longhorn" config option that is off by default. Try setting pkinit_longhorn =1. Olga Kornievskaia wrote: > Can you post the debugging pkinit output that you do get? > > I think there are several possibilities for the failure: > 1. AS_REP coming back from windows is somehow broken and pkinit is > failing to decode it. We should be able to see such message if pkinit > debugging is on. > 2. If we have pasted decoding AS_REP, we can fail if we didn't find an > acceptable SAN in KDC's certificate. I believe it is possible to turn > off KDC's SAN checking. > 3. dnsName in the KDC's certificate doesn't match the hostname specified > in your krb5.conf. Since in you have pkinit_win2k =yes, you should have > pkinit_kdc_hostname. > > I'm not sure if anybody ever tested pkinit with Windows AD. Who knows > what kind of bugs were introduced in that version. > > > Douglas E. Engert wrote: > >> I am trying to use krb5-pkinit krb5-1.6.dfsg.3~beta1-2ubuntu1 with >> a Windows AD 2008 server as the KDC. When using kinit it appears that >> all goes well and a AS-REP with pa-data-type (17) is returned by the >> KDC as reported by wireshark, but then kinit falls back to prompting >> for a password. No error messages are produced. >> >> I have tried building the pkinit.so with debugging turned on, but this >> does not show much either. >> >> The smart card being used works with XP and Vista client to AD 2008. >> The card has a subjectAltName that does not match the user or realm, >> but has something like <11 digit number>@FEDIDCARD.GOV for the UPN. >> >> Windows AD 2008 can handle this by changing the userPrincipalName >> in user account. >> >> So has anyone tested pkinit clients against AD 2008, with the SAN >> not matching the kerberos principal name? >> >> Is there any additional debugging to turn on for pkinit that could >> show why it fails after receiving the AS-REP? >> >> The enc-part of the AS-REP is encrypted in aes256-cts-hmac-sha1-96 (18) >> >> A snippet of the krb5.conf: >> [realms] >> ANL.GOV = { >> # first two for testbed >> kdc = test2.anl.gov:88 >> pkinit_kdc_hostname = TEST2.anl.gov >> pkinit_eku_checking = none >> # or kpKDC for RFC 4556 will try none for now >> # will assume the next 2 are not for 2008 >> # pkinit_win2k = yes >> pkinit_win2k_require_binding = false >> pkinit_cert_match = msScLogin >> pkinit_pool = DIR:/opt/smartcard/pool.certdir >> pkinit_anchors = DIR:/opt/smartcard/trusted.certdir >> } >> >> >> > _______________________________________________ > krbdev mailing list krbdev at mit.edu > https://mailman.mit.edu/mailman/listinfo/krbdev > > From William.Fiveash at sun.com Fri Jun 27 16:30:31 2008 From: William.Fiveash at sun.com (Will Fiveash) Date: Fri, 27 Jun 2008 15:30:31 -0500 Subject: question related to mkey keytab stash project Message-ID: <20080627203031.GA13976@sun.com> While the current code under review appears to work and all MIT tests pass, I do have a question as to the new behavior of the krb5_db_fetch_mkey() function. The new krb5_db_fetch_mkey() will return the first key it finds in the keytab stash and can optionally search based on either kvno, enctype or both. My question is; if a kvno is not specified when calling krb5_db_fetch_mkey() as is the case when krb5kdc calls it, should the function try to get the masterkey princ entry and use the kvno in the entry to search the keytab or should that be the responsibility of the caller which would then include that kvno when calling krb5_db_fetch_mkey()? -- Will Fiveash Sun Microsystems Inc. http://opensolaris.org/os/project/kerberos/ From kulg123 at gmail.com Sun Jun 29 07:01:17 2008 From: kulg123 at gmail.com (kul gupta) Date: Sun, 29 Jun 2008 16:31:17 +0530 Subject: mod_auth_kerb+ apacahe+kerberos Message-ID: <2203f95e0806290401u7ce56bd7j3cd1532c811de8c2@mail.gmail.com> Hello I want to use the module "auth_mod_kerb" for the web authentication . Currently i m trying on RedHat enterprise linix 5.0 I have Openssl 0.9.8 g installed on it But when i m trying to install "apachae with ssl " ,i m getting some error. Without ssl apache is getting installed properly Is it necessary to have "apache with ssl " for working with "auth_mod_kerb" ?? If yes ,how can i proceed for the same I will highly appreciate if someone can help me on this issue. Thanks Regards KUL From hotz at jpl.nasa.gov Mon Jun 30 01:23:24 2008 From: hotz at jpl.nasa.gov (Henry B. Hotz) Date: Sun, 29 Jun 2008 22:23:24 -0700 Subject: mod_auth_kerb+ apacahe+kerberos In-Reply-To: References: Message-ID: <364127E5-51FE-4E0F-A7B5-B3470DD7E266@jpl.nasa.gov> On Jun 29, 2008, at 9:15 AM, krbdev-request at mit.edu wrote: > Message: 1 > Date: Sun, 29 Jun 2008 16:31:17 +0530 > From: "kul gupta" > Subject: mod_auth_kerb+ apacahe+kerberos > To: kerberos at mit.edu, krbdev at mit.edu, "Russ Allbery" > , "Tadoori (EXT), Vilas" > , "Jeffrey Hutzelman" > Message-ID: > <2203f95e0806290401u7ce56bd7j3cd1532c811de8c2 at mail.gmail.com> > Content-Type: text/plain; charset=ISO-8859-1 > > Hello > > I want to use the module "auth_mod_kerb" for the web authentication . > Currently i m trying on RedHat enterprise linix 5.0 > > I have Openssl 0.9.8 g installed on it > But when i m trying to install "apachae with ssl " ,i m getting some > error. > Without ssl apache is getting installed properly > > Is it necessary to have "apache with ssl " for working with > "auth_mod_kerb" ?? > If yes ,how can i proceed for the same > > I will highly appreciate if someone can help me on this issue. > > > Thanks > Regards > KUL Not in the sense of just making the software work. It's a very good idea though. I'd say get ssl working first in a build with mod_so (dynamically loadable modules). Then add mod_auth_kerb afterwards. ------------------------------------------------------ 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 kulg123 at gmail.com Mon Jun 30 08:35:56 2008 From: kulg123 at gmail.com (kul gupta) Date: Mon, 30 Jun 2008 18:05:56 +0530 Subject: mod_auth_kerb+ apacahe+mod_SSL Message-ID: <2203f95e0806300535u7636c4f1n394001f4debbbf44@mail.gmail.com> Hello I want to use the module "auth_mod_kerb" for the web authentication . Currently i m trying on RedHat enterprise linix 5.0 I have Openssl 0.9.8 g installed on it But when i m trying to install "apachae with ssl " (apache 2.2.8 ),i m getting some error. Without ssl apache is getting installed properly i did ./configure --enable-ssl --enable-mods-shared=all then make Now i m getting following errors /ab.c:382:undefined reference to`BIO_get_callback_arg' /ab.c:1144: undefined reference to`BIO_set_callback' /ab.c:1144: undefined reference to`BIO_set_callback' /ab.c:1145: undefined reference to`BIO_set_callback_arg' .libs/ab.o: In function `main': ab.c:2154: undefined reference to`SSL_CTX_set_info_callback' Please help me out in resloving this issue Thanks kul On 6/30/08, Henry B. Hotz wrote: > > > On Jun 29, 2008, at 9:15 AM, krbdev-request at mit.edu wrote: > > Message: 1 >> Date: Sun, 29 Jun 2008 16:31:17 +0530 >> From: "kul gupta" >> Subject: mod_auth_kerb+ apacahe+kerberos >> To: kerberos at mit.edu, krbdev at mit.edu, "Russ Allbery" >> , "Tadoori (EXT), Vilas" >> , "Jeffrey Hutzelman" < >> jhutz at cmu.edu> >> Message-ID: >> <2203f95e0806290401u7ce56bd7j3cd1532c811de8c2 at mail.gmail.com> >> Content-Type: text/plain; charset=ISO-8859-1 >> >> Hello >> >> I want to use the module "auth_mod_kerb" for the web authentication . >> Currently i m trying on RedHat enterprise linix 5.0 >> >> I have Openssl 0.9.8 g installed on it >> But when i m trying to install "apachae with ssl " ,i m getting some >> error. >> Without ssl apache is getting installed properly >> >> Is it necessary to have "apache with ssl " for working with >> "auth_mod_kerb" ?? >> If yes ,how can i proceed for the same >> >> I will highly appreciate if someone can help me on this issue. >> >> >> Thanks >> Regards >> KUL >> > > Not in the sense of just making the software work. It's a very good idea > though. > > I'd say get ssl working first in a build with mod_so (dynamically loadable > modules). Then add mod_auth_kerb afterwards. > > ------------------------------------------------------ > 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 kulg123 at gmail.com Mon Jun 30 08:45:38 2008 From: kulg123 at gmail.com (kul gupta) Date: Mon, 30 Jun 2008 18:15:38 +0530 Subject: mod_auth_kerb+ apacahe+mod_SSL In-Reply-To: <2203f95e0806300535u7636c4f1n394001f4debbbf44@mail.gmail.com> References: <2203f95e0806300535u7636c4f1n394001f4debbbf44@mail.gmail.com> Message-ID: <2203f95e0806300545t6af3eeelb6cfb66aecdeec28@mail.gmail.com> On 6/30/08, kul gupta wrote: > > Hello > > I want to use the module "mod_auth_kerb" for the web authentication . > Currently i m trying on RedHat enterprise linix 5.0 > > I have Openssl 0.9.8 g installed on it > But when i m trying to install "apachae with ssl " (apache 2.2.8 ),i m > getting some error. > Without ssl apache is getting installed properly > > > i did > ./configure --enable-ssl --enable-mods-shared=all > > then > > make > > Now i m getting following errors > /ab.c:382:undefined reference to`BIO_get_callback_arg' > /ab.c:1144: undefined reference to`BIO_set_callback' > /ab.c:1144: undefined reference to`BIO_set_callback' > /ab.c:1145: undefined reference to`BIO_set_callback_arg' > .libs/ab.o: In function `main': > ab.c:2154: undefined reference to`SSL_CTX_set_info_callback' > > Please help me out in resloving this issue > Thanks > kul > > > > > > > > > On 6/30/08, Henry B. Hotz wrote: >> >> >> On Jun 29, 2008, at 9:15 AM, krbdev-request at mit.edu wrote: >> >> Message: 1 >>> Date: Sun, 29 Jun 2008 16:31:17 +0530 >>> From: "kul gupta" >>> Subject: mod_auth_kerb+ apacahe+kerberos >>> To: kerberos at mit.edu, krbdev at mit.edu, "Russ Allbery" >>> , "Tadoori (EXT), Vilas" >>> , "Jeffrey Hutzelman" < >>> jhutz at cmu.edu> >>> Message-ID: >>> <2203f95e0806290401u7ce56bd7j3cd1532c811de8c2 at mail.gmail.com> >>> Content-Type: text/plain; charset=ISO-8859-1 >>> >>> Hello >>> >>> I want to use the module "auth_mod_kerb" for the web authentication . >>> Currently i m trying on RedHat enterprise linix 5.0 >>> >>> I have Openssl 0.9.8 g installed on it >>> But when i m trying to install "apachae with ssl " ,i m getting some >>> error. >>> Without ssl apache is getting installed properly >>> >>> Is it necessary to have "apache with ssl " for working with >>> "auth_mod_kerb" ?? >>> If yes ,how can i proceed for the same >>> >>> I will highly appreciate if someone can help me on this issue. >>> >>> >>> Thanks >>> Regards >>> KUL >>> >> >> Not in the sense of just making the software work. It's a very good idea >> though. >> >> I'd say get ssl working first in a build with mod_so (dynamically loadable >> modules). Then add mod_auth_kerb afterwards. >> >> ------------------------------------------------------ >> 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 msimovic at concurrent-thinking.com Sun Jun 29 07:20:55 2008 From: msimovic at concurrent-thinking.com (Martin Simovic) Date: Sun, 29 Jun 2008 12:20:55 +0100 Subject: mod_auth_kerb+ apacahe+kerberos In-Reply-To: <2203f95e0806290401u7ce56bd7j3cd1532c811de8c2@mail.gmail.com> References: <2203f95e0806290401u7ce56bd7j3cd1532c811de8c2@mail.gmail.com> Message-ID: <1214738455.8726.18.camel@precision.lan.streamline-computing.com> On Sun, 2008-06-29 at 16:31 +0530, kul gupta wrote: > Hello > > I want to use the module "auth_mod_kerb" for the web authentication . > Currently i m trying on RedHat enterprise linix 5.0 > > I have Openssl 0.9.8 g installed on it > But when i m trying to install "apachae with ssl " ,i m getting some error. > Without ssl apache is getting installed properly > > Is it necessary to have "apache with ssl " for working with > "auth_mod_kerb" ?? > If yes ,how can i proceed for the same > > I will highly appreciate if someone can help me on this issue. > > > Thanks > Regards > KUL > ________________________________________________ > Kerberos mailing list Kerberos at mit.edu > https://mailman.mit.edu/mailman/listinfo/kerberos Hi, 'some error' does not actually help us to solve your problem. this is redhat specific and has nothing to do with kerberos or auth. whatsoever at this stage. look at the redhat docs (which used to be very good - last one i used was 'shrike' :) ) for the troubleshooting of apache SSL installation. to answer your question: for apache auth_mod_krb SSL is recomended, however not necessary. the fact is, it would work without it, but it's definitely something you do not want to do. without SSL your kerberos passwords will fly to the web server in cleartext (yes) and therefore totally compromise your kerberos infrastructure (all your kerberized services use the same useraname/password yes?) apart from that, if your goal is to implement SSO solution (so that your users will use kerberos TGT rather than password -but you never know what will user do ;) ) the firefox (and IE) plugin is configured to authenticate only to kerberos enabled websites over SSL - you would have to override this in about:config setting for each of your URL's in firefox (no idea for IE). summary: you want SSL there is a nice docs here (recommend reading through) http://modauthkerb.sourceforge.net/index.html Martin. From jhutz at cmu.edu Mon Jun 30 14:54:22 2008 From: jhutz at cmu.edu (Jeffrey Hutzelman) Date: Mon, 30 Jun 2008 14:54:22 -0400 Subject: pkinit and AD 2008 In-Reply-To: <200806271606.m5RG6B3K019363@grapenut.srv.cs.cmu.edu> References: <48650575.6040209@anl.gov> <200806271606.m5RG6B3K019363@grapenut.srv.cs.cmu.edu> Message-ID: <853CB33D7EACF89ACD819503@sirius.fac.cs.cmu.edu> --On Friday, June 27, 2008 12:05:41 PM -0400 Olga Kornievskaia wrote: > 3. dnsName in the KDC's certificate doesn't match the hostname specified > in your krb5.conf Um. Why would you expect that? PKINIT contains no requirement that the KDC's certificate contain a dnsName, nor that it match any particular hostname if it is present. The only requirement is for an id-pkinit-san matching the name of the realm's TGS. -- Jeff From aglo at citi.umich.edu Mon Jun 30 15:11:02 2008 From: aglo at citi.umich.edu (Olga Kornievskaia) Date: Mon, 30 Jun 2008 15:11:02 -0400 Subject: pkinit and AD 2008 In-Reply-To: <853CB33D7EACF89ACD819503@sirius.fac.cs.cmu.edu> References: <48650575.6040209@anl.gov> <200806271606.m5RG6B3K019363@grapenut.srv.cs.cmu.edu> <853CB33D7EACF89ACD819503@sirius.fac.cs.cmu.edu> Message-ID: <48692FC6.6080301@citi.umich.edu> Jeffrey Hutzelman wrote: > --On Friday, June 27, 2008 12:05:41 PM -0400 Olga Kornievskaia > wrote: > >> 3. dnsName in the KDC's certificate doesn't match the hostname specified >> in your krb5.conf > > Um. Why would you expect that? PKINIT contains no requirement that > the KDC's certificate contain a dnsName, nor that it match any > particular hostname if it is present. The only requirement is for an > id-pkinit-san matching the name of the realm's TGS. In RFC 4556 in *Appendix C. Miscellaneous Information about Microsoft Windows PKINIT* KDC certificates issued by Windows 2003 Enterprise CAs contain a dNSName SAN with the DNS name of the host running the KDC. From hotz at jpl.nasa.gov Mon Jun 30 18:01:26 2008 From: hotz at jpl.nasa.gov (Henry B. Hotz) Date: Mon, 30 Jun 2008 15:01:26 -0700 Subject: mod_auth_kerb+ apacahe+kerberos In-Reply-To: References: Message-ID: <1E182F67-C9C4-4041-AF87-96BDCD576C73@jpl.nasa.gov> On Jun 30, 2008, at 9:07 AM, krbdev-request at mit.edu wrote: > to answer your question: for apache auth_mod_krb SSL is recomended, > however not necessary. the fact is, it would work without it, but it's > definitely something you do not want to do. without SSL your kerberos > passwords will fly to the web server in cleartext (yes) and therefore > totally compromise your kerberos infrastructure (all your kerberized > services use the same useraname/password yes?) No, it's not remotely that bad. In fact your passwords don't go over that link (or any other) at all with Kerberos. It's just Kerberos tickets with short (~1 day at most) lifetimes. The main issue is that the ticket could be sniffed and re- used to let someone else access the same web server. There are a number of other issues as well: server-side replay cacheing, ticket forwarding, ticket lifetimes. Your original password is not a problem unless the server falls-back to basic-auth over a non- SSL connection. If that happens, it's bad, but it's got nothing to do with Kerberos. From hotz at jpl.nasa.gov Mon Jun 30 18:06:56 2008 From: hotz at jpl.nasa.gov (Henry B. Hotz) Date: Mon, 30 Jun 2008 15:06:56 -0700 Subject: mod_auth_kerb+ apacahe+mod_SSL In-Reply-To: <2203f95e0806300545t6af3eeelb6cfb66aecdeec28@mail.gmail.com> References: <2203f95e0806300535u7636c4f1n394001f4debbbf44@mail.gmail.com> <2203f95e0806300545t6af3eeelb6cfb66aecdeec28@mail.gmail.com> Message-ID: Questions relating to Apache and SSL have nothing to do with Kerberos. I think you would get much better help from a RedHat or Apache list. Once you get Apache+SSL working, I suggest you ask on modauthkerb-help at lists.sourceforge.net about any mod_auth_kerb issues. Is there a reason you're not using the Apache+SSL+mod_auth_kerb that already are provided by RedHat? This is still probably not your best forum, but I don't want to cut you off too short. On Jun 30, 2008, at 5:45 AM, kul gupta wrote: > On 6/30/08, kul gupta wrote: > Hello > > I want to use the module "mod_auth_kerb" for the web authentication . > Currently i m trying on RedHat enterprise linix 5.0 > > I have Openssl 0.9.8 g installed on it > But when i m trying to install "apachae with ssl " (apache 2.2.8 ),i > m getting some error. > Without ssl apache is getting installed properly > > i did > ./configure --enable-ssl --enable-mods-shared=all > > then > > make > > Now i m getting following errors > /ab.c:382:undefined reference to`BIO_get_callback_arg' > /ab.c:1144: undefined reference to`BIO_set_callback' > /ab.c:1144: undefined reference to`BIO_set_callback' > /ab.c:1145: undefined reference to`BIO_set_callback_arg' > .libs/ab.o: In function `main': > ab.c:2154: undefined reference to`SSL_CTX_set_info_callback' > > Please help me out in resloving this issue > Thanks > kul > > > > > > > > > On 6/30/08, Henry B. Hotz wrote: > On Jun 29, 2008, at 9:15 AM, krbdev-request at mit.edu wrote: > > Message: 1 > Date: Sun, 29 Jun 2008 16:31:17 +0530 > From: "kul gupta" > Subject: mod_auth_kerb+ apacahe+kerberos > To: kerberos at mit.edu, krbdev at mit.edu, "Russ Allbery" > , "Tadoori (EXT), Vilas" > , "Jeffrey Hutzelman" > > Message-ID: > <2203f95e0806290401u7ce56bd7j3cd1532c811de8c2 at mail.gmail.com> > Content-Type: text/plain; charset=ISO-8859-1 > > Hello > > I want to use the module "auth_mod_kerb" for the web authentication . > Currently i m trying on RedHat enterprise linix 5.0 > > I have Openssl 0.9.8 g installed on it > But when i m trying to install "apachae with ssl " ,i m getting some > error. > Without ssl apache is getting installed properly > > Is it necessary to have "apache with ssl " for working with > "auth_mod_kerb" ?? > If yes ,how can i proceed for the same > > I will highly appreciate if someone can help me on this issue. > > > Thanks > Regards > KUL > > Not in the sense of just making the software work. It's a very good > idea though. > > I'd say get ssl working first in a build with mod_so (dynamically > loadable modules). Then add mod_auth_kerb afterwards. > > ------------------------------------------------------ > 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 rra at stanford.edu Mon Jun 30 18:15:47 2008 From: rra at stanford.edu (Russ Allbery) Date: Mon, 30 Jun 2008 15:15:47 -0700 Subject: mod_auth_kerb+ apacahe+kerberos In-Reply-To: <1E182F67-C9C4-4041-AF87-96BDCD576C73@jpl.nasa.gov> (Henry B. Hotz's message of "Mon\, 30 Jun 2008 15\:01\:26 -0700") References: <1E182F67-C9C4-4041-AF87-96BDCD576C73@jpl.nasa.gov> Message-ID: <87iqvqefho.fsf@windlord.stanford.edu> "Henry B. Hotz" writes: > On Jun 30, 2008, at 9:07 AM, krbdev-request at mit.edu wrote: >> to answer your question: for apache auth_mod_krb SSL is recomended, >> however not necessary. the fact is, it would work without it, but it's >> definitely something you do not want to do. without SSL your kerberos >> passwords will fly to the web server in cleartext (yes) and therefore >> totally compromise your kerberos infrastructure (all your kerberized >> services use the same useraname/password yes?) > No, it's not remotely that bad. > In fact your passwords don't go over that link (or any other) at all > with Kerberos. It's just Kerberos tickets with short (~1 day at most) > lifetimes. The main issue is that the ticket could be sniffed and re- > used to let someone else access the same web server. This is only true if you enable negotiate-auth. The default in mod_auth_kerb is to do basic auth and verify the password on the server, which does have the behavior described by the previous poster. -- Russ Allbery (rra at stanford.edu) From mohamed.chaari at orange-ftgroup.com Mon Jun 30 10:43:10 2008 From: mohamed.chaari at orange-ftgroup.com (mohamed.chaari@orange-ftgroup.com) Date: Mon, 30 Jun 2008 16:43:10 +0200 Subject: ASN.1 Message-ID: Hello, I would like to know if I can modify the ASN.1 files of kerberos. Thanks.