Re: Impersonate Kerberos user on HDFS
Ken Hornstein via Kerberos writes: > - Have access to to user's key/password and generate a ticket for that > user using kinit. As someone else already noted, this isn't really > impersonating a user. > - Have access to the TGS key and generate a TGT for that user (or any user). > This is generally referred to as "ticket printing". I don't _think_ > the Kerberos distributions come with a utility to do that, but I > believe there are example programs floating around that do that. I > have to say that doing so would require access to the TGS key and > having that outside of your Kerberos database would be extremely > dangerous as if it was compromised your entire realm would be > compromised. I have in the past written a variation on these two approaches as a service that runs directly on the KDC. It accepted authenticated requests, applied some sort of complex ACL, and, if the authenticated user making the request passed that ACL, returned a printed ticket (and of course logged that this was happening). Since it ran on the KDC, it already had access to the keys required to do so. I convinced myself that this was acceptably secure. (The actual project was for a former employer and I don't have the source, and there were some other weird things about that environment that meant I was able to maintain separate keytabs for each user without worrying about them being invalidated, so I didn't do the full ticket printing approach based on the TGS key and just used a bunch of user keytabs since that was a lot easier to set up without having to work too hard.) The huge drawback of all variations on this type of approach is that you lose the ability to distinguish between user accesses based on their own authentication and third-party accesses via ticket printing. That can be a real problem if anything goes wrong and you need to figure out whether it was really the user or some ticket-printing service, and can be hard to explain (for good reason) in various audit situations. So probably best avoided if you can find a different approach. -- Russ Allbery (ea...@eyrie.org) <https://www.eyrie.org/~eagle/> Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
krb5-strength 3.3 released
I'm pleased to announce release 3.3 of krb5-strength. krb5-strength provides a password quality plugin for the MIT Kerberos KDC (specifically the kadmind server) and Heimdal KDC, an external password quality program for use with Heimdal, and a per-principal password history implementation for Heimdal. Passwords can be tested with CrackLib, checked against a CDB or SQLite database of known weak passwords with some transformations, checked for length, checked for non-printable or non-ASCII characters that may be difficult to enter reproducibly, required to contain particular character classes, or any combination of these tests. Changes from previous release: heimdal-history now requires the Perl modules Const::Fast and JSON::MaybeXS instead of Readonly and JSON. Increase hash iterations for heimdal-history by about 10% to maintain the time required for a password hash at about 0.1 seconds on not horribly modern hardware. This will affect newly-stored history entries but will not invalidate existing password history entries. Explicitly erase the copy of the password made in the Heimdal plugin before freeing memory. Add a spec file for building RPMs, contributed by Daria Phoebe Brashear. Update to rra-c-util 10.5: * Assume a working snprintf rather than supplying a replacement. * Fix detection of reallocarray on NetBSD. * Check that Kerberos header files were found during configure. * Use AS_ECHO in all Autoconf macros. * Always use lib32 or lib64 if it exists, even on Debian. * Fix rejection of unknown Clang warning flags. * Disable -Wreserved-identifier for Clang warning builds. You can download it from: <https://www.eyrie.org/~eagle/software/krb5-strength/> This package is maintained using Git; see the instructions on the above page to access the Git repository. Debian packages have been uploaded to Debian unstable. Please let me know of any problems or feature requests not already listed in the TODO file. -- Russ Allbery (ea...@eyrie.org) <https://www.eyrie.org/~eagle/> Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: About the purpose of client host principals for NFS
Marco Rebhan via Kerberos writes: > What purpose does the host principal for clients serve here? I assumed > it would be either used to authenticate hosts before they're allowed to > obtain a TGT, or authenticate for mounting NFS shares, but clearly > that's not the case since it works without. Is it only used so that the > network share can be mounted without a user TGT? Yup, pretty much. There is indeed no need to key clients if you're going to obtain credentials after login with something like kinit and you don't care about more sophisticated Kerberos network protection features like FAST. The other reason to key a client is so that it can verify that the password that you enter is indeed a valid Kerberos credential so that you can use Kerberos to control access to the system itself. If the system doesn't have any keys (and you don't have something like anonymous PKINIT available), then the client computer can't tell the difference between getting Kerberos credentials from a real KDC or from a fake KDC that someone put on the same network. This only matters in cases where someone might be trying to log on to the client system with fake Kerberos credentials, and doesn't really matter if you're logging on to the system with local credentials and then getting Kerberos credentials later. (This is mostly relevant for work computers that use central Kerberos to authenticate all access, computer labs that have multiple users, and similar sorts of cases.) -- Russ Allbery (ea...@eyrie.org) <https://www.eyrie.org/~eagle/> Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: How to view KVNO on slave
Mike via Kerberos writes: > I'm surmising that the issue might be that the service principle may not > have replicated corerctly to the slave server, which is used by the > Apache host. I can see the ticket details on the master using > kadmin.local and getprinc and I can see the keytab info using ktutil. > My question is this: How does one view the KVNO in the Slave DB? I > imaine it's probably available via kdb5_util dump but unfortunatly I > have not found any documents explaining the fields in the dump. You can use kadmin.local on the slave the same way that you use it on the master, I'm fairly sure. It's been a while since I've done this, but I'm pretty sure the database is the same and the tool doesn't have any idea whether you're running it on a master or a slave. I would expect you to get replication errors if there was a replication problem. If you're only doing incremental replication and you think something may have gone wrong, you can always do a full replication, which guarantees that the slave is identical to the master. -- Russ Allbery (ea...@eyrie.org) <https://www.eyrie.org/~eagle/> Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: authenticate user via ldap bind
"John Alex. via Kerberos" writes: > In this instance, user passwords are stored in our LDAP server > (OpenLDAP), hashed. All our services currently validate user credentials > by attempting an LDAP bind either directly or via another protocol > implementation (Shibboleth IdP, FreeRADIUS, Keycloak etc). > So my question is, is there a way to implement kerberos without > knowledge of the plaintext passwords, or do we have to somehow capture > the credentials during users' login to other services and then sync them > to the kdc db? Unfortunately, although Kerberos also stores all of the passwords hashed, the hashing algorithm used by Kerberos is almost certainly different than the hashing algorithm used by LDAP. You therefore need the cleartext password in order to create the KDC entry, since the point of hashing is that it's not reversible. The only exception would be if somehow Kerberos could be convinced to use the same hashing algorithm as LDAP, but I don't think that's the case. (The client and the KDC have to agree on a hashing algorithm, so this isn't a simple thing to do.) -- Russ Allbery (ea...@eyrie.org) <https://www.eyrie.org/~eagle/> Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: help with OTP
Charles Hedrick writes: > Anonymous PKINIT works fine but requires certs to be distributed. Unless > you're prepared to update every machine in the world every year, you > pretty much have to use a cert that goes back to a commercial CA. Because you have to distribute the certs to the client anyway, you can use self-signed certificates and set whatever expiration you want. There's the standard tradeoff of long certificate lifetime, but so far as I know there's no reason why you can't set your KDC public key certificate lifetime to 50 years or whatever. I agree with your other points, though. -- Russ Allbery (ea...@eyrie.org) <https://www.eyrie.org/~eagle/> Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: help with OTP
Ken Hornstein via Kerberos writes: > Well, dang, that's one for the toolbox! I was able to confirm that > works just fine (but note I already had an existing PKINIT > infrastructure to leverage). I will note that the existing > documentation implies you could authenticate to WELLKNOWN/ANONYMOUS > using your password, but maybe that isn't true? I'm specifically > referring to the documentation for the '-n' option for kinit, the > "second form" of anonymous tickets. There is a note that this isn't > supported, but it mentions MIT Kerberos 1.8 so one could believe that > note is out of date. > This is kind of the giant mystery surrounding FAST. If you're not > familiar with the gory details of the FAST protocol you're kind of left > stumbling around to figure out what exactly you need to do. I realize > this is probably because it's hard to write documentation for beginners > (certainly I am guilty of this also); I'm only making this as a general > observation. I worked through a bunch of this for pam-krb5 back in the day and made it support a set of reasonable things, including anonymous PKINIT to establish the FAST armor. People who are working in this area may find its source code useful to look at, although I think there have been improvements since then and what it does may no longer be best practice. https://github.com/rra/pam-krb5/blob/main/module/fast.c -- Russ Allbery (ea...@eyrie.org) <https://www.eyrie.org/~eagle/> Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: appl/simple/client/sim_client.c uses internal APIs
Simo Sorce writes: > On Fri, 2023-02-24 at 16:27 -0800, Russ Allbery wrote: >> Essentially everything that I don't like about GSSAPI is a direct >> consequence of the fact that it's a generic authentication protocol >> that in theory (although essentially never in practice outside of toys >> and science experiments) could negotiate a mechanism other than >> Kerberos. Supporting that generality forces the addition of >> irreducible complexity to the API. > Sorry Russ, > I do not know about toys or science experiments, but I have been using > GSSAPI in real HTTP applications to do either NTLM or Krb5 just fine. > And before that in SMB applications (although Samba is more complicated > because of its history). Argh, sorry, I got this backwards, and I think this is the same mistake that I have made before. For some reason it is stuck in my head that SPNEGO is used to negotiate GSSAPI when it's the other way around: SPNEGO is a GSSAPI mechanism. Thank you all for the interesting feedback on this thread. I think my original statement had a few things wrong, and I appreciate all the corrections. My basic point is that I understand the need to first negotiate a security mechanism and then use that security mechanism, but I don't like the layering of multiple negotiation mechanisms, so I'm not a big fan of SASL and GSSAPI/SPNEGO being separate and HTTP using yet another negotiation protocol via WWW-Authenticate headers, although I understand why this happened. Ideally, I'd like to have three concepts: a negotiation protocol, a security protocol for Kerberos, and an encoding layer for both of those protocols into the application protocol (HTTP, IMAP, whatever) that deals with problems like how to put this into valid HTTP requests. I feel like we've collectively taken multiple shots at this over the years and we keep getting closer, but we keep ending up with the divisions between the layers being murky and having multiple negotiation layers, and that in turn makes the code more complicated. And this is probably a pipe dream at this point, since all this stuff is very baked into long-standing protocols that are unlikely to change significantly. More actionably, for a lot of applications I think there's some merit in dispensing with the negitiation layer and having one single supported security mechanism and that's it. This was the idea behind Wireguard, and I think it's an interesting model. This isn't suitable for IMAP or HTTP or whatnot for obvious reasons, but it adds a lot of simplicity when one knows what security mechanism is in play because the (often private) protocol only supports a single one and can just use it directly. And this is what becomes impossible when GSSAPI is the only recommended way of using Kerberos, because then you can't get rid of the generic layer of the API even if you don't need it, so you're stuck with having multiple identity concepts, etc. (I do understand all of the other problems with the raw Kerberos API, though, and I'm not saying it should be used instead. The API that I actually want doesn't exist, I think.) -- Russ Allbery (ea...@eyrie.org) <https://www.eyrie.org/~eagle/> Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: appl/simple/client/sim_client.c uses internal APIs
Nico Williams writes: > Which is why, for a new mechanism, I would much prefer that it support > Kerberos naming. Certainly I don't ever want to see a mechanism use > x.500 style naming again. Primarily what I'd want in a new mechanism is for it to be a protocol for Kerberos authentication. (Or some other underlying authentication system that we all use instead, although that would be off-topic for this group.) In other words, not generic. I understand why GSSAPI was made generic, but that's not what I want, and I think the security world is starting to realize that being able to negotiate every security property and mechanism is more of a bug than a feature. Right now, it is possible to get into the truly absurd situation where to authenticate a client to a server you use: * HTTP authentication, to negotiate * SPNEGO, to negotiate * GSASPI, to negotiate * Kerberos, to do the actual authentication Something similar happens with SASL. This is three layers of negotiation too many. Even if you can hide or eliminate all of the round trips, you're introducing a lot of conceptual complexity, and while the developer doesn't need to know about any of it if all goes well, all often doesn't go well in the real world and then you have to figure out at what layer everything broke. I understand the need for *a* negotiation layer. I think the error was in accepting additional negotiation layers below that, as opposed to getting out of the generic mode as quickly as possible and start working directly with the true protocol. Essentially everything that I don't like about GSSAPI is a direct consequence of the fact that it's a generic authentication protocol that in theory (although essentially never in practice outside of toys and science experiments) could negotiate a mechanism other than Kerberos. Supporting that generality forces the addition of irreducible complexity to the API. (There is the other problem that all of the effort, hardware support, and optimization work is going into TLS now, and it feels like a huge waste of energy to try to compete with TLS in the secure transport business. But that's a whole different can of worms since TLS is very wedded to X.509 certificates and there are a bunch of very good reasons to not want to use X.509 certificates for client authentication in a lot of situations.) -- Russ Allbery (ea...@eyrie.org) <https://www.eyrie.org/~eagle/> Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: appl/simple/client/sim_client.c uses internal APIs
Nico Williams writes: > RFC 7546 exists. Yes, I am well aware that this exists. If you can read this and come away thinking that the API that it describes is simpler than the krb5 API, I really don't know what to say. Perhaps GSSAPI reflects the way that you think more closely, so it seems simpler to you. I use GSSAPI for new code because it is a *better* API (or, more precisely, a better *protocol*) that fixes various underlying issues and has better defaults. But it is not *simpler*; quite the opposite, it's more tedious and annoying and weird, harder to debug because of the imposition of the generic layer that has a tendency to get in the way of understanding what's going on, and requires you think about both Kerberos and GSS concepts at the same time when implementing a non-trivial application instead of focusing only on Kerberos. Just to take another example, GSSAPI introduces yet another identity format and now you have to be aware of both the Kerberos identity and the GSS identity, which are sort of the same but not always. > I've written a fair amount of app code using krb5 and GSS APIs, and I > strongly prefer GSS code. Well, I have written some of that code myself, and I don't agree. > It does pay a price, but if all you need is encrypted sessions, then > it's simple. I think we have very different definitions of simple. -- Russ Allbery (ea...@eyrie.org) <https://www.eyrie.org/~eagle/> Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: appl/simple/client/sim_client.c uses internal APIs
Nico Williams writes: > If you're just trying to set up a GSS context between a client and a > server, then GSS is really simple, and much simpler than the krb5 API. I'm very dubious about this statement. The requirement to handle negotiation and potential multiple round trips and all the complexity with major and minor status codes makes the equivalent GSS code complicated and annoying. GSS pays a significant price for being a generic mechanism with a negotiation method, and the API does not hide that price from the programmer. -- Russ Allbery (ea...@eyrie.org) <https://www.eyrie.org/~eagle/> Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: Kerberos protocol transition with unconstrained delegation (i.e. TGT impersonation)
Jonathan Calmels writes: > Thank you for the suggestions, I didn't know about kimpersonate and this > would indeed solve part of the problem. The reason why I mentioned > libkadm5 is because we were thinking of relying on > "kadm5_get_principal_keys" instead of keytabs. This way we could also > reuse the kadm ACLs and have a rule like "gsshostservice@REALM e > */ci@REALM". You can certainly do that, but just be aware that there's not much in the way of a security difference between that and keytabs. In theory it means the GSS service doesn't have access to all the user's keys at once but has to ask for them on demand, but if I were you I'd just colocate the GSS service with the KDC since the security model is essentially the same, at which point the KDC database is right there and there's really no particularly meaningful distinction. (I have implemented something akin to this before, and that's how I did it.) > Forging a cross-realm TGT would definitely be preferable, although I'm > not sure if it's doable with libkrb5. It should be doable, but you may have to use really low-level functions to duplicate what kimpersonate is doing. -- Russ Allbery (ea...@eyrie.org) <https://www.eyrie.org/~eagle/> Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: Kerberos protocol transition with unconstrained delegation (i.e. TGT impersonation)
Jonathan Calmels via Kerberos writes: > So far, the only hack we can think of is replicating the AD users into > the MIT KDC and writing some kind of GSS service that would issue TGTs > for those (given the proper service ticket). Something like: > 1. The scheduler does protocol transition with the AD UPN it got from > the CI/CD > 2. The scheduler contacts this GSS service with the resulting service > ticket > 3. The GSS service converts the UPN from the AD realm to its MIT > realm counterpart > 4. If everything checks out, it sends back a TGT for the user (this > might involve some unconventional calls to libkadm5) > 5. The scheduler forwards this TGT as usual Yup, this is also what I would do given your constraints. (You have a fairly weird security corner case that requires arbitrary user impersonation with no chain of authentication back to the user being impersonated, which Kerberos doesn't really natively support for somewhat obvious reasons.) > Is there a cleaner alternative? Ideally, one that doesn't involve > replicating users. You possibly could cheat by giving the GSS service access to the cross-realm key so that it can forge TGTs that look to the MIT Kerberos KDC as if they were issued by AD. I think this would be roughly equivalent from a security standpoint (either way, the GSS service is essentially a KDC and has full access to the entirety of your MIT realm), but would avoid the need to create principals in your KDC database for every user. The drawback of this approach is that you're likely to need to write some low-level Kerberos code to forge the tickets, whereas in your plan above you can just generate keytab files for every user and store them on disk (again, the GSS service is functionally equivalent to a KDC, so this is just the KDC database in another format), and then your GSS service can generate TGTs through normal libkrb5 calls using the keytab and doesn't have to do anything special. -- Russ Allbery (ea...@eyrie.org) <https://www.eyrie.org/~eagle/> Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: kadmin not working after server migration, but kdc works
Wouter Verhelst writes: > On Tue, Sep 20, 2022 at 11:43:40AM -0400, Greg Hudson wrote: >> From experience, this probably means you have a single-DES enctype >> listed in supported_enctypes and are using release 1.18. (In 1.17 or >> previous the enctype would be recognized; in 1.19 or later the library >> would ignore the enctype rather than failing out.) Remove the >> single-DES enctype and kadmind should start working again. > So, supported_enctypes is not even in the krb5.conf file; I assume that > means it then reverts to defaults? That's your krb5.conf, but the error message is about your kdc.conf (/etc/krb5kdc/kdc.conf). It has its own separate supported_enctypes setting. -- Russ Allbery (ea...@eyrie.org) <https://www.eyrie.org/~eagle/> Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: Help with replication
Bill MacAllister writes: > The KDC logs revealed that indeed the principal did not exist. I had > updated the krb5.conf to use a cname for the admin principal and kpropd > is using the entry in the krb5.conf without canonicalization. I changed > the krb5.conf file to use host names that matched the principals that I > had created. That along with making sure kadm5.acl and kpropd.acl had > the appropriate entries solved my problem. Thanks for the pointer. > (Who would have thought to look in the logs? Certainly now me.) Is this the thing where kpropd always uses exactly the hostname you have listed and doesn't do any DNS canonicalization? If so, I've run into that before and I think I just put keys for all of the principals that could be formed from all the possible replica names in the keytab file for the replicas and my recollection is that worked, although it's been a few years. > I guess one what would be to create principals for the cnames. Right, yeah, that. Similar to what we had to do with LDAP servers. -- Russ Allbery (ea...@eyrie.org) <https://www.eyrie.org/~eagle/> Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: Using an alternate principal for ssh
Dan Mahoney writes: > Our userbase is pretty small and systems are overall managed with > puppet, so that's not a problem for us. We'd need to either disallow > GSSAPI entirely, or accept that we need to manipulate a dir of k5login > files outside the users' homedirs. If you're already willing to manage .k5login files, the search_k5login option to my PAM module may also work and the whole reason why I started contributing to that module instead of using Red Hat's (to solve an old issue that Stanford had). alt_auth_map is the more precise solution, but it only allows a single mapping, whereas with search_k5login you can do whatever you want as long as you populate .k5login accordingly. > I'll take a directory of k5login files. As an organization we don't > like pubkey auth because there's no easy central control over users. > (i.e. pubkey completely sidesteps kerberos. If you have something like > ldap deployed, that can help, but we don't like the idea of every system > call like ls -al phoning an LDAP server.) Yes, at Stanford we disabled public key and required GSS-API for most things. -- Russ Allbery (ea...@eyrie.org) <https://www.eyrie.org/~eagle/> Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: Kerberos through loadbalancer
Stefan Kania writes: > we have 4 ldap-provider ldap1.example.net to ldap4.example.net. We > securing the replication via kerberos, everything works fine between the > providers. But now we want to set up some consumers. Between the > providers and the consumers a loadbalancer is located, so the consumers > only connect to the loadbalancer and the loadbalancer chooses one of the > providers. For the replication we put the fqdn from the loadbalancer > into the configuration. The fqdn is ldap.example.net. We then created a > host-principal and a service-principal for ldap.example.net and we put > the host-key into /etc/krb5.keytab of all ldap-providers the same with > the service-key. So now all provider can use both, the own keys and the > keys from the loadbalancer. But it's not working :-(. Two things to check: First, how did you put the service kep for ldap/ldap.example.net onto each host? If you used ktadd via kadmin, you alas did not do that. Each time you downloaded the keytab entry, ktadd randomized the key again, so only the last host on which you put the key has a correct key and all of the rest have incorrect keys. You have to either manually copy the keytab file between hosts without running ktadd again, or somehow use -norandkey to generate the keytab entry. If that's not the problem, it used to be that you had to apply a one-line patch to Cyrus SASL to prevent it from forcing Kerberos to only use the keytab entry that it thought corresponded to the local hostname, which otherwise would prevent this trick from working. I thought Cyrus SASL upstream had finally taken that patch and included it in a release, but maybe you're using an old version of Cyrus SASL? I don't remember what error message that used to produce, though, so maybe this is a different problem. -- Russ Allbery (ea...@eyrie.org) <https://www.eyrie.org/~eagle/> Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: Always prompting for OTP
BuzzSaw Code writes: > But that prompt is a callback to the prompter routine in pam_krb5 passed > in so I could bypass that prompt by just force feeding the "password" > into the response structure right ? Yes, you can intercept it inside pam_krb5. It's really ugly from a pam-krb5 architecture perspective, though, so I'm not sure I'd want to incorporate that upstream. I feel like we went through a very similar problem with the use_pkinit option and we came up with some solution that didn't require doing this response injection thing, but I seem to have swapped all of that out of my brain. But maybe that was a different problem, since, looking at the code, I think I used a prompter that rejected all password prompts, which is sort of the opposite problem from the problem you're having. -- Russ Allbery (ea...@eyrie.org) <https://www.eyrie.org/~eagle/> Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: Always prompting for OTP
Greg Hudson writes: > The FAST negotiation is irrelevant, except insofar as it makes the > design of FAST OTP possible. Client preauth modules implementing OTP > mechanisms simply don't consider the Kerberos password to be the same as > an OTP value, so they ask for the OTP value via the responder or > prompter. Oh, I think this was the bit that I was missing. I was for some reason assuming that the Kerberos library itself understood that part of the thing passed in as a "password" was actually an OTP value and the other part was a password, but it sounds like I was wrong to think this, and instead the entire "password" is sent via RADIUS and it's the RADIUS server that takes it apart into an OTP value and an actual password? And therefore, because of that, the Kerberos library declines to send a password passed in as an argument to krb5_get_init_creds_password to the RADIUS server, and always forces a separate prompt, because it is really designed for the case where the password and OTP are separate and entered separately at two different prompts, the second (for the OTP) triggered by the preauth mechanism? If I have this right, it feels like the root problem is the combined password mechanism that overloads the password field to carry unrelated additional information, but unfortunately that may be forced by the number of protocols that are entirely unable to deal with additional PAM prompts. -- Russ Allbery (ea...@eyrie.org) <https://www.eyrie.org/~eagle/> Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: Always prompting for OTP
BuzzSaw Code writes: > We want the full OTP+password string just passed without modification. Ah, okay, so then in theory the problem could be solved entirely within the Kerberos libraries, although I haven't wrapped my mind around the problem Greg identified. > It would also be nice if when we use > try_first_pass/use_first_pass/force_first_pass options with pam_krb5 > that it actually did that in the OTP case without the extra prompt. > no_prompt doesn't help as the password doesn't stay on the stack. I'm assuming this is because the Kerberos library doesn't think that the passed-in password can be sent after the FAST negotiation and therefore re-prompts internally? I'm not sure I entirely understand the logic flow here. -- Russ Allbery (ea...@eyrie.org) <https://www.eyrie.org/~eagle/> Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: Always prompting for OTP
BuzzSaw Code writes: > A bad side effect of this behavior is that the calling PAM module never > gets that OTP value so it isn't available for other modules in the > stack, so they too prompt for credentials because they think the > password has not been entered yet. What behavior do you expect here? For the full OTP+password string to be carried over to other modules in the stack, or only the password? If the latter, I believe this inherently requires that the pam_krb5 module know to disassemble the password (which would probably also solve your other problems at the cost of more complexity in the PAM module). -- Russ Allbery (ea...@eyrie.org) <https://www.eyrie.org/~eagle/> Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
remctl 3.18 released
I'm pleased to announce release 3.18 of remctl. remctl is a client/server application that supports remote execution of specific commands, using Kerberos GSS-API for authentication. Authorization is controlled by a configuration file and ACL files and can be set separately for each command, unlike with rsh. remctl is like a Kerberos-authenticated simple CGI server, or a combination of Kerberos ssh and sudo without most of the features and complexity of either. Changes from previous release: Add support for PCRE2 for pcre ACLs and use it by preference over PCRE1 if it is found. UTF-8 regular expressions are not enabled by default, but can be enabled by adding (*UTF) to the beginning of the regular expression (a standard PCRE2 feature not specific to remctl). Document that pcre and regex ACL expressions are not automatically anchored at the start and end of the principal name, so they should be explicitly anchored in the configuration unless one intends to allow partial matches. The Perl libraries and the remctl test suite now require Perl 5.10 or later. Document sending SIGHUP to remctld when running in stand-alone mode to ask it to re-read its configuration file, and document that SIGTERM will cause it to exit. (Fixes #30) Mark remctl client library functions that allocate memory with their corresponding deallocation functions so that GCC 11 and later can diagnose memory deallocation bugs. Remove remaining references to pytest-runner in the Python bindings. Thanks, Ken Dreyer. Switch the Ruby bindings tests to Minitest from Test::Unit. Thanks, Ken Dreyer. Update to rra-c-util 10.2: * Fix IN6_ARE_ADDR_EQUAL Autoconf probe on macOS. * Fix compiler flag probes with Clang. * Check that Kerberos headers can be included. * Fix util/fdflag test on Solaris 11 and OpenBSD. * Suppress some additional warnings in GCC 10. You can download it from: <https://www.eyrie.org/~eagle/software/remctl/> This package is maintained using Git; see the instructions on the above page to access the Git repository. Debian packages have been uploaded to Debian unstable. Please let me know of any problems or feature requests not already listed in the TODO file. -- Russ Allbery (ea...@eyrie.org) <https://www.eyrie.org/~eagle/> Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
KDC timeout for MIT Kerberos?
A user of my Kerberos PAM module asked whether there was a way to adjust the timeout when talking to the KDC. The use case is a laptop that may have a dodgy VPN and thus think it's on the Internet but not be able to reach the KDC. https://github.com/rra/pam-krb5/issues/22 My understanding is that Heimdal supports the kdc_timeout configuration option in krb5.conf, but I don't see an equivalent for MIT Kerberos. Is there any way for the application or for the user to control how long it takes for the library to decide that it's not going to get a reply from the KDC and fail the krb5_get_init_creds_password attempt? -- Russ Allbery (ea...@eyrie.org) <https://www.eyrie.org/~eagle/> Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: Kerberos Server Implementation
Charles Hedrick writes: > This is a client-server pair designed to create home directories for > users. When you’re using kerberized NFS the normal pam_mkhomedir won’t > work, because it assumes that root can create directories in the file > system. With kerberized NFS, root has no special privileges. So we have > a pam_kmkhomedir that calls a process on the file server to do the > creation. > If I were doing it again, I’d probably write it using GSSAPI rather than > a basic Kerberos client / server. Then I could write the server as a web > service in python and use libcurl on the client side. Unfortunately it > doesn’t seem to be practical to write a pam module in anything other > than C, but with libcurl all the GSSAPi stuff is handled by the > library. If the client isn’t a pam module, it’s easy enough to write a > GSSAPI client in python. (I can give you example client-server if you > need it.) You may also be interested in remctl, which is designed to do this sort of thing. https://www.eyrie.org/~eagle/software/remctl/ -- Russ Allbery (ea...@eyrie.org) <https://www.eyrie.org/~eagle/> Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: 2FA with krb5
Simo Sorce writes: > Starting an ad-hoc kdc is pretty easy, I have it done in the make check > phase in many small projects, including starting an ldap server, I > haven't tried radius, but hopefully starting a freeradius server is not > exceedingly hard either. Yeah, for the record it was just the RADIUS bit that I didn't already have working. If anyone is curious: https://github.com/rra/pam-krb5/tree/master/ci contains scripts that will set up either an MIT Kerberos KDC or a Heimdal KDC with PKINIT configured and a variety of keytabs and whatnot premade. They are used via GitHub Actions here: https://github.com/rra/pam-krb5/blob/master/.github/workflows/build.yaml -- Russ Allbery (ea...@eyrie.org) <https://www.eyrie.org/~eagle/> Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: 2FA with krb5
Ken Hornstein writes: > Huh, I _kinda_ thought that if you had FAST going, you got FAST OTP (on > the client at least) for free! Which shows what I know. Maybe it works > already and you never tested it? The bit that I suspect doesn't work is all the interactions between the prompting and the prompt control options like use_first_pass. -- Russ Allbery (ea...@eyrie.org) <https://www.eyrie.org/~eagle/> Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: 2FA with krb5
Ken Hornstein writes: > I am not sure of the client coverage of the OTP FAST factor, though. For what it's worth, although my pam-krb5 module implements FAST including both keyed and anonymous FAST, it does not implement FAST OTP. This is because (a) I didn't find any documentation of what I was supposed to do as a client (it's been years since I looked so this quite possibly has changed), and (b) attempting to set up a reasonable test environment looked painful. In particular, there was (at the time, again haven't checked recently) a lot of hand-waving about exactly to set up the RADIUS part, since MIT Kerberos just treats it as an oracle. I haven't checked if sssd supports FAST OTP. That seems much more likely given that they probably have enterprise use cases that would warrant implementing it. I'd be happy to take pull requests since I try to make pam-krb5 reasonably completionist as a hobby (although be aware that it's a purely hobby project at this point), but they would need to include changes to the ci directory to set up the KDC and RADIUS server appropriately so that the test suite could do a proper end-to-end integration test. -- Russ Allbery (ea...@eyrie.org) <https://www.eyrie.org/~eagle/> Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
kstart 4.3 released
I'm pleased to announce release 4.3 of kstart. k5start and krenew are modified versions of kinit which add support for running as a daemon to maintain a ticket cache, running a command with credentials from a keytab and maintaining a ticket cache until that command completes, obtaining AFS tokens (via an external aklog) after obtaining tickets, and creating an AFS PAG for a command. They are primarily useful in conjunction with long-running jobs; for moving ticket handling code out of servers, cron jobs, or daemons; and to obtain tickets and AFS tokens with a single command. Changes from previous release: Add support for kafs to the -t options of k5start and krenew. If AFS setpag support is not compiled in or AFS is not available, but the Linux kafs kernel module is available, do not error out when -t is specified and continue to run the external program. If libkeyutils is found at compile time and a command was specified on the command line, create a new session keyring before running the external command to isolate its AFS credentials from the calling process. Thanks to Bill MacAllister, David Howells, and Jeffrey Altman for proposed code and implementation discussion. If the process run by k5start or krenew is killed by a signal, k5start or krenew now exits with status 128 plus the killing signal rather than zero. This avoids the caller of k5start or krenew thinking the command succeeded when it was killed, and matches the return status behavior of bash. Patch from Aasif Versi. Use explicit_bzero, where available, to overwrite the memory used for the user's password when k5start is run with the -s option. Rename the script to bootstrap from a Git checkout to bootstrap, matching the emerging consensus in the Autoconf world. Update to rra-c-util 9.1: * Fix getgroups error handling in k_haspag replacement. * Check for a working Kerberos header file during configure. * Use AS_ECHO in all Autoconf macros for better portability. * Fix reallocarray portability on NetBSD. * Stop providing a replacement for a broken snprintf. * Don't check for krb5-config when using explicit paths. * Fix new warnings with current versions of GCC and Clang. * Probe for the warning flags supported by the compiler. Update to C TAP Harness 4.7: * Report test failures as left and right instead of wanted and seen. * Fix string comparisons against NULL pointers. * Honor C_TAP_SOURCE and C_TAP_BUILD along with SOURCE and BUILD. You can download it from: <https://www.eyrie.org/~eagle/software/kstart/> This package is maintained using Git; see the instructions on the above page to access the Git repository. Debian packages have been uploaded to Debian unstable. Please let me know of any problems or feature requests not already listed in the TODO file. -- Russ Allbery (ea...@eyrie.org) <https://www.eyrie.org/~eagle/> Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: weak regex/glob in listprincs in kadmin (on ldap)?
"Chris Hecker" writes: > It's not clear how you'd iterate them all with the current API in a > remotely efficient manner. Maybe people don't want to do that very > often though. Whenever I wanted to do something like that, I generally did it using kadmin.local or the library equivalent on a KDC replica rather than trying to do it over protocol. I'm not a huge fan of the kadmin network protocol. It works, mostly, but whenever I was doing something very complicated, I usually had better luck writing some code that could run on a KDC against a local database (I never used LDAP, but the same principle mostly applies) and then wrapping my own protocol around whatever that operation wanted to return. -- Russ Allbery (ea...@eyrie.org) <https://www.eyrie.org/~eagle/> Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
pam-krb5 4.10 released
I'm pleased to announce release 4.10 of pam-krb5. This is a small bug-fix release with a possible security fix, although I don't see a path to exploit the bug. But better safe than sorry. pam-krb5 is a Kerberos PAM module for either MIT Kerberos or Heimdal. It supports ticket refreshing by screen savers, configurable authorization handling, authentication of non-local accounts for network services, password changing, and password expiration, as well as all the standard expected PAM features. It works correctly with OpenSSH, even with ChallengeResponseAuthentication and PrivilegeSeparation enabled, and supports extensive configuration either by PAM options or in krb5.conf or both. PKINIT is supported with recent versions of both MIT Kerberos and Heimdal and FAST is supported with recent MIT Kerberos. Changes from previous release: When re-retrieving the authenticated principal from the current cache, ensure the stored principal in the authentication context is always either valid or NULL. Otherwise, a failure of krb5_cc_get_principal could result in a double free. Thanks to Michael Muehle for the report. Update to rra-c-util 9.0: * Check that at least one Kerberos header file was found and works. * Use AS_ECHO in all Autoconf macros in preference to echo. * Fix portability of reallocarray on NetBSD systems. * Stop providing a replacement for a broken snprintf. Update to C TAP Harness 4.7: * Fix warnings with GCC 10. You can download it from: <https://www.eyrie.org/~eagle/software/pam-krb5/> This package is maintained using Git; see the instructions on the above page to access the Git repository. Debian packages have been uploaded to Debian experimental, and the bug fix patch has been backported to 4.9 in Debian unstable. Please let me know of any problems or feature requests not already listed in the TODO file. -- Russ Allbery (ea...@eyrie.org) <https://www.eyrie.org/~eagle/> Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
remctl 3.17 released
I'm pleased to announce release 3.17 of remctl. This is a stop-gap bugfix release that, alas, doesn't address open feature work. I am considering breaking the remctl distribution into separate releases for each language binding, saving the remctl release for only the primary C library, client, and server. The primary motivation would be to upload the language bindings to their respective ecosystem repositories so that they're available to tools like cpanm and pip. However, this will require work for the Red Hat packaging and a bit more work when manually installing. If this would cause problems for you, let me know. (It's not likely to happen all that quickly, since there are some other things I need to fix first.) remctl is a client/server application that supports remote execution of specific commands, using Kerberos GSS-API for authentication. Authorization is controlled by a configuration file and ACL files and can be set separately for each command, unlike with rsh. remctl is like a Kerberos-authenticated simple CGI server, or a combination of Kerberos ssh and sudo without most of the features and complexity of either. Changes from previous release: Port the PHP extention to PHP 8. This required declaring the arguments to the functions (which should have been done with PHP 7) and removing some obsolete constructs. Make the Python install_requires dependency on typing conditional on Python versions earlier than 3.5 so that setuptools won't attempt to download typing when it's part of the standard library. Thanks to Gianfranco Costamagna and Matthias Klose for the bug report. Fix the Python module build to more reliably test the newly-built module and to enable verbose testing. Fix non-Kerberos network tests on hosts with no IPv4 addresses. In this case, the network tests for binding all configured addresses will bind only to IPv6, which broke some prior assumptions in the test suite. Thanks to Niko Tyni for the bug report. Note that the tests that require a Kerberos setup will still fail in this scenario, since they assume remctld will bind to 127.0.0.1 by default. Stop providing a replacement for a broken snprintf and assume the libc version works correctly. This portability code has proven difficult to maintain, and was only relevant for ancient proprietary UNIX versions that have been obsolete for many years. Update to rra-c-util 8.4: * Fix reallocarray prototyping on NetBSD. * Fix getnameinfo tests on musl-based Linux distributions. * Include string.h when probing for getaddrinfo properties. * Fix Perl style issues found by Perl::Critic::Freenode. * Fix support for configuring the test suite with a krb5.conf file. * Fix tests when the system krb5.conf file does not set default_realm. * Ignore files in tests/config when checking for license identifiers. * Ignore object files when checking for license identifiers. * Drop support for Perl 5.6. * Reformat all C source using clang-format 10. * Remove bogus snprintf tests. Update to C TAP Harness 4.7: * Fix warning with GCC 10. You can download it from: <https://www.eyrie.org/~eagle/software/remctl/> This package is maintained using Git; see the instructions on the above page to access the Git repository. Debian packages have been uploaded to Debian unstable. Please let me know of any problems or feature requests not already listed in the TODO file. -- Russ Allbery (ea...@eyrie.org) <https://www.eyrie.org/~eagle/> Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: SSH and The requires_pre_auth attribute
"Dan Mahoney (Gushi)" writes: > 1) Is my "if it's on the host entry, it must be on the user entry" > basically accurate? Yes. Therefore, because of this, unless you are *certain* that every principal that needs to authenticate to another principal will have requires pre-auth set, you should not set requires pre-auth on server principals. There is in general no strong reason to set requires pre-auth on randomly-generated keys unless you want to force exactly this client behavior. Yes, not having it set means that in theory an attacker can try to brute-force the randomly-generated key, but... it's randomly generated. So if there is any realistic chance of success in this, you have much larger problems. (I don't have off-the-cuff answers to your other questions.) -- Russ Allbery (ea...@eyrie.org) <https://www.eyrie.org/~eagle/> Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
krb5-strength 3.2 released
I'm pleased to announce release 3.2 of krb5-strength. krb5-strength provides a password quality plugin for the MIT Kerberos KDC (specifically the kadmind server) and Heimdal KDC, an external password quality program for use with Heimdal, and a per-principal password history implementation for Heimdal. Passwords can be tested with CrackLib, checked against a CDB or SQLite database of known weak passwords with some transformations, checked for length, checked for non-printable or non-ASCII characters that may be difficult to enter reproducibly, required to contain particular character classes, or any combination of these tests. Changes from previous release: Add new -c (--check-only) option to heimdal-history to check whether a password would be accepted without updating the history or password length databases. Based on work by macrotex. Increase hash iterations for heimdal-history by roughly a factor of four to increase the time required for a password hash to about 0.1 seconds on modern hardware. This will affect newly-stored history entries but will not invalidate existing password history entries. Support building without CrackLib support by passing --without-cracklib to configure. This makes the code a bit simpler and lighter if you don't intend to ever use the CrackLib support. krb5-strength-wordlist now requires Perl 5.010 or later. Use explicit_bzero instead of memset, where available, to overwrite copies of passwords before freeing memory. This reduces the lifetime of passwords in memory. Skip tests that require the stronger rule configuration in the embedded CrackLib when built against system CrackLib. This avoids test failures when built with system CrackLib. Rework the check-valgrind target to use the new C TAP Harness valgrind support and automatically check the valgrind log files for errors at the end of the test suite. Add SPDX-License-Identifier headers to all substantial source files other than those in the bundled version of CrackLib. Update to rra-c-util 8.2: * Implement explicit_bzero with memset if it is not available. * Reformat all C source using clang-format 10. * Work around Test::Strict not skipping .git directories. * Fix warnings with perltidy 20190601 and Perl::Critic 1.134. * Improve check for obsolete strings. * Use a more standard all-permissive license. * Add SPDX-License-Identifier headers to all substantial source files. * Skip more build system files when running the test suite. * Fix warnings with Clang 10, GCC 10, and the Clang static analyzer. * Exclude more valgrind false positives with Kerberos libraries. * Improve support for AIX's bundled Kerberos. Update to C TAP Harness 4.7: * Fix warnings with GCC 10. * Reformat all C source using clang-format 10. * Fixed malloc error checking in bstrndup. * Add support for valgrind testing via test list options. * Report test failures as left and right, not wanted and seen. * Fix is_string comparisons involving NULL pointers and "(null)". * Add SPDX-License-Identifier headers to all substantial source files. You can download it from: <https://www.eyrie.org/~eagle/software/krb5-strength/> This package is maintained using Git; see the instructions on the above page to access the Git repository. Debian packages will be uploaded to Debian unstable shortly once a Perl transition clears. Please let me know of any problems or feature requests not already listed in the TODO file. -- Russ Allbery (ea...@eyrie.org) <https://www.eyrie.org/~eagle/> Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
pam-krb5 security advisory (4.9 and earlier)
Vulnerability type: Buffer overflow
Versions affected: All versions prior to 4.8
Versions fixed: 4.9 and later
Discovered: 2020-03-02
Public announcement: 2009-03-30
CVE ID: CVE-2020-10595
During a refactor of my pam-krb5 Kerberos PAM module, I discovered a
single byte buffer overflow that had been there since either the first
version of the module or very early in its development. During prompting
initiated by the Kerberos library, an attacker who enters a response
exactly as long as the length of the buffer provided by the underlying
Kerberos library will cause pam-krb5 to write a single nul byte past the
end of that buffer.
The effect of this buffer overflow will depend on the buffer allocation
strategy of the underlying Kerberos library, but could result in heap
corruption or a single-byte overwrite of another stack variable, with
unknown consequences. Conceivably, remote code execution could be
possible, although I believe it would be difficult to achieve.
Under normal usage of this PAM module, it never does prompting initiated
by the Kerberos library, and thus most configurations will not be readily
vulnerable to this bug. Kerberos-library-initiated prompting generally
only happens with the no_prompt PAM configuration option, PKINIT, or other
non-password preauth mechanisms.
I do not believe this vulnerability is publicly known, and am not aware of
any exploits in the wild.
This problem has been fixed in pam-krb5 4.9, available from:
https://www.eyrie.org/~eagle/software/pam-krb5/
pam-krb5 was released as the libpam-krb5 and libpam-heimdal packages with
Debian 4.0 (etch) and later. These vulnerabilities will be fixed in the
4.7-4+deb9u1 version of the libpam-krb5 Debian package for Debian 9.0
(stretch) and the 4.8-2+deb10u1 version for Debian 10.0 (buster). They
have also been fixed in the 4.9-1 package for Debian unstable (sid).
For others who use this module, here is a patch that should apply to
versions prior to 4.9. (pam-krb5 4.9 restructures this code.)
diff --git a/prompting.c b/prompting.c
index e985d95..d81054f 100644
--- a/prompting.c
+++ b/prompting.c
@@ -314,26 +314,27 @@ pamk5_prompter_krb5(krb5_context context UNUSED, void
*data, const char *name,
/*
* Reuse pam_prompts as a starting index and copy the data into the reply
* area of the krb5_prompt structs.
*/
pam_prompts = 0;
if (name != NULL && !args->silent)
pam_prompts++;
if (banner != NULL && !args->silent)
pam_prompts++;
for (i = 0; i < num_prompts; i++, pam_prompts++) {
-size_t len;
+size_t len, allowed;
if (resp[pam_prompts].resp == NULL)
goto cleanup;
len = strlen(resp[pam_prompts].resp);
-if (len > prompts[i].reply->length)
+allowed = prompts[i].reply->length;
+if (allowed == 0 || len > allowed - 1)
goto cleanup;
/*
* The trailing nul is not included in length, but other applications
* expect it to be there. Therefore, we copy one more byte than the
* actual length of the password, but set length to just the length of
* the password.
*/
memcpy(prompts[i].reply->data, resp[pam_prompts].resp, len + 1);
prompts[i].reply->length = (unsigned int) len;
--
Russ Allbery (ea...@eyrie.org) <https://www.eyrie.org/~eagle/>
Kerberos mailing list Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos
Re: [oss-security] pam-krb5 security advisory (4.9 and earlier)
Russ Allbery writes: > Public announcement: 2009-03-30 Mutter. Obviously, this should be 2020-03-20. -- Russ Allbery (ea...@eyrie.org) <https://www.eyrie.org/~eagle/> Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: [oss-security] pam-krb5 security advisory (4.9 and earlier)
Russ Allbery writes: > Russ Allbery writes: >> Public announcement: 2009-03-30 > Mutter. Obviously, this should be 2020-03-20. Or even 2020-03-30, a mistake that I have made every time I have written that date. -- Russ Allbery (ea...@eyrie.org) <https://www.eyrie.org/~eagle/> Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
pam-krb5 release 4.9
I'm pleased to announce release 4.9 of pam-krb5. pam-krb5 is a Kerberos PAM module for either MIT Kerberos or Heimdal. It supports ticket refreshing by screen savers, configurable authorization handling, authentication of non-local accounts for network services, password changing, and password expiration, as well as all the standard expected PAM features. It works correctly with OpenSSH, even with ChallengeResponseAuthentication and PrivilegeSeparation enabled, and supports extensive configuration either by PAM options or in krb5.conf or both. PKINIT is supported with recent versions of both MIT Kerberos and Heimdal and FAST is supported with recent MIT Kerberos. Changes from previous release: SECURITY: All previous versions of this module could overflow the buffer provided by the underlying Kerberos library for the response to a prompt by writing a single nul character past the end of the buffer. (CVE-2020-10595) Support use_pkinit with MIT Kerberos. (Debian Bug#871699) Reject passwords as long or longer than PAM_MAX_RESP_SIZE (normally 512 octets), since extremely long passwords can be used for a denial of service attack via the Kerberos string to key function. Thanks to Florian Best for pointing out this issue and suggesting a good fix. Use explicit_bzero instead of memset, where available, to overwrite the memory used by PAM responses before freeing. This reduces the lifetime of passwords and other secrets in memory. Return more accurate errors from the Kerberos prompter function if it was unable to prompt for the password. This may translate into better debug log messages and, in some situations, returning the slightly more accurate PAM_AUTHINFO_UNAVAIL instead of PAM_AUTH_ERR. Fix an edge-case memory leak in pam_chauthtok when prompting for a new password for an ignored user. Ensure the module/basic test will run properly when the system krb5.conf file does not specify a default realm. Reported by TBK. Update to rra-c-util 8.2: * Fix support for configuring the test suite with a krb5.conf file. * Drop support for Perl 5.6. * Reformat all C source using clang-format 10. * Remove bogus snprintf tests. * Fix misplaced va_end in the pam-util putil_log_failure function. * Skip checking for krb5-config on the path if a prefix was given. * Add SPDX-License-Identifier headers to all substantial source files. Update to C TAP Harness 4.6: * Fixed malloc error checking in bstrndup. * Fix (harmless) allocation error in runtests driver. * Add support for valgrind testing via test list options. * Report test failures as left and right, not wanted and seen. * Fix is_string comparisons involving NULL pointers and "(null)". * Add SPDX-License-Identifier headers to all substantial source files. You can download it from: <https://www.eyrie.org/~eagle/software/pam-krb5/> This package is maintained using Git; see the instructions on the above page to access the Git repository. Debian packages have been uploaded to Debian unstable. Please let me know of any problems or feature requests not already listed in the TODO file. -- Russ Allbery (ea...@eyrie.org) <https://www.eyrie.org/~eagle/> Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: Nuances of MIT Kerberos prompting
Greg Hudson writes: > Yes. For this prompter call, name is NULL, banner is the formatted > expiration warning, and num_prompts is 0. Thanks! > Ah, two responder calls, not two prompter calls. I was looking at the > wrong code paths. Oh, sorry, poor bug report on my part. > Now that I look a the PKINIT responder logic, I agree that there is a > bug. In the second call to k5_preauth(), we are processing the KDC > PKINIT padata supplied alongside the issued ticket, in order to > authenticate the KDC response and set the correct reply key. PKINIT > does not need access to client certificates at this stage, but > pkinit_client_prep_questions() re-asks questions for its recorded > identities without checking the padata type or any other state that > would indicate where it is in the process. I will file a ticket. Thanks! > (The real reason kinit isn't affected is that it doesn't use a responder > callback.) Yes, that makes perfect sense in retrospect. I should have started with gdb before speculating. -- Russ Allbery (ea...@eyrie.org) <https://www.eyrie.org/~eagle/> Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: Nuances of MIT Kerberos prompting
Greg Hudson writes:
> On 3/8/20 8:01 PM, Russ Allbery wrote:
>> I think the reason why I am confused by this is that Heimdal uses the
>> prompter to pass along informational messages such as "your principal
>> is about to expire," and I wasn't sure how MIT Kerberos would do the
>> same thing with the responder interface. But maybe it doesn't present
>> those messages, or uses the prompter for them even if a responder is
>> provided and answers the actual questions?
> In MIT krb5 you can set an expire callback
> (krb5_get_init_creds_opt_set_expire_callback()); otherwise the prompter
> is used if present, whether or not a responder is provided.
Oh! Okay, that makes sense. In this case, the prompter is called with
just a banner but no question?
> Yeah, I don't see an explanation there. A PKINIT PKCS12 prompter call
> should be preceded by a "PKINIT initial PKCS12_parse with no password
> failed" message. There are two such trace messages, but the first comes
> during prep_questions(), when prompting is deferred (instead, the
> identity is saved and a question for the responder is generated).
I was wrong -- it's not during verify creds. (I finally realized that I
had enough information that I could set a break point exactly where this
happens and look at the call structure.) It appears to be called twice
during krb5_get_init_creds_password. Here are the Kerberos library
portions of the two backtraces (the prompt in both cases is identical).
This is MIT Kerberos 1.17.
The relevant difference seems to be in frame 4 and frame 5. Source
embedded from the krb5-1.17-final tag. In both cases, k5_preauth then
calls the responder.
#3 0x77f2fc9b in k5_preauth (context=context@entry=0x55594810,
ctx=ctx@entry=0x55595710, in_padata=0x55570bd0,
must_preauth=must_preauth@entry=1, padata_out=0x55595928,
pa_type_out=pa_type_out@entry=0x555958e8)
at ../../../../src/lib/krb5/krb/preauth2.c:1061
#4 0x77f22397 in init_creds_step_request (out=0x7fffc8e0,
ctx=0x55595710, context=0x55594810)
at ../../../../src/lib/krb5/krb/get_in_tkt.c:1398
if (ctx->request->padata == NULL && ctx->method_padata != NULL) {
/* Retrying after KDC_ERR_PREAUTH_REQUIRED, or trying again with a
* different mechanism after a failure. */
TRACE_INIT_CREDS_PREAUTH(context);
code = k5_preauth(context, ctx, ctx->method_padata, TRUE,
&ctx->request->padata, &ctx->selected_preauth_type);
if (code) {
if (save.code != 0)
code = k5_restore_ctx_error(context, &save);
goto cleanup;
}
}
#5 krb5_init_creds_step (flags=0x7fffc8d8, realm=0x7fffc900,
out=0x7fffc8e0, in=, ctx=0x55595710,
context=0x55594810) at ../../../../src/lib/krb5/krb/get_in_tkt.c:1767
code = init_creds_step_request(context, ctx, out);
if (code != 0)
goto cleanup;
#6 krb5_init_creds_step (context=0x55594810, ctx=0x55595710,
in=, out=0x7fffc8e0, realm=0x7fffc900,
flags=0x7fffc8d8) at ../../../../src/lib/krb5/krb/get_in_tkt.c:1727
#7 0x77f230b9 in k5_init_creds_get (
context=context@entry=0x55594810, ctx=0x55595710,
use_master=use_master@entry=0x7fffca98)
at ../../../../src/lib/krb5/krb/get_in_tkt.c:608
#8 0x77f23214 in k5_get_init_creds (
context=context@entry=0x55594810, creds=creds@entry=0x55594cc0,
client=client@entry=0x55596a30, prompter=prompter@entry=0x0,
prompter_data=prompter_data@entry=0x55592d30,
start_time=start_time@entry=0, in_tkt_service=0x0, options=0x55594d40,
gak_fct=0x77f24750 ,
gak_data=0x7fffcb00, use_master=0x7fffca98,
as_reply=0x7fffcaa0) at ../../../../src/lib/krb5/krb/get_in_tkt.c:1833
#9 0x77f24d39 in krb5_get_init_creds_password (
context=0x55594810, creds=0x55594cc0, client=0x55596a30,
password=password@entry=0x0, prompter=prompter@entry=0x0,
data=data@entry=0x55592d30, start_time=0, in_tkt_service=0x0,
options=0x55594d40) at ../../../../src/lib/krb5/krb/gic_pwd.c:317
#3 0x77f2fc9b in k5_preauth (context=context@entry=0x55594810,
ctx=ctx@entry=0x55595710, in_padata=0x5559b210, must_preauth=0,
padata_out=padata_out@entry=0x7fffc800,
pa_type_out=pa_type_out@entry=0x7fffc7f4)
at ../../../../src/lib/krb5/krb/preauth2.c:1061
#4 0x77f21cab in init_creds_step_reply (in=,
ctx=0x55595710, context=0x55594810)
at ../../../../src/lib/krb5/krb/get_in_tkt.c:1638
/* Process the final reply padata. Don't restrict the preauth types or
* record a selected preauth type. */
ctx->allowed_preauth_type = KRB5_PADATA_NONE;
c
Re: Nuances of MIT Kerberos prompting
h types: PA-PK-AS-REP (17) 1583711787.103198: PKINIT client verified DH reply 1583711787.103199: PKINIT client found id-pkinit-san in KDC cert: krbtgt/eyrie@eyrie.org 1583711787.103200: PKINIT client matched KDC principal krbtgt/eyrie@eyrie.org against id-pkinit-san; no EKU check required 1583711787.103201: PKINIT client used KDF 2B06010502030602 to compute reply key aes256-cts/1BD3 1583711787.103202: Preauth module pkinit (17) (real) returned: 0/Success 1583711787.103203: Produced preauth for next request: (empty) 1583711787.103204: AS key determined by preauth: aes256-cts/1BD3 1583711787.103205: Decrypted AS reply; session key is: aes256-cts/8D62 1583711787.103206: FAST negotiation: available -- Russ Allbery (ea...@eyrie.org) <https://www.eyrie.org/~eagle/> Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Nuances of MIT Kerberos prompting
I'm finally revisiting PKINIT prompting in pam-krb5 and am trying to wrap my head around some subtle nuances of behavior to be sure I'm doing reasonable things. Thus, a few questions: 1. The normal prompter interface has a mechanism to send a "name" and a "banner". Neither of these are very well-documented, but the current PAM module behavior is to output them both (name first, then banner) as PAM_TEXT_INFO. I don't see any equivalent in the responder API. How does that work? Is the prompter called with the name and banner but an empty list of prompts and the responder called with the actual questions, if both are given? In what order? I naively would have expected some way to use the responder interface to completely replace the prompter interface, but that doesn't seem to be possible because name and banner aren't supported. 2. Revisiting this message from many years ago: http://mailman.mit.edu/pipermail/kerberos/2013-May/018973.html the suggestion for use_pkinit was to have a prompter that declined to respond to password questions and only passed along preauth questions. This would be an alternative approach to using the responder API. However, this prompts a question: how does a prompter decline to respond to a question? Should the prompter return failure if KRB5_PROMPT_TYPE_PASSWORD appears anywhere in krb5_get_prompt_types, presumably without displaying the name or banner? If so, what status code? 3. How can I trigger MIT Kerberos to send a PKINIT prompt with multiple identities so that I can test the code that prompts the user to select one? The code seems determined to prevent me from specifying multiple pkinit_identities. Only the first one in krb5.conf appears to be honored and any subsequent ones are ignored, and kinit doesn't allow X509_user_identity to be set more than once. Do I *have* to have a PKCS11 module to get to that code path, and I cannot access it with FILE or PKCS12 identities? Finally, more a bug report than a question, but MIT Kerberos 1.17, when given a PKCS12 identity file that's protected with a password (which is what I'm using to test PIN prompting) prompts for the password twice. The second time appears to be during the krb5_verify_init_creds call. What's going on here? The user experience is a little odd. kinit only prompts once, but I think that's because kinit never calls krb5_verify_init_creds. -- Russ Allbery (ea...@eyrie.org) <https://www.eyrie.org/~eagle/> Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: kadmin ignoring target column ?
Laura Smith writes: > I am trying to create a suitably restricted user for use with > configuration automation (SaltStack ). My line looks like the following: > saltstack/ad...@example.com ADMCIL nfs/*@EXAMPLE.COM > I have edited kadm5.acl and restarted kadmind, however list_princs > returns a list of all principals, not just nfs/* ? > If I remove the target column (i.e. saltstack/ad...@example.com ADMCIL) > and restart kadmind, then ADMCIL operates as expected (blocks > list_princs entirely). I don't believe the "l" permission supports the target field. I think it's all or nothing: either you can list all principals or you can't. The man page for kadm5.acl seems to support that: l [Dis]allows the listing of all principals or policies -- Russ Allbery (ea...@eyrie.org) <https://www.eyrie.org/~eagle/> Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
remctl 3.16 released
I'm pleased to announce release 3.16 of remctl. remctl is a client/server application that supports remote execution of specific commands, using Kerberos GSS-API for authentication. Authorization is controlled by a configuration file and ACL files and can be set separately for each command, unlike with rsh. remctl is like a Kerberos-authenticated simple CGI server, or a combination of Kerberos ssh and sudo without most of the features and complexity of either. Changes from previous release: The Python bindings now support Python 3. They have been tested only with Python 2.7 and Python 3.7, but should work with any version of Python 3 later than Python 3.1. The Python bindings have been modernized to remove obsolete syntax, which may mean that versions of Python back to Python 2.3 are no longer supported. The bindings are only tested with Python 2.7. Passing in anything other than an iterable of str or bytes as the command to run is deprecated and support for using objects that can be converted to str in commands will be removed in a future release. Update the Python bindings documentation to use proper Python types and to document how str and bytes values are handled. Building the Python bindings now requires the setuptools, pytest, pytest-runner, and typing Python modules. Add -t flag to the remctl client to specify the network timeout. Thanks, Remi Ferrand. Fix NULL pointer dereference in the client library if allocation of memory fails, caught by cppcheck. Add GCC attributes to the declarations of the libremctl client functions, which will allow some minor optimization improvements and better compiler errors about NULL pointers. Check for minimum versions of Perl or Python during configure if building the Perl or Python bindings is requested. More correctly handle user-supplied CFLAGS in combination with make warnings when building the PHP bindings. Add the warning flags to AM_CFLAGS instead of CFLAGS and pass user-supplied CFLAGS through to configure (but not the warning flags). Thanks, Ken Dreyer. Fix Kerberos library probing with --enable-reduced-depends and correctly suppress probing for Kerberos library features when no Kerberos library is present. Update to rra-c-util 8.0: * Skip more Automake files in tests. * Fix warnings with current versions of GCC and cppcheck. Update to C TAP Harness 4.5: * Fix error checking for malloc failure in bstrndup. You can download it from: <https://www.eyrie.org/~eagle/software/remctl/> This package is maintained using Git; see the instructions on the above page to access the Git repository. Debian packages have been uploaded to Debian unstable. There may be a bit of delay due to NEW processing. Please let me know of any problems or feature requests not already listed in the TODO file. -- Russ Allbery (ea...@eyrie.org) <https://www.eyrie.org/~eagle/> Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: Kerberos n00b question.
Grant Taylor writes: > On 1/8/19 6:22 PM, Russ Allbery wrote: >> Internet use is very common in the Kerberos community. > Does this include client <-> KDC? Yes. A lot of higher education institutions that have used Kerberos for many, many years have their KDCs directly on the Internet and allow clients to authenticate from anywhere. > My cursory reading makes me think that FAST is what provides the > security (by encrypting more things through the Fast and Secure Tunnel) > using parameters derived via PKINIT. PKINIT is just a replacement preauth mechanism, instead of enc-timestamp. Basically, the client uses an X.509 authentication instead of a proof of key possession as the preauthentication step to establish a shared session secret that is used to encrypt the TGT. (This may not be 100% accurate; it's been a while since I dug into the protocol.) FAST is a replacement for the whole preauth step. It uses some pre-existing shared session key between the KDC and the client to encrypt the whole preauthentication exchange. Inside of that, you can use various preauthentication mechanisms. Where they usefully combine is in how to get that pre-existing shared session key to be able to start using FAST. This is a chicken-and-egg problem with traditional Kerberos: you have to authenticate first in order to authenticate. You can, for instance, use the local host key (which is probably randomly generated and therefore safer to use in a direct exchange with the KDC) to get a session key to start FAST, and then do preauthentication with the (weaker) password-derived key. Anonymous PKINIT lets you out of that trap by letting the client "authenticate" with anonymous Diffie-Hellman to the KDC. This doesn't establish any meaningful identity, but it *does* get you a shared session key, and with that you can start FAST, and use it to protect any subsequent preauthentication exchange. Note that you can enable anonymous PKINIT even if you don't otherwise use PKINIT and don't have any client certificates. (You ideally do have a KDC certificate, though, that the clients know about.) -- Russ Allbery (ea...@eyrie.org) <http://www.eyrie.org/~eagle/> Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: Kerberos n00b question.
Robbie Harwood writes: > Also! 2FA will mitigate this concern somewhat as well. krb5 is > prepared to hand off to a RADIUS responder for OTP (freeIPA uses this, > which I know you're not interested in but is meaningful as a PoC); you > can then use something like freeOTP or a physical 2fa token for > acquiring additional credentials. I wonder how hard it would be to add WebAuthn as a preauth mechanism for Kerberos as part of a FAST chain. HOTP/TOTP don't have the greatest security properties, even though most Kerberos use cases are inherently less vulnerable to phishing than the typical web authentication use. > Apologies. I consider Kerberos (with preauth and strong passwords) safe > for internet use, as I imagine the rest of us on here do as well. Internet use is very common in the Kerberos community. It is somewhat vulnerable to weak user passwords, but I'd probably invest my effort in FAST via anonymous PKINIT to solve that problem instead of network tunnels. -- Russ Allbery (ea...@eyrie.org) <http://www.eyrie.org/~eagle/> Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: Kerberos n00b question.
Grant Taylor writes: > I wonder if there is any possibility of users using a random key that is > password protected. Thus using the password unlocking the random key > that is used to secure communications. - I suspect that would make keys > used for users as secure as -randkey for services, at least as far as > brute forcing things. Of course you would need to protect the encrypted > key. But that's a different issue. If you want to go down this path, I would take a look at PKINIT, which replaces the initial authentication request using a password-derived key with X.509 mutual authentication. You have to figure out a PKI strategy to give the users certificates, but that then effectively gives you what you describe: a password-protected random key. I have also implemented half-assed versions of this, such as putting a service with permissions to mint Kerberos TGTs for users behind SSH public key authentication, so that users can use an SSH keypair to get a Kerberos TGT. > I /think/ that client <-> server is okay as part of SSH. - I'm trying > to understand if the client <-> server is okay on it's own, or if it's > also relying on security offered by SSH. Mainly so that I can judge how > safe it is to use for other protocols between the client and server > (with or without other encryption). The client/server exchange uses GSS-API, which is fine on its own and doesn't rely on the SSH encrypted tunnel to be secure. > I think the biggest issue is that I need to get the keytab to the server > in a secure manner. I would expect that something like scp / sftp would > suffice. You may or may not want to think about the chain of trust for the server (i.e., how do you know that you're scp'ing the keytab to the correct machine). In an ideal world, the machine is launched with some existing credentials (like a TLS private key) that are installed on it securely, and then you use those credentials to bootstrap other credentials it needs, such as keytabs. -- Russ Allbery (ea...@eyrie.org) <http://www.eyrie.org/~eagle/> Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: Kerberos n00b question.
Grant Taylor writes: > On 01/07/2019 10:53 AM, Russ Allbery wrote: >> The standard solution for this is FAST, which protects the initial >> authentication against this attack. (You do need some other credential >> to set up the FAST tunnel, but you can use anonymous Diffie-Hellman via >> anonymous PKINIT, or you can use a randomized key.) > Would you please expand (what I assume is) the FAST acronym? I expect > that there will be quite a few phonetic collisions searching for "FAST". I think it stands for Flexible and Secure Tunneling. It's defined in: https://tools.ietf.org/html/rfc6113.html The keywords "kerberos fast" in Google seem to turn up the right stuff (rather more than I had expected; I like you was expecting that to be drowned by performance stuff). -- Russ Allbery (ea...@eyrie.org) <http://www.eyrie.org/~eagle/> Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: Kerberos n00b question.
Grant Taylor writes: > It's my (mis?)understanding that communications between Kerberos clients > and the KDC are in the clear (but do not include the password), and that > there is functionally no communications between a remote server and the > KDC. I don't think describing it as "in the clear" is quite right, but a default Kerberos configuration using enc-timestamp and no tunneling as the preauth mechanism is somewhat vulnerable to packet capture followed by an off-line dictionary attack to recover the authentication key. The standard solution for this is FAST, which protects the initial authentication against this attack. (You do need some other credential to set up the FAST tunnel, but you can use anonymous Diffie-Hellman via anonymous PKINIT, or you can use a randomized key.) The attack still requires subsequent work; you can't just snoop the connection between the client and the KDC and immediately get credentials. The work factor is basically linked to the complexity of the client key, so it's not much of a worry for a randomized key but is a worry for user passwords. > As such, I'm wondering if it would be relatively safe enough to use > Kerberos to authenticate to a VPS in the cloud when both the client and > KDC are on the LAN. I think Kerberized SSH would be the only Kerberos > related traffic across the Big Bad Internet to the VPS. Is this > correct? Yes. > Can anyone point me to some general reading that any /a ll Kerberos n00b > should read? (I've been following How-Tos and gotten a lot to work.) I don't have a good answer for this, unfortunately. -- Russ Allbery (ea...@eyrie.org) <http://www.eyrie.org/~eagle/> Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: Running KDC as non-root and dockerize KDC
Grant Taylor writes: > Do you happen to know off hand if DNS lookups for SRV records happen > before or after initial connection attempts to the standard ports? > If SRV records are looked up /before/ attempting to connect to standard > ports, I could see adding SRV records as a simple optimization. Before, in the sense that you mean, although it's a little more complicated than that since krb5.conf configuration will override SRV records (as you might expect). So SRV records are only used when there's no client configuration, and in that case the client otherwise isn't going to know what to connect to, so there wouldn't be a connection attempt to a standard port. The idea of SRV record configuration is that all the client needs to know is the realm, at which point it looks up the SRV records for that realm and gets all the other server connection information it needs from that. -- Russ Allbery (ea...@eyrie.org) <http://www.eyrie.org/~eagle/> Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: Running KDC as non-root and dockerize KDC
Grant Taylor writes: > Aside: How well would Kerberos work if these services ran on a high > port and IPTables magic was used to redirect requests to the low ports > up to high ports? It should be fine as long as the magic handles both UDP and TCP. Another option would be to run the services on non-standard ports and configure the clients. Modern clients support SRV records, which include the port and let you configure alternate ports. Even older clients that don't support SRV records can be configured in krb5.conf, which supports specifying a port, although I'm not sure how good the support for that is for all protocols and older versions. -- Russ Allbery (ea...@eyrie.org) <http://www.eyrie.org/~eagle/> Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: issue with k5start
I saw your other follow-up, but just to close out a few things with this thread Kristen Webb writes: > On Tue, Sep 25, 2018 at 3:11 PM Russ Allbery wrote: >> It should only do this if the ticket is going to expire sooner than two >> minutes before the next wake-up period, though, I think? I would have >> expected this to work with all jobs sharing the same cache file, as >> long as they're at least a little staggered. That said, I don't think >> I've really tested for this sort of parallelism, and it's entirely >> possible that the separate k5start processes don't manage coordination >> between each other on the same ticket cache properly. > The only control I can find for the CC is the -a flag, which always > renews tickets when k5start wakes up. It looks like k5start always > inits the CC on startup. Oh, yes. That's true. > This works for most cases. However, when a new job starts near the time > a TGT is ready to be renewed, it's afs token lifetime can be quite short > and can expire before a planned re-aklog within that PAG. Yes, you have to arrange the timings such that the minimum remaining lifetime of the TGT is always above the minimum length of a token that you need. This should be possible with the right set of flags, but it won't avoid the initialization of the cache on startup. > This is similar to what I am trying to do manually. It would appear > that k5start might be capable of doing this, and I would be interested > in trying to help implement this feature. I've added this to TODO, for the record, although I haven't had much time to work on kstart in the last few years. * Add a mode of operation that only runs the aklog program and doesn't attempt to refresh the ticket cache unless it's about to expire. This would allow multiple k5start daemons to use the same ticket cache without putting a lot of load on the Kerberos KDC for constant renewals from each daemon. -- Russ Allbery (ea...@eyrie.org) <http://www.eyrie.org/~eagle/> Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: issue with k5start
Kristen Webb writes: > When I use the -k ccache option it appears that each job simply > overwrites the cchache file. It should only do this if the ticket is going to expire sooner than two minutes before the next wake-up period, though, I think? I would have expected this to work with all jobs sharing the same cache file, as long as they're at least a little staggered. That said, I don't think I've really tested for this sort of parallelism, and it's entirely possible that the separate k5start processes don't manage coordination between each other on the same ticket cache properly. > Is there a way to use k5start to achieve what I am after > - shared ccache for many jobs to keep kerberos server traffic down > - allow long running jobs to continue beyond their initial aklog > renewal date > If I ran k5start as a daemon and managed periodic aklog's within my > application, would that work? Yes, that's what I was going to suggest. If each application is running in a separate PAG, each application needs to run aklog periodically independently of the others. If you also want to share a single ticket cache among the applications, you probably want to split those two operations. Unfortunately, k5start doesn't currently have a mode of operation in which it only runs the aklog command but doesn't try to renew tickets if they aren't about to expire. -- Russ Allbery (ea...@eyrie.org) <http://www.eyrie.org/~eagle/> Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
wallet 1.4 released
I'm pleased to announce release 1.4 of wallet. The wallet is a system for managing secure data, authorization rules to retrieve or change that data, and audit rules for documenting actions taken on that data. Objects of various types may be stored in the wallet or generated on request and retrieved by authorized users. The wallet tracks ACLs, metadata, and trace information. It is built on top of the remctl protocol and uses Kerberos GSS-API authentication. One of the object types it supports is Kerberos keytabs, making it suitable as a user-accessible front-end to Kerberos kadmind with richer ACL and metadata operations. Changes from previous release: Substantial improvements to Active Directory support: Add a contrib/ad-keytab script that assists with initial setup and examining the Active Directory objects, rename some configuration variables to reflect that they are relative distinguished names, add a configuration variable for the base DN, make sure userPrincipalName is created for all keytabs and use it to search, allow creation of a service principal, and truncate and make unique long names in AD if necessary. This support should still be considered experimental. When getting configuration values from krb5.conf, pass the default local realm into the Kerberos appdefault functions. This will produce more correct results with krb5.conf files that specify wallet configuration for multiple realms. Remove stray references to strlcpy and strlcat that broke builds on platforms where those functions are part of libc. Thanks to Karl Kornel for the report. Detect the path to Perl during configure, allowing an override by setting the PERL environment or configure variable, and use that path for all Perl scripts. This allows wallet to use a version of Perl at a non-standard path. Patches from Karl Kornel. Rename the script to bootstrap from a Git checkout to bootstrap, matching the emerging consensus in the Autoconf world. Add SPDX-License-Identifier headers to all substantial source files. Update to rra-c-util 7.2: * Improve configure output for krb5-config testing. * Define UINT32_MAX for systems that don't have it. * Add SPDX-License-Identifier headers to all substantial source files. * Fix new warnings from GCC 7 and Clang warnings. * Require Test::Strict 0.25 or later to run those tests. * Fix off-by-one error in return-value checks for snprintf. * Use Autoconf to probe for supported warning flags. * Fix running module-version-t -u with current versions of Perl. * Use C_TAP_SOURCE and C_TAP_BUILD instead of SOURCE and BUILD. Update to C TAP Harness 4.3: * Add support for valgrind and libtool in test lists. * Report test failures as left and right, not wanted and expected. * Fix string comparisons with NULL pointers and the string "(null)". * Add SPDX-License-Identifier headers to all substantial source files. * Avoid zero-length realloc allocations in breallocarray. * Fix new warnings from GCC 7 and Clang warnings. * Use C_TAP_SOURCE and C_TAP_BUILD instead of SOURCE and BUILD. You can download it from: <https://www.eyrie.org/~eagle/software/wallet/> This package is maintained using Git; see the instructions on the above page to access the Git repository. Please let me know of any problems or feature requests not already listed in the TODO file. -- Russ Allbery (ea...@eyrie.org) <http://www.eyrie.org/~eagle/> Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
remctl 3.15 released
I'm pleased to announce release 3.15 of remctl. remctl is a client/server application that supports remote execution of specific commands, using Kerberos GSS-API for authentication. Authorization is controlled by a configuration file and ACL files and can be set separately for each command, unlike with rsh. remctl is like a Kerberos-authenticated simple CGI server, or a combination of Kerberos ssh and sudo without most of the features and complexity of either. Changes from previous release: Fix a bug where output could have been truncated for a command run by the server that was accepting an argument on standard input, if it exited before reading all of the input data. Incorrect server logic disabled reads from the child process on write failure, so could have missed the last buffer of output from the child. This was only seen under valgrind testing, not reported as a bug, so it's not clear how widespread of a problem this was. Validate command argument count, the length of command arguments, and the length of blocks of output from the server fit into the data type used in the wire protocol. Check the port argument to remctl and remctld to ensure that it is a valid port number. Add maintainer check-cppcheck target to run cppcheck across the source base with a standard configuration. Fix all issues found by cppcheck. Rework the check-valgrind target to use the new C TAP Harness valgrind support and automatically check the valgrind log files for errors at the end of the test suite. This catches the bad free that caused the security issue in 3.14. Flesh out support for Clang warnings and compile cleanly under Clang with most warnings enabled (-Weverything with some exclusions). Add SPDX-License-Identifier headers to all substantial source files. Update to rra-c-util 7.1: * Avoid spurious test failures from the network library. * Fix configure output when a Kerberos install prefix was provided. * Fix new warnings in GCC 7 and add new warning flags. * Fix all warnings from the Clang static analyzer. * Fix warnings under Clang with most warnings enabled. * Define UINT32_MAX for systems that don't have it. * Support running remctld under valgrind for memory leak testing. * Update the valgrind suppression file. Update to C TAP Harness 4.3: * Add support for valgrind testing via test list options. * Report test failures as left and right, not wanted and seen. * Fix is_string comparisons involving NULL pointers and "(null)". You can download it from: <https://www.eyrie.org/~eagle/software/remctl/> This package is maintained using Git; see the instructions on the above page to access the Git repository. Debian packages have been uploaded to Debian unstable. Please let me know of any problems or feature requests not already listed in the TODO file. -- Russ Allbery (ea...@eyrie.org) <http://www.eyrie.org/~eagle/> Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: /etc/default/krb5-admin-server: 'RUN_KADMIND=false' not possible anymore
Giuseppe Mazza writes: > I want to install a new kerberos slave running on Ubuntu16.04. I would > like to prevent the service krb5-admin-server running on the slave. systemctl disable krb5-admin-server -- Russ Allbery (ea...@eyrie.org) <http://www.eyrie.org/~eagle/> Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: Determening the number of clients per KDC
Mark Pröhl writes: > On 04/16/2018 05:51 PM, Russ Allbery wrote: >> ... Clients aren't going to generally all try to get a ticket at the >> same time, due to ticket caching, so that scales to a lot of clients. > I have only seen JAVA/JAAS clients caching the TGT and not the service > tickets. Especially in Hadoop environments this leads to much more TGS > traffic than in "classical" Kerberos environments. 1000 rps are not > unusual. Ah, interesting! (Also incredibly broken behavior) -- Russ Allbery (ea...@eyrie.org) <http://www.eyrie.org/~eagle/> Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: Determening the number of clients per KDC
Andrew Cobaugh writes: > Also currently using it to demonstrate how much faster MIT Kerberos is > compared to AD, even when not using workers (on modern-ish CPUs, without > workers enabled krb5kdc can do ~4000 rps. I can share more details if > folks are interested). Ah, good, I'm glad my 100 qps number was off in the direction that I thought it would be. I didn't want to overpromise, but KDCs are *really fast*. -- Russ Allbery (ea...@eyrie.org) <http://www.eyrie.org/~eagle/> Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: Determening the number of clients per KDC
Sergei Gerasenko writes: > Will keeping an access log slow me down much, do you know? Yes, you may want to tune syslog or whatever you're using for your KDC logging, although MIT is a lot better than Heimdal in that regard (Heimdal is very verbose). I generally disabled sync to disk on the syslog log file that the KDC logging was routed to. > For that matter, is there a benchmarking tool for KDCs? Not that I'm aware of. I usually just rolled my own by calling kinit with a keytab and then kvno to get service tickets. > Ok, it’s just that I see everywhere > (e.g. https://en.wikipedia.org/wiki/Kerberos_(protocol) > <https://en.wikipedia.org/wiki/Kerberos_(protocol)>) that the initial > TGT response includes a session key that the host and the service server > will share. So that’s what got me thinking that once a TGT is retrieved, > the client should request a service ticket using the same KDC. But like > I said, I’m total newb. The TGT contains both the session key and a copy of the session key encrypted in the KDC's private key, which is shared between all of the KDCs as part of the normal database, and the client always provides that encrypted copy of the key back in subsequent protocol exchanges. -- Russ Allbery (ea...@eyrie.org) <http://www.eyrie.org/~eagle/> Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: Determening the number of clients per KDC
Sergei Gerasenko writes: > Since I don’t know too much about the KDC architecture, sorry for the > dilettante questions. Oh, no problem -- just be aware that they're being answered by someone who hasn't run large-scale KDCs in about four years, so some of my information is stale. :) >> It's unfortunately been long enough since I've tested this on a system >> running flat out that I don't remember what qps a KDC can do on modern >> hardware, but I would expect it to at least be in the range of 100 qps. > Is that per worker? Oh, workers are new to me. So yes, that would be per-worker. > Speaking of workers, does MIT Kerberos spawn workers as needed (sort of > like apache) or is it capped by the `-w` argument? What’s a good number > of workers to start with? 70? 500? 1000? If you're doing default Kerberos, the networking is UDP, so it's not going to spend a lot of time waiting for the network. I would expect that to be CPU-bound, and therefore would tend towards one worker per core. If you're doing a lot of TCP, that might increase the chances that you'll wait for networking, and may benefit from more workers. This is all just a wild-ass guess, though. Given your setup, though, it would really surprise me if you saw any performance issues. > Ok, to clarify what you mean by the replica serving requests as well, do > you mean: > 1. Using a VIP that round-robins the requests to the primary and > secondary KDC? > 2. Or do you mean that half the clients use the master and the other > half the slave? > 3. Or do you mean that the client itself round-robins between them? You can use SRV records and get 3 by just listing both KDCs as equal weight. All Kerberos clients these days should support SRV records. If you do have Kerberos clients that don't do SRV records for some reason, it's pretty easy to do 2 by just randomizing the order of the KDCs in /etc/krb5.conf. Kerberos clients are very good about falling back to a second server. You'll just see a slight delay that you might not even notice. > I can only see 2 as a real option because *I think* once a TGT is > requested, all TGS requests would need to go to the server that gave the > TGT? Nope, all KDCs share the same database and can answer all requests. From a client perspective, all KDC traffic is completely interchangeable. The only time it matters is when there's a write, since there's a propagation delay and the replica will serve stale information for a short period of time. For keytabs, this almost doesn't matter; for user credentials with passwords, there's a way to configure the client to automatically retry the master if an authentication fails against the replica, which can be useful for authentication immediately after a password change if you're not using incremental replication. -- Russ Allbery (ea...@eyrie.org) <http://www.eyrie.org/~eagle/> Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: Determening the number of clients per KDC
Sergei Gerasenko writes: > Thanks for the quick response, Russ. Let’s say I run 1 worker > process. How many clients can that sustain in the worst case scenario of > all the clients trying to get a ticket? I need some way to quantify > this. As for failover, I am planning to deploy a standby node. It's unfortunately been long enough since I've tested this on a system running flat out that I don't remember what qps a KDC can do on modern hardware, but I would expect it to at least be in the range of 100 qps. It's probably constrained by the KDC being single-threaded. Clients aren't going to generally all try to get a ticket at the same time, due to ticket caching, so that scales to a lot of clients. General rule of thumb for KDCs is that you want at least a master and a replica, and there's no reason not to have the replica serve most of the traffic (in other words, I wouldn't go with a standby design). Usually I run at least three KDCs, although the number three is mostly because I started with kaserver that needed three KDCs for stable Ubik quorum, which of course isn't a thing with regular KDCs, so I don't know that three is really better than two. -- Russ Allbery (ea...@eyrie.org) <http://www.eyrie.org/~eagle/> Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: Determening the number of clients per KDC
Sergei Gerasenko writes: > I’m planning an MIT KDC installation for a hadoop cluster consisting of > X clients with Y kerberized services each. The KDCs are rather powerful > machines with 64 cores and 125G of RAM. I want to get the most out of > this hardware and use the mininum number of KDCs required. Is there a > rule of thumb for situations like this? > For example, imagining X=300 and Y=10, can/should I run X*Y (3000) > workers to accomodate the worst case scenario when they all want to get > their tickets? Or can I assume that X*Y/2 will can handle that? For 3000 workers, you could probably run the KDC on a Raspberry Pi. Redundancy for outage tolerance is almost certainly going to be the limiting factor for number of KDCs in this situation unless you have way, way more clients getting tickets than that, or you're using really short ticket lifetimes, or you have some other unusual situation. -- Russ Allbery (ea...@eyrie.org) <http://www.eyrie.org/~eagle/> Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
remctl 2018-04-01 Security Advisory
Vulnerability type: Use after free, double free Versions affected: 3.12 and 3.13 Versions fixed: 3.14 and later Reported:2018-03-30 Public announcement: 2018-04-01 CVE IDs: CVE-2018-0493 Santosh Ananthakrishnan discovered incorrect memory management in the remctld and remctl-shell servers when handling commands with the sudo configuration option. For remctld, it may be possible (although appears to be difficult) for a client to execute arbitrary commands on the server. To exploit this vulnerability, the client must have access to run a command that uses the sudo configuration option. The client would then need to run the command using sudo multiple times in a single connection using keep-alive. I'm not aware of any exploits in the wild. remctl-shell is not affected, only remctld. This problem has been fixed in remctl 3.14, available from: https://www.eyrie.org/~eagle/software/remctl/ It has also been fixed in Debian stable (stretch) in the 3.13-1+deb9u1 package version, and in Debian unstable in the 3.14-1 package version. Only the remctl-server package is affected. This bug is not present in older Debian releases. My apologies for this memory management error. It's an obvious error in context and was probably left over from a code refactoring when developing the sudo feature. I hope to include better automated memory management testing in the next release of remctl after 3.14. -- Russ Allbery (ea...@eyrie.org) <http://www.eyrie.org/~eagle/> Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
remctl 3.14 released
Version 3.14 of remctl has been released. This is a minimal security fix over 3.13 (with some additional warning fixes for the latest version of GCC). remctl is a client/server application that supports remote execution of specific commands, using Kerberos GSS-API for authentication. Authorization is controlled by a configuration file and ACL files and can be set separately for each command, unlike with rsh. remctl is like a Kerberos-authenticated simple CGI server, or a combination of Kerberos rsh and sudo without most of the features and complexity of either. Changes from previous release: SECURITY: Fix use-after-free and double-free when handling the sudo option in the remctld and remctl-shell server. For remctl-shell, this will occasionally produce a spurious non-zero exit status for a command that succeeded. For remctld, the normal consequence is a server process crash after running a command with the sudo option, but it may be possible (albeit difficult) for a streaming client to abuse this bug to execute an arbitrary command on the server or corrupt server memory. Thanks, Santosh Ananthakrishnan. (CVE-2018-0493) You can download it from: <https://www.eyrie.org/~eagle/software/remctl/> This package is maintained using Git; see the instructions on the above page to access the Git repository. Debian packages have been uploaded to Debian unstable. Please let me know of any problems or feature requests not already listed in the TODO file. -- Russ Allbery (ea...@eyrie.org) <http://www.eyrie.org/~eagle/> Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: -allow_tgs_req
Chris Hecker writes: > Right, I will disable the princ when I find out obviously, I just want > the person to not be able to use it as a user princ to get tickets to > other services in the meantime. Does that make sense or am I missing > something? It makes sense -- I just don't think it's something that currently exists in the KDC's permission model, at least so far as I can tell. Although it's entirely possible I'm missing something. -- Russ Allbery (ea...@eyrie.org) <http://www.eyrie.org/~eagle/> Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: -allow_tgs_req
Chris Hecker writes: > Ah, I assumed that was symmetric for some reason. I obviously need to > be able to get tickets for these services. Not sure why I thought that. > I'll check it out, thanks! It is symmetric, yeah, so it has the problem that you're assuming it has. I don't think there's a way to disable exactly the bit that you want. There's -allow_svr, which prevents issuing service tickets for the principal, and -allow_tix, which presents issuing any tickets at all, but I don't think there's a flag to keep from allowing that principal to authenticate and get a TGT. Maybe -pwexpire in the past would do what you want? I'm not sure how that interacts with service tickets. Note, however, that if your keytab is compromised, the attacker can issue arbitrary service tickets for your service in any identity they chose, so I'm not sure you would want to leave service tickets enabled in that situation. -- Russ Allbery (ea...@eyrie.org) <http://www.eyrie.org/~eagle/> Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: -allow_tgs_req
Chris Hecker writes: > Ah. Is there any way to prevent a service princ from being able to get > tickets? > As in, if one of my service keytabs is compromised, can I prevent those > princs from being used like a normal user princ? I think you want -allow_tix. -- Russ Allbery (ea...@eyrie.org) <http://www.eyrie.org/~eagle/> Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: -allow_tgs_req
Chris Hecker writes: > If -allow_tgs_req / DISALLOW_TGT_BASED is set on a service princ then I > shouldn't be able to kinit with it, right? I'm able to get TGTs though > with kinit and the keytab for this service, and then get service tickets > with kvno; I need to update my KDC and see if this is still true, or > mabye I'm misunderstanding how it works...? That prevents other principals from getting service tickets for that principal using a TGT. It's intended for principals like kadmin/changepw that want to force an AS-REQ to get a service ticket for that principal. It doesn't have any effect on authenticating as that principal. -- Russ Allbery (ea...@eyrie.org) <http://www.eyrie.org/~eagle/> Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
pam-krb5 4.8 released
I'm pleased to announce release 4.8 of pam-krb5. pam-krb5 is a Kerberos PAM module for either MIT Kerberos or Heimdal. It supports ticket refreshing by screen savers, configurable authorization handling, authentication of non-local accounts for network services, password changing, and password expiration, as well as all the standard expected PAM features. It works correctly with OpenSSH, even with ChallengeResponseAuthentication and PrivilegeSeparation enabled, and supports extensive configuration either by PAM options or in krb5.conf or both. PKINIT is supported with recent versions of both MIT Kerberos and Heimdal and FAST is supported with recent MIT Kerberos. Changes from previous release: When verifying that an expired password can still be used to get kadmin/changepw credentials, correctly set the credential options for getting password change credentials, not for getting initial credentials. This should fix password change issues when, for example, krb5.conf requests that all tickets be proxiable but kadmin/changepw doesn't allow proxiable credentials. Thanks to Florian Best for the bug report. When built against recent versions of Heimdal with richer status codes from PKINIT attempts, report to the user the reason for a PKINIT failure. Based on work by Henry Jacques. Document the test suite configuration files required to run the PKINIT tests. Fix expired password tests to work with Heimdal 7.0.1 and later. Better document that the default Kerberos library ticket cache location is not used (and why), and how to set configuration parameters in krb5.conf. Thanks, Matthew Gabeler-Lee. (Debian Bug#872943) Compile cleanly under GCC 7 and Clang warnings and Clang's static analyzer. Rename the script to bootstrap from a Git checkout to bootstrap, matching the emerging consensus in the Autoconf world. Update to rra-c-util 7.0: * Fix new warnings in GCC 7. * Support a warning build under Clang. * Avoid zero-length allocations in reallocarray and vector. * Probe for warning flags instead of hard-coding a list. * New test for obsolete URLs and email addresses. * Remove unused portable replacements for strlcpy and strlcat. * Use C_TAP_SOURCE and C_TAP_BUILD environment variables in tests. * Fix portability defines for anonymous principal strings. * Clear errno on pam_modutil_getpwnam to improve other testing. * Add portability defines for macOS's PAM implementation. * Add new Autoconf macro to probe for pam_strerror const usage. * Support Solaris 10's included Kerberos. Update to C TAP Harness 4.2: * Avoid zero-length allocations in breallocarray. * Add is_blob and is_bool functions. * Use C_TAP_SOURCE and C_TAP_BUILD environment variables in tests. * Fix segfault in runtests with an empty test list. * Display verbose test results with -v or C_TAP_VERBOSE. * Test infrastructure builds cleanly with Clang warnings. You can download it from: <https://www.eyrie.org/~eagle/software/pam-krb5/> This package is maintained using Git; see the instructions on the above page to access the Git repository. Debian packages have been uploaded to Debian unstable. Please let me know of any problems or feature requests not already listed in the TODO file. -- Russ Allbery (ea...@eyrie.org) <http://www.eyrie.org/~eagle/> Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: PID file ... not readable (yet?)
Robbie Harwood writes: > Won't this produce something that requires systemd if systemd was > present during build, thereby preventing a maintainer from shipping both > a sysvinit script and a systemd unit file? Or am I misunderstanding? No, the sd_notify call in libsystemd quietly does nothing, successfully, if the system wasn't booted with systemd. -- Russ Allbery (ea...@eyrie.org) <http://www.eyrie.org/~eagle/> Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: PID file ... not readable (yet?)
Benjamin Kaduk writes:
> I suspect that we would be a little friendlier to systemd if we passed
> -n to krb5kdc and adjusted the unit file accordingly. There would still
> be a race window between when systemd thinks krb5kdc is started and
> ready to accept connections and when that is actually the case, but in
> both cases that window is small, and we cannot eliminate it entirely
> without patching the code to call systemd-specific functions.
For what it's worth, that's a pretty light burden. It's just the
following Autoconf probe:
PKG_CHECK_EXISTS([libsystemd],
[PKG_CHECK_MODULES([SYSTEMD], [libsystemd])
AC_DEFINE([HAVE_SD_NOTIFY], 1, [Define if sd_notify is available.])])
(does require the pkg-config Autoconf stuff as well), the following at the
start of the daemon C file:
#ifdef HAVE_SD_NOTIFY
# include
#else
# define sd_notify(u, s) 0
#endif
and then just the following call when the daemon has started up and is
ready for connections:
sd_notify(true, "READY=1");
or, to be more complete, something akin to:
status = sd_notify(true, "READY=1");
if (status < 0)
warn("cannot notify systemd of startup: %s", strerror(-status));
Then you can be a native systemd daemon and systemd will know exactly when
the KDC is ready to respond to connections, which will resolve various
race conditions when some other system service depends on the KDC for
startup.
--
Russ Allbery (ea...@eyrie.org) <http://www.eyrie.org/~eagle/>
Kerberos mailing list Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos
Re: Kerberos and LDAP password sync question
Greg Hudson writes: > There's krb5-sync, which works with MIT krb5 or Heimdal. It's designed > to sync to Active Directory, so while it does sync passwords via LDAP, > I'm not sure it will work with just any LDAP server as the target. > https://www.eyrie.org/~eagle/software/krb5-sync/ It doesn't use LDAP to store the password, only the account status. It uses the Kerberos password change protocol to store the password. So that won't be immediately helpful for a generic LDAP server. -- Russ Allbery (ea...@eyrie.org) <http://www.eyrie.org/~eagle/> Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: client IP address in Kerberos ticket.
Jim Shi writes: > Hi, I have question regarding client IP address checking in KDC. Is > that true that by default tickets issued by KDC is not bound to any > client IP address. Also KDC server does not check IP if the ticket does > not have any client IP address in it. > Do we have to explicitly turn on the client IP address checking on KDC? > How to do it? Thank you very much. I am dubious that IP address checking is a meaningful security measure. My recommendation would be to forget that it exists and not rely on it for your security model. You're correct that the default value of the noaddresses configuration option is true, largely because address-locked tickets tend to cause tons of problems in modern network environments that often involve NAT. -- Russ Allbery (ea...@eyrie.org) <http://www.eyrie.org/~eagle/> Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: Is a keytab file encrypted?
Russ Allbery writes: > Charles Hedrick writes: >> * A kerberized service where the user registers that they want to be >> able to do cron jobs on a given machine. >> * A kerberized pam module that calls the same service and gets back >> credentials, locked to the IP address, and at least by default not >> forwardable. > How does this address the problem raised on this thread? It's still the > case that if you become root on the host, you can just steal the keytab > used by that daemon and use it anywhere. This gives you enhanced > protection if you trust the boundary between non-root users and root, > but not if you don't trust the machine. Oh, wait, I see -- it does transform part of the attack to occasional on-line, since while you can steal the system keytab and request tickets whenever you want, you can't get the long-lived keytab for the actual target credential. (And presumably you can put monitoring and alerting around the host keytab being used from unexpected places.) Yeah, that's a partial security improvement. -- Russ Allbery (ea...@eyrie.org) <http://www.eyrie.org/~eagle/> Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: Is a keytab file encrypted?
Charles Hedrick writes: > * A kerberized service where the user registers that they want to be > able to do cron jobs on a given machine. > * A kerberized pam module that calls the same service and gets back > credentials, locked to the IP address, and at least by default not > forwardable. How does this address the problem raised on this thread? It's still the case that if you become root on the host, you can just steal the keytab used by that daemon and use it anywhere. This gives you enhanced protection if you trust the boundary between non-root users and root, but not if you don't trust the machine. The point of the TPM is that you can't exfiltrate the keys, even if you have root, only perform on-line operations. -- Russ Allbery (ea...@eyrie.org) <http://www.eyrie.org/~eagle/> Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: Is a keytab file encrypted?
Charles Hedrick writes: > The argument makes sense. > However I am disturbed by the fact that a keytab can be used > anywhere. If someone manages to become root on one machine, I’d like > them not to be able to do things on other machines. I’m in an > environment where we have systems administered by users, and unattended > public workstations. > That makes me unwilling to tell users to create key tables for cron > jobs. Yeah, if you're worried about portable keys, that's when you probably want to do something with a system TPM. If you go down that path, I'd probably try to figure out some way to do PKINIT using a TLS certificate stored in the TPM. I'm not aware of anyone who has already done that work, but it would be a pretty interesting project. -- Russ Allbery (ea...@eyrie.org) <http://www.eyrie.org/~eagle/> Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: Is a keytab file encrypted?
Greg Hudson writes: > On 07/18/2017 12:48 PM, pratyush parimal wrote: >> (2) Is it possible to export the key in encrypted form? If so, then how >> does the service application open the encrypted keytab? > The keytab file does not have any way to represent encrypted keys, and > the kadmin protocol has no facility to export encrypted keys. One > could, in principle, design an out-of-band system which used > kadmin.local to create a keytab, encrypt the file, transmit the > encrypted kyetab file to the server, and then decrypt the file on the > server (into a memory filesystem, perhaps) before running the server > application, but I've never heard of anyone doing that. You have kind of a chicken and an egg problem, since in a typical Kerberos environment the keytab *is* the core identity keys for an application. If it's encrypted, then you need some other unencrypted keys that *really* represent the application, at which point why not use those keys for Kerberos directly? That said, if you had a private key in a TPM or some other sort of tamper-resistent hardware, I could see wanting to hand out Kerberos keytabs encrypted to the public key of the server. But you'd have to build the service to do key issuance that way yourself. (It wouldn't be horribly hard to build if you'd already done the work to build out the PKI and its TPM component.) But, even in that case, it's not clear to me what the keytab is then doing for you versus just using the PKI and using PKINIT to get Kerberos tickets. There are probably some practical uses for introducing the extra layer of complexity, but it's not obviously necessary. -- Russ Allbery (ea...@eyrie.org) <http://www.eyrie.org/~eagle/> Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: Fwd: Testing 3 Kerberos realms from same server
"David A. Kovacic" writes: > Unfortunately we are not using kadmin and do not have the ability to set > the "-r" flag in this case. We are trying to create test programs in > perl and python that test the KDC functionality so that when we upgrade > we can test development, test, and production servers all from the same > machine rather than having to log in to each admin server for each realm > to run our test program. > The perl programs use Authen::Krb5::Admin and the python program uses > python-kadmin to try the tests - both of which use the Kerberos > libraries to implement the "init with keytab" routine to produce an > admin object with which we can manipulate principals, policies, etc. For Perl, create an Authen::Krb5::Config object, set realm, and pass it into your other kadmin operations as the $krb5_config parameter. See the Authen::Krb5::Config documentation. I assume python-kadmin has some similar mechanism. > The keytabs have the appropriate services and hosts defined in them and > we are using a connection "client" in both the perl and python instances > of > /@ (eg: > "my-admin@myh...@myrealm.example.com") > and the keytab which is correctly defined in the krb5.conf file. We are > pretty sure the keytab and krb5.conf file are correct since we get the > proper admin object when the default realm and the test realm are the > same. You have to explicitly set the realm in your authentication call if it doesn't match the default realm. There's no way that Kerberos can figure this out from the keytab since cross-realm authentication is valid in Kerberos, so you may well want to be using a key from one realm to authenticate to a different realm. -- Russ Allbery (ea...@eyrie.org) <http://www.eyrie.org/~eagle/> Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
krb5-strength 3.1 released
I'm pleased to announce release 3.1 of krb5-strength. krb5-strength provides a password quality plugin for the MIT Kerberos KDC (specifically the kadmind server) and Heimdal KDC, an external password quality program for use with Heimdal, and a per-principal password history implementation for Heimdal. Passwords can be tested with CrackLib, checked against a CDB or SQLite database of known weak passwords with some transformations, checked for length, checked for non-printable or non-ASCII characters that may be difficult to enter reproducibly, required to contain particular character classes, or any combination of these tests. Changes from previous release: A new configuration option, cracklib_maxlen, can be set to skip CrackLib checks of passwords longer than that length. The CrackLib rules were designed in a world in which most passwords were four to eight characters long and tend to spuriously reject longer passwords. SQLite dictionaries work better for checking longer passwords and passphrases. Patch from Jorj Bauer. The require_classes configuration option can now require a particular number of character classes in the password (whatever those classes are). Patch from Toby Blake. Change the error messages returned for passwords that fail strength checking to start with a capital letter. This appears to be more consistent with the error message conventions used inside Heimdal. Change the DB_File::Lock calling method in heimdal-history to work properly with the (buggy) CPAN version of DB_File::Lock, instead of relying on Debian's patched version. Thanks to Bernt Jernberg for the report. Apply the SuSE patch for a buffer overflow when using duplicate rules to the embedded CrackLib. No duplicating rules are used in the rule set included with this package, and this package doesn't expose the general API, so this was not exploitable, but best to close the latent issue. (The other recent CrackLib vulnerability, CVE-2016-6318, doesn't apply since all the GECOS manipulation code was removed from the embedded CrackLib in this package.) Patch the mkdict and packer in the embedded copy of CrackLib to force C locale when sorting (avoiding a corrupted dictionary) and warn and skip out-of-order words rather than creating a corrupted dictionary. Patch from Mark Sirota. Configuration instrutions are now in the heimdal-history and heimdal-strength man pages and a new krb5-strength man page (which documents configuration of the KDC plugin) instead of the README file to make it more accessible after the software has been installed. Update to rra-c-util 6.2: * Use calloc in preference to malloc wherever appropriate. * Use reallocarray in preference to realloc wherever appropriate. * Suppress warnings from Kerberos headers under make warnings. * Support the embedded Kerberos in Solaris 10 in library probes. * Add missing va_end in xasprintf implementation. * Fix logic in Test::RRA::Automake for new Automake dist checking. * Fix all return-value checks for snprintf to avoid off-by-one error. * Update warning flags for make warnings to GCC 6.1.0. * Fix Test::RRA::Config for new "do" semantics in Perl 5.22.2. * Add a new test for obsolete eyrie.org URLs. * Require Test::Strict 0.25 or newer for Perl strictness checks. Update to C TAP Harness 4.1: * Replace all remaining uses of sprintf. * Test lists may now have comments and blank lines. * runtests -v will show the complete output from a test. * Fix segfault in runtests when given an empty test list. * Tests use C_TAP_SOURCE and C_TAP_BUILD instead of SOURCE and BUILD. You can download it from: <http://www.eyrie.org/~eagle/software/krb5-strength/> This package is maintained using Git; see the instructions on the above page to access the Git repository. Debian packages have been uploaded to Debian unstable. Please let me know of any problems or feature requests not already listed in the TODO file. -- Russ Allbery (ea...@eyrie.org) <http://www.eyrie.org/~eagle/> Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: remctl 3.13 released
Rick van Rein writes: > Hi Russ (and remctl users), > You are probably aware of overviewing management tools like Ansible, > Puppet and NixOps. I wonder how remctl relates to those. Are you (or > other users) aware of anyone combining them? They're a little orthogonal, although maybe more to Puppet than to Ansible. remctl is, formally speaking, an authenticated RPC system like gRPC or the like, just a very, very simple one that doesn't require that you learn protobufs, language bindings, or all the other machinery of a full RPC system. (But which, in turn, doesn't have schemas, typing, or structured arguments.) You can use such a thing as part of a configuration management system, or the config management system can roll its own (which is kind of what Puppet did, although not in a straightforward way that exposes the underlying RPC system). You could use remctl as a transport for a config management system, but the normal nature of config management is such that you probably want the full power of executing arbitrary commands, which is somewhat the opposite of what remctl was designed to do. (IIRC, Ansible mostly uses ssh to push stuff around.) -- Russ Allbery (ea...@eyrie.org) <http://www.eyrie.org/~eagle/> Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
remctl 3.13 released
I'm pleased to announce release 3.13 of remctl. remctl is a client/server application that supports remote execution of specific commands, using Kerberos GSS-API for authentication. Authorization is controlled by a configuration file and ACL files and can be set separately for each command, unlike with rsh. remctl is like a Kerberos-authenticated simple CGI server, or a combination of Kerberos rsh and sudo without most of the features and complexity of either. Changes from previous release: remctl-shell now also supports being run as a forced command from authorized_keys (or other methods). This may be preferrable to using it as a shell since it doesn't require setting non-standard sshd options. The summary configuration option is now allowed for commands with subcommands other than ALL. When generating a help summary (done in response to the command "help" with no arguments), command lines with a subcommand and a summary option will be run with two arguments: the value of the summary option and then the subcommand. This allows proper generation of command summaries even for users who only have access to a few subcommands of a command. Patch from Remi Ferrand. The build system now supports new REMCTL_PROGRAM_CFLAGS and REMCTL_PROGRAM_LDFLAGS variables that can be set at build time to pass in additional arguments when compiling and linking programs (like remctl and remctld) but not libraries and, more importantly, language bindings. This can be used in distribution builds to pass in -fPIE for additional binary hardening. (CFLAGS and LDFLAGS cannot be used since -fPIE breaks the builds of the dynamic modules for langauges like Perl.) Update to rra-c-util 6.1: * Correct return-value checks for snprintf. * Adjust Test::RRA::Config for new load path behavior in Perl 5.22.2. You can download it from: <http://www.eyrie.org/~eagle/software/remctl/> This package is maintained using Git; see the instructions on the above page to access the Git repository. Debian packages have been uploaded to Debian unstable. Please let me know of any problems or feature requests not already listed in the TODO file. -- Russ Allbery (ea...@eyrie.org) <http://www.eyrie.org/~eagle/> Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: KEYRING:persistent and ssh
tseegerkrb writes: > Thanks for your help. Is my setup so special (kerberos/OpenLDAP/sssd/sshd) > nobody using it? I think i will ask debian/ubuntu or the openssh > maintainer for help. It's sadly quite unusual to use non-FILE ticket caches. I wish it weren't, since KEYRING has nice security properties, but it's relatively new and the rest of the world has definitely not adapted yet. -- Russ Allbery (ea...@eyrie.org) <http://www.eyrie.org/~eagle/> Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: KEYRING:persistent and ssh
tseegerkrb writes: > I think the sshd daemon do not honor the "default_ccache_name" and uses > the default file format. I'm pretty sure you're correct if you're doing GSS-API authentication with ssh. Looking at the source code to sshd, you don't seem to get much choice in the matter: # ifdef HAVE_KRB5_CC_NEW_UNIQUE problem = krb5_cc_new_unique(authctxt->krb5_ctx, krb5_fcc_ops.prefix, NULL, &authctxt->krb5_fwd_ccache); # else problem = krb5_cc_gen_new(authctxt->krb5_ctx, &krb5_fcc_ops, &authctxt->krb5_fwd_ccache); # endif [...] authctxt->krb5_ticket_file = (char *)krb5_cc_get_name(authctxt->krb5_ctx, authctxt->krb5_fwd_ccache); len = strlen(authctxt->krb5_ticket_file) + 6; authctxt->krb5_ccname = xmalloc(len); #ifdef USE_CCAPI snprintf(authctxt->krb5_ccname, len, "API:%s", authctxt->krb5_ticket_file); #else snprintf(authctxt->krb5_ccname, len, "FILE:%s", authctxt->krb5_ticket_file); #endif You'd need to write a PAM module that read in that ticket cache file and wrote it back out to your preferred ticket cache format and then adjusted KRB5CCNAME in the user's environment. Unfortunately, there doesn't appear to be any way of preventing the ticket cache from being temporarily written to /tmp. -- Russ Allbery (ea...@eyrie.org) <http://www.eyrie.org/~eagle/> Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: Kerberos and HTTP / HTTPS - Could Kerberos tickets be intercepted and misused?
Simo Sorce writes: > By default MIT's GSSAPI (and Heimdal's if I recall) enables the replay > cache, but some modules (notoriously mod_auth_kerb) just disable it. It's very challenging to use the replay cache with mod_auth_kerb and a typical web application and security configuration, since it redoes an authentication on every page fetch and therefore generates a ton of Kerberos authentication requests in a very small timeframe. Historically, this has caused replay cache collisions, which is why the replay cache is always turned off, since otherwise most protected web sites became inaccessible due to all the replay cache rejections. I think modern replay caches may no longer have this collision issue? -- Russ Allbery (ea...@eyrie.org) <http://www.eyrie.org/~eagle/> Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
remctl 3.12 released
I'm pleased to announce release 3.12 of remctl. remctl is a client/server application that supports remote execution of specific commands, using Kerberos GSS-API for authentication. Authorization is controlled by a configuration file and ACL files and can be set separately for each command, unlike with rsh. remctl is like a Kerberos-authenticated simple CGI server, or a combination of Kerberos rsh and sudo without most of the features and complexity of either. Changes from previous release: Add a new server implementation, remctl-shell. This does not use the remctl protocol; instead, it is meant to be run via ssh by being configured as the shell of a dedicated user. It interprets a command it was given as a remctl command, using the same configuration and authorization checking as the normal remctl server. This can be useful to introduce remctl into an environment that has ssh public key authentication instead of Kerberos. remctl-shell has some significant limitations inherited from ssh and requires some setup to use. See its manual page for more information. Add a new configuration option, sudo, which tells remctld and remctl-shell to run the command as a different user using sudo. The path to the sudo binary is determined when remctld is compiled. Normally, it's more convenient to use the existing user option, but it relies on remctld running as root. If running the daemon as a non-root user, or when running remctl-shell as a non-root user, this option may work better. Note that remctl-shell is currently a bit of a science experiment, and there are some remaining things I want to tweak about it, so its behavior may change a bit in a subsequent release. But I figured I'd put it out there for people to play with. You can download it from: <http://www.eyrie.org/~eagle/software/remctl/> This package is maintained using Git; see the instructions on the above page to access the Git repository. Debian packages have been uploaded to Debian unstable. Please let me know of any problems or feature requests not already listed in the TODO file. -- Russ Allbery (ea...@eyrie.org) <http://www.eyrie.org/~eagle/> Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
remctl 3.11 released
I'm pleased to announce release 3.11 of remctl. remctl is a client/server application that supports remote execution of specific commands, using Kerberos GSS-API for authentication. Authorization is controlled by a configuration file and ACL files and can be set separately for each command, unlike with rsh. remctl is like a Kerberos-authenticated simple CGI server, or a combination of Kerberos rsh and sudo without most of the features and complexity of either. Changes from previous release: The PHP bindings have been ported to PHP 7, based on work by Nish Aravamudan. The PHP 7 API is sufficiently different that this was done by forking the PHP code and creating a new version for PHP 7 and later, chosing which extension to compile based on the discovered version of PHP. Currently, there is no functionality difference, but the PHP 5 extension should be considered frozen and may not get any new features. It will eventually be removed in a future version of remctl when PHP 7 is sufficiently widespread. Rename the script to bootstrap from a Git checkout to bootstrap, matching the emerging consensus in the Autoconf world. Fix numerous portability issues to various versions of Heimdal, thanks to multiple patches from Jeffrey Hutzelman. Multiple fixes and improvements to the RPM spec file from Jeffrey Hutzelman: systemd support, SLES support, add the missing libevent-devel dependency, fix the version, and fix an invalid date. Update to rra-c-util 6.0: * Remove all remaining uses of strlcpy and strlcat. * Fix the Perl docs/synopsis.t test to be less UNIX-specific. * Make util/network/server-t more robust against missing IPv6. Update to C TAP Harness 4.0: * Use C_TAP_SOURCE and C_TAP_BUILD instead of SOURCE and BUILD. You can download it from: <http://www.eyrie.org/~eagle/software/remctl/> This package is maintained using Git; see the instructions on the above page to access the Git repository. Debian packages have been uploaded to Debian unstable. Please let me know of any problems or feature requests not already listed in the TODO file. -- Russ Allbery (ea...@eyrie.org) <http://www.eyrie.org/~eagle/> Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: Kerberos trust
Mauro Cazzari writes: > I'm relatively new to Kerberos, so please forgive me if my question > might sound dumb. > I'm trying to access a secured Hadoop environment from a Windows > machine. The Hadoop cluster uses its own realm. I installed MIT > Kerberos on the Windows box and configured it so that I can successfully > obtain tickets, but I'd like to see if there is a way to instead use the > tickets that are generated through AD when I log on to Windows. My > understanding is that a one-way trust between the AD and the cluster's > KDC could solve the issue. What's not clear is whether I need to define > anything at all at the AD level. I'm thinking that since I'm trying to > gain access to the realm associated with the Hadoop cluster, all I need > to do is to add a principal to it for the AD realm, the one I want to > trust. After that, I would change the krb5.conf file to make sure the AD > realm is seen. Even one-way trust requires making changes to both KDCs, since for any type of trust you need to have a shared key between AD and the remote KDC. The only difference between one-way trust and two-way trust is that you have only one shared key instead of two shared keys. In theory, one-way trust where you have a krbtgt/@ principal in both KDCs should be sufficient. In practice, I have run into no end of weird trouble with one-way trust, and strongly prefer to set up two-way trust whenever I set up cross-realm trust just to avoid having my head hurt later. Note that you'll also have to configure the Windows side to know to do cross-realm to the Hadoop realm when accessing those resources. There are probably ways to do this with local configuration, but I think domain_realm mappings on Windows are usually also done with AD configuration. (Disclaimer: I've never done the AD side of this setup myself.) -- Russ Allbery (ea...@eyrie.org) <http://www.eyrie.org/~eagle/> Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: Kerberos API - enhancing program to *force* authentication
Matt Garman writes: > Since sending that I basically did exactly what you suggest, more or > less copying the krb5_init source, but stripping out any cache-related > stuff. I also request a very short-lived ticket life (30s). So far > seems pretty straightforward! Yup, that will work. Note that you're probably skipping krb5_verify_creds, so an attacker that can spoof the KDC on the network can bypass this check, but given the other issues with this security measure, it may not be worth worrying about that. I would recommend considering using PAM to do the authentication instead of hard-coding a Kerberos authentication, since that gives you some more flexibility to, say, plug in a 2FA authentication mechanism instead later on. I think you'd actually get more security from requiring a Yubikey tap to reattach than you're getting from asking for the Kerberos password, and PAM makes it much easier to swap that stuff around. > Oh we violate this on a regular basis! Our Linux environment is all > rackmount servers in a remote facility, and none have keyboards attached > (except in special maintenance situations). But all access is through > ssh, so I believe Kerberos keys (or anything sensitive for that matter) > should never pass through the network un-encrypted. Yeah, it's common. The theoretical risk is that it means a compromise of any server means a compromise of all user accounts that have authenticated on that server since the compromise, which allows lateral movement. If the attacker steals credential caches, they can do that to some extent anyway, but limited by the ticket lifetime. With the long-term keys, the threat is more persistent. The basic idea is that there's really no security system that can get out of having to trust the physical system at which someone is sitting, but you can limit your exposure to lateral movement just to those systems (at least within the lifetime of the ticket cache) by not letting the long-term keys leave those systems. In practice, it's very hard to hold to this, and a more common approach these days is to add a second factor instead, since intercepting someone's second factor via a compromised server doesn't actually help the attacker. > Not currently, but now that you mention it, it's probably time I sit > down and learn it (SELinux that is). To be honest, I've always been > scared of it. It's kind of scary. :) > But: if a root user can drop in a fake binary, can't he also twiddle > the SELinux policy as well? (Exposing my gross ignorance of SELinux > here.) Changing MAC security policies usually requires a reboot, and can be set up to require some other special access (physical console, booting into a rescue environment, etc.). That makes it very hard for an attacker to do that without being detected. > On the other hand, our environment is such that it would be fairly hard > to actually produce a non-desired binary, as Internet access is > basically non-existent, and the vanilla source (tmux or other program) > would be secured in a inaccessible vault. If an attacker can possibly ssh into a system, they can probably get their own tmux binary onto that system. They just cat it over the ssh connection. :) Attackers don't need outbound Internet access. Usually the attacker has to compromise your VPN in some way first, of course, but you're clearly already worrying about attackers who have gotten that far in or you wouldn't bother securing server-side tmux sessions. It's pretty hard to prevent an attacker from bringing in their own binaries without making it impossible for people to do their work. > We acknowledge that there will likely always be holes, just trying to > plug the known ones and set up as many safeguards as possible. Yeah, I'm just not sure this safeguard is that meaningful. But it does depend on your threat model. It's pretty good against a local admin who decides to casually snoop on things but won't be bothered to upload a new tmux binary, since a bit of obscurity will be enough to deter that sort of attacker. It's probably useless against an APT attacker. -- Russ Allbery (ea...@eyrie.org) <http://www.eyrie.org/~eagle/> Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: Kerberos API - enhancing program to *force* authentication
Matt Garman writes: > - Will forcing the retrieval of a new ticket interfere in any way > with the user's current credentials (or his credentials cache)? The > main reason we currently have Kerberos implemented is for Kerberized > NFSv4 home directories (i.e. sec=krb5p NFS mount option). So as I > suggested above, the user will already have valid Kerberos ticket and > credentials cache (otherwise they'll be "permission denied" out of > their own home dir). I don't want to interfere with those, just > authenticate that the person using this program is really who he says > he is. You'll want to either perform just the authentication calls without saving the resulting cache or use a separate cache (by setting KRB5CCNAME to override the default cache, only for this interaction). > - I'm just getting started with familiarizing myself with the > Kerberos API, but already I see that's a fairly low-level way to > achieve my goal. I.e., some of my reading suggests using GSS-API, > SASL+TSL, etc might be a more "generic" approach... any thoughts on > this, given my use case? You probably want to just call krb5_get_init_creds_password. Preferrably you would do this via PAM rather than doing any direct Kerberos integration yourself, and just use the system PAM Kerberos module. Note that this requires the user to enter their password into your application, so ideally from a Kerberos perspective this application would only run on their local system (the one physically attached to the keyboard they're typing into). Anything else is a (partial) weakening of the Kerberos security model, since the long-term user keys should never leave the local system. But practical deployments of Kerberos do tend to violate this all the time, so > Lastly, FWIW, the program we want to integrate with Kerberos is tmux > (same concept as GNU Screen). tmux allows terminals to be "detached" > and "reattached" (e.g. detach, go home, login remotely, attach to get > your exact same terminal(s) back). What we want is to force a Kerberos > authentication whenever an "attach" is attempted. This is to prevent > admins (i.e. root user) from su'ing to that user, then attaching to his > console (and why we don't want to use existing credentials, but force > password entry). I assume you're using SELinux or some other MAC system to significantly restrict the capabilities of root? Otherwise, root users can just replace your tmux binary with their own that doesn't have this check and bypass all of your checks, so this is, from a security standpoint, kind of pointless. It's just security via obscurity. If you are using SELinux, it might be easier to just not give root access to the tmux sockets. -- Russ Allbery (ea...@eyrie.org) <http://www.eyrie.org/~eagle/> Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: kprop with multiple or NATted IP address
Jerry Shipman writes: > (I thought about that about 5 minutes after I sent the email — oops.) > I guess my question is: does kprop do anything other than: secrecy of > the data in transmission, integrity of the transmission, kdb5_util > dump/load ? Or can I really do the same thing in a cron job (or maybe 2, > one on each end) without missing anything important? I guess I would > lose out on the possibility of doing incremental propagation. You lose incremental propagation, but other than that, I'm pretty sure kprop/kpropd is just an authenticated copy of a dump and loading it on the other end. -- Russ Allbery (ea...@eyrie.org) <http://www.eyrie.org/~eagle/> Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: kprop with multiple or NATted IP address
Jerry Shipman writes: > It’s me again, who was trying to kprop through a NAT a month ago. > Hypothetically speaking… how bad of an idea would it be to make a cron > job that `scp`s the database file to the slave KDC, or something like > that? Does the slave KDC daemon need to restart after the file is > updated, maybe? Or is this significantly less safe than using kprop? I > think I would be relying on ssh instead of kerberos for the > confidentiality and integrity. But I do that whenever I log into the > machine anyway. I think I may risk getting the file in the middle of a > write (so some records could be corrupted in the copy). It seems like > this would be a bad idea; just checking. If you're going to use scp, I strongly recommend generating a dump with kdb5_util dump, scping that, and then loading it with kdb5_util load. That's effectively what kprop/kpropd do. Just copying the database file runs the risk of copying a corrupt database because you happened to catch it in the middle of a write, as you note. -- Russ Allbery (ea...@eyrie.org) <http://www.eyrie.org/~eagle/> Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
wallet 1.3 released
Clang (currently not warning clean). Update to C TAP Harness 3.4: * Fix segfault in runtests with an empty test list. * Display verbose test results with -v or C_TAP_VERBOSE. * Test infrastructure builds cleanly with Clang warnings. * Support comments and blank lines in test lists. You can download it from: <http://www.eyrie.org/~eagle/software/wallet/> This package is maintained using Git; see the instructions on the above page to access the Git repository. Please let me know of any problems or feature requests not already listed in the TODO file. -- Russ Allbery (ea...@eyrie.org) <http://www.eyrie.org/~eagle/> Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
kstart 4.2 released
ll libtap.sh library. * Silence __attribute__ warnings on more compilers. * runtests now frees all allocated resources on exit. You can download it from: <http://www.eyrie.org/~eagle/software/kstart/> This package is maintained using Git; see the instructions on the above page to access the Git repository. Debian packages have been uploaded to Debian unstable. Please let me know of any problems or feature requests not already listed in the TODO file. -- Russ Allbery (ea...@eyrie.org) <http://www.eyrie.org/~eagle/> Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
remctl 3.10 released
I'm pleased to announce release 3.10 of remctl. remctl is a client/server application that supports remote execution of specific commands, using Kerberos GSS-API for authentication. Authorization is controlled by a configuration file and ACL files and can be set separately for each command, unlike with rsh. remctl is like a Kerberos-authenticated simple CGI server, or a combination of Kerberos rsh and sudo without most of the features and complexity of either. Changes from previous release: Two new remctld ACLs are supported: anyuser:auth and anyuser:anonymous. The first is equivalent to ANYUSER, and indeed ANYUSER is now treated as a backwards-compatibility alias for anyuser:auth. This permits any authenticated user in either the local realm or any realm with which there is cross-realm trust. The new anyuser:anonymous ACL permits absolutely any user, even unauthenticated users, allowing anyone with network access to the server to run the command. (Note, however, that actually running commands anonymously requires anonymous PKINIT and anonymous service tickets be enabled for the local Kerberos realm. These are not common configurations, particularly the second.) The remctld server now sets the REMOTE_EXPIRES environment variable to the time (in seconds since UNIX epoch) when the authenticated session used to run a command will expire. This will generally be the expiration time of the Kerberos ticket used to authenticate to the server. Anonymous authentication (such as via anonymous PKINIT) no longer satisfies ANYUSER ACLs. It's unlikely that existing installations would have encountered anonymous authentication, since obtaining service tickets with anonymous PKINIT is disabled by default. Simplify the Python RemctlError exception class. The code in the exception class just duplicated the behavior of the parent Exception class and was unnecessary, and it interfered with pickling the exception. This means that RemctlError exceptions, and any derived from RemctlError, will no longer have a value attribute. To get this information, use the string value of the exception object, or call the error() method on the remctl object. Thanks to Andrew Deason for the report. Previous versions always passed the flags to disable certain warnings to the language binding builds, even if warnings weren't otherwise enabled. As of remctl 3.9, that included a warning flag not supported by old versions of gcc, breaking builds on RHEL 5. Instead, only pass the warning suppression flags when building with warnings (via make warnings), which is not the default and is only supported with recent versions of gcc. Thanks to Ken Dreyer for the report. For the localgroup ACL scheme, dynamically resize the buffer passed to getgrnam_r if the call fails due to ERANGE. Users in large numbers of local groups may require more space than the buffer size returned by the sysconf call. Patch from Hugh Cole-Baker. Fix test suite portability to systems with older versions of Kerberos that didn't have krb5_get_init_creds_opt_alloc, such as the included Kerberos in Solaris 10. Update to rra-c-util 5.8: * Add missing va_end to xasprintf implementation. * Fix Perl test suite framework for new Automake relative paths. * Avoid $() in the probe for systemd support for Solaris portability. * Prefer libsystemd to libsystemd-daemon if it is available. * Improve portability to Kerberos included in Solaris 10. * Use appropriate warning flags with Clang (currently not warning clean). * Check for integer overflow in vector_join. * Avoid strlcpy in more of the portability code. * Fix hidden visibility of some utility functions. * Improve portability of socket error codes to Windows. Update to C TAP Harness 3.4: * Fix segfault in runtests with an empty test list. * Display verbose test results with -v or C_TAP_VERBOSE. * Support comments and blank lines in test lists. You can download it from: <http://www.eyrie.org/~eagle/software/remctl/> This package is maintained using Git; see the instructions on the above page to access the Git repository. Debian packages have been uploaded to Debian unstable. Please let me know of any problems or feature requests not already listed in the TODO file. -- Russ Allbery (ea...@eyrie.org) <http://www.eyrie.org/~eagle/> Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: daily latency spike
"Paul B. Henson" writes: > We currently have two kerberos realms, each consisting of three systems > (1 physical box and 2 virtual machines). For a while now we've been > having an issue where once a day, almost exactly every 24 hours, the two > physical boxes have a latency spike and don't respond to authentication > requests, to the point where our monitoring systems alarms that they're > down. Interestingly, this daily outage seems to happen every 24 hours > based on when the services were last restarted. > We see a small spike on io requests that seems to correspond with the > delayed authentication processing. The two vm's in each realm also see > similar spikes, but the SAN they are on has loads of iops and they don't > seem to have an issue continuing to respond to requests during the > spike. > We're using openldap with the ldap backend. I assume you've already looked for daily cron jobs? It's common for LDAP servers to take a nightly LDIF dump for backups, for example, which would cause symptoms like this. -- Russ Allbery (ea...@eyrie.org) <http://www.eyrie.org/~eagle/> Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: Kerberos, Windows and FreeIPA
Randolph Morgan writes: > We are running a mixed environment network. However, all of our > authentication is performed via LDAP, we do not have an AD on our > network, nor do we have any Windows servers, all of our servers are > running RHEL. We are working on implementing a new authentication > server that is running FreeIPA, but would like to do single sign-on via > Kerberos. I have been reading posts for the better part of two weeks > and can not find instructions that work, on how to get Windows (XP - 10) > to authenticate via Kerberos. There used to be various workarounds that would let you do this, but when we asked Microsoft about it, they said it was officially unsupported and very likely to break. I think subsequent releases of Windows may have broken it. I believe the only supported way to get a Windows system to use Kerberos for its integrated login is to join the host to a domain (whether AD or Samba). You can, of course, run Kerberos software on unjoined Windows hosts, get tickets, and authenticate to Kerberos services without any trouble. The problems arise when you want the core OS stuff to use Kerberos directly, since I believe all of that is effectively gated on being domain-joined. -- Russ Allbery (ea...@eyrie.org) <http://www.eyrie.org/~eagle/> Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: syncing MIT Kerberos to Active Directory
Tony Pugielli writes: > Good day, I have an environment with MIT Kerberos and Active > Directory. Is there a way to keep both databases (username and password) > in sync? The use case is 802.1x authentication. EAP-GTC is not native to > many devices so we want to use Active Directory so we can take advantage > of the more widely native supplicant PEAP-MSCHAPV2. We would prefer the > user only need to keep track of one username and password. Right now the > Kerberos MIT database is widely used for their single sign-on > applications. You may find: http://www.eyrie.org/~eagle/software/krb5-sync useful, although it only does passwords. I believe there is a krb5-adsync package somewhere based on that which also creates accounts. -- Russ Allbery (ea...@eyrie.org) <http://www.eyrie.org/~eagle/> Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: Cannot create cert chain: certificate signature failure
Thanks for the reply!
Greg Hudson writes:
> On 09/05/2015 01:57 AM, Russ Allbery wrote:
>> Sep 4 22:48:34 mithrandir krb5kdc[12868]: AS_REQ (6 etypes {18 17 16 23 25
>> 26}) 127.0.0.1: KDC_RETURN_PADATA: WELLKNOWN/anonym...@eyrie.org for
>> krbtgt/eyrie@eyrie.org, Cannot create cert chain: certificate signature
>> failure
>>
>> Any idea what's going on? This appears to be some failure inside OpenSSL,
>> but it looks like absolutely no information about the error is actually
>> logged anywhere?
> We're logging what OpenSSL gives us from X509_verify_cert_error_string()
> after X509_verify_cert() fails. We could be doing more;
> X509_STORE_CTX_get_error_depth() would give us the depth where the error
> occured in the cert chain and X509_STORE_CTX_get_current_cert() would
> give us the cert that caused the failure. In this case, I think you
> would merely find out that the error occurred verifying the leaf
> certificate against the CA's public key.
This is anonymous PKINIT, though... I'm not sure what leaf certificate is
in play. The KDC's itself? So the problem here is that attempting to
return the chain of the KDC cert and the signing cert is failing? I guess
I'm confused about what operation is failing.
> Looking inside OpenSSL, this error (X509_V_ERR_CERT_SIGNATURE_FAILURE)
> is generated when X509_verify() fails inside internal_verify(). It does
> look like X509_verify() (or rather ASN1_verify()) does something with
> the OpenSSL framework to indicate what kind of error happened, but I am
> not sure how our PKINIT code is supposed to pull that information out.
> The man page for X509_verify_cert() only mentions
> X509_STORE_CTX_get_error().
Yeah, sorry, that sounded way more critical than I'd actually intended. I
know it's really hard to get useful information out of OpenSSL sometimes
when operations fail.
BTW, is there a way to get the equivalent of KRB5_TRACE out of a KDC? It
looks like it normally turns this off (or at least I wasn't seeing much
when running a KDC with that set).
> It doesn't seem like the client version should have anything to do with
> this failure, so I have no theories as to what changed.
Yeah, it's really weird to me too. The client in anonymous PKINIT isn't
doing much.
I confirmed that it does work with certs created directly with OpenSSL, so
I'll go down that path and regenerate the CA and certificates for that
realm.
BTW, a slightly different question: what's the correct way to detect, in a
GSS-API application, that the client has authenticated anonymously? I see
that GSS_C_NT_ANONYMOUS exists (the project wiki mentions it without the
_C), but I'm not entirely sure how to use it. It looks like the naive
approach of calling gss_display_name returns the string version of the
anonymous principal, so I could do a krb5_parse_name and then do a
krb5_principal_compare, but that feels inelegant and like a layering
violation.
--
Russ Allbery (ea...@eyrie.org) <http://www.eyrie.org/~eagle/>
Kerberos mailing list Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos
Re: Cannot create cert chain: certificate signature failure
Russ Allbery writes:
> I had working PKINIT in my test MIT Kerberos realm using certificates
> issued by Heimdal, but now all attempts to authenticate with PKINIT are
> just failing with the following error in the KDC syslog:
> Sep 4 22:48:34 mithrandir krb5kdc[12868]: AS_REQ (6 etypes {18 17 16 23 25
> 26}) 127.0.0.1: KDC_RETURN_PADATA: WELLKNOWN/anonym...@eyrie.org for
> krbtgt/eyrie@eyrie.org, Cannot create cert chain: certificate signature
> failure
> Any idea what's going on? This appears to be some failure inside OpenSSL,
> but it looks like absolutely no information about the error is actually
> logged anywhere?
> The key piece of information is probably that the certificates (CA, KDC,
> and client) were created with Heimdal hxtool.
> I was previously successful issuing certs with OpenSSL directly and the
> configuration from the wiki, but I'd really rather use hxtool, which is
> a much nicer interface. And I'm not sure why it wouldn't work,
> particularly since it was previously working just fine (with the same
> server software version, although an older MIT Kerberos client version).
I should have added:
Client: MIT Kerberos 1.13.2
Server: Tried both MIT Kerberos 1.10.1 and 1.13.2
With 1.10.1, I got the infamous "Cannot allocate memory" error with
PKINIT, but got the "certificate signature failure" error when trying to
use a client certificate.
--
Russ Allbery (ea...@eyrie.org) <http://www.eyrie.org/~eagle/>
Kerberos mailing list Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos
Cannot create cert chain: certificate signature failure
Hi all,
I had working PKINIT in my test MIT Kerberos realm using certificates
issued by Heimdal, but now all attempts to authenticate with PKINIT are
just failing with the following error in the KDC syslog:
Sep 4 22:48:34 mithrandir krb5kdc[12868]: AS_REQ (6 etypes {18 17 16 23 25
26}) 127.0.0.1: KDC_RETURN_PADATA: WELLKNOWN/anonym...@eyrie.org for
krbtgt/eyrie@eyrie.org, Cannot create cert chain: certificate signature
failure
Any idea what's going on? This appears to be some failure inside OpenSSL,
but it looks like absolutely no information about the error is actually
logged anywhere?
The key piece of information is probably that the certificates (CA, KDC,
and client) were created with Heimdal hxtool.
I was previously successful issuing certs with OpenSSL directly and the
configuration from the wiki, but I'd really rather use hxtool, which is a
much nicer interface. And I'm not sure why it wouldn't work, particularly
since it was previously working just fine (with the same server software
version, although an older MIT Kerberos client version).
--
Russ Allbery (ea...@eyrie.org) <http://www.eyrie.org/~eagle/>
Kerberos mailing list Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos
Re: Fwd: Queries for Kerb Auth using Certificates and KCD for linux Reverse Proxy
Amit Thukral writes: > I am trying to implement kerberos authentication between clients and > windows KDC using certificates. > The product on which this needs to be implemented is a linux based > reverse proxy. > We have already integrated a MIT Kerberos libraries with it and are able > to authenticate clients with Windows KDC. i.e. we are able to get TGT > on behalf the client (by setting forwardable flag for AS Req), pass it > back to the browser (client) and thus client authenticates using that > ticket with servers protected behind our product. But for this as, as > of now, when a user trying to access a service protected behind our > product, we prompt him with login form where he enters his credentials, > using which we call krb5_get_init_creds_password api to send AS REQ and > get TGT. > Now, we want to achieve this using certificates. If I'm understanding your problem description correctly, I'm not sure this is possible. To get Kerberos tickets from a certificate (aka PKINIT), the client that has access to the certificate private key needs to do this directly. An intermediate cannot do this, since it doesn't have access to the certificate private key. So if you're trying to get the Linux reverse proxy to do the authentication on behalf of the user, that isn't going to work. Anyway, assuming I'm wrong and you're actually doing the authentication in the client, the short version is that you should call these two functions: krb5_get_init_creds_opt_set_pa(c, opts, "X509_user_identity", user); krb5_get_init_creds_opt_set_pa(c, opts, "X509_anchors", anchors); with an appropriate value for X509_user_identity and X509_pkinit_anchors, respectively, and then do your krb5_get_init_creds_password call as normal with a NULL password. If the KDC offers PKINIT, the Kerberos libraries should try PKINIT with the identity and anchors configured there. -- Russ Allbery (ea...@eyrie.org) <http://www.eyrie.org/~eagle/> Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
