Neither of these parameters has anything to do with the krb5 authentication method, because PostgreSQL removed that method in 9.4. The krb_ prefix survives for the usual reason parameter names survive anything: renaming a GUC breaks every postgresql.conf that mentions it. What they actually configure is GSSAPI authentication, the gss method in pg_hba.conf, which in practice means Kerberos, which in practice usually means Active Directory. (Their siblings were less lucky: krb_server_hostname left in 8.4, and krb_srvname went down with the ship in 9.4.)
Most GSSAPI policy lives in pg_hba.conf, per line: include_realm, krb_realm, map. These two settings are server-wide, which is why they are GUCs at all. Both are context sighup; a reload suffices, no restart.
krb_server_keyfile
This is the location of the server’s keytab, the file holding the keys for the service principal (conventionally postgres/server.fqdn@REALM) that lets the server prove it is the server. The default is FILE: followed by krb5.keytab in whatever sysconfdir was at build time; pg_config --sysconfdir will tell you, and on Debian-family packages the result is FILE:/etc/postgresql-common/krb5.keytab. The FILE: prefix is not decoration. It is Kerberos keytab-name syntax (a type and a residual), passed through to the Kerberos library as-is. Set the parameter to an empty string and PostgreSQL stays out of it entirely; the Kerberos library falls back to its own default, typically the system keytab at /etc/krb5.keytab or whatever KRB5_KTNAME says.
Do not use that fallback. The documentation recommends a dedicated keytab for PostgreSQL rather than the system one, and the reason deserves stating plainly: a keytab is a credential, not configuration. Whoever can read it can be the server. The system keytab holds the host’s own keys and belongs to root; a PostgreSQL server that can read it holds more identity than it needs, and a PostgreSQL compromise that leaks it is now a host compromise. Generate a separate keytab containing only the postgres/... principal, make it readable (and preferably only readable) by the PostgreSQL service account, and point this parameter at it. Since the context is sighup, re-pointing it after a key rotation costs you a reload, not a restart.
krb_caseins_users
Boolean, default off, and the origin story explains it better than the description does. In 2005 Magnus Hagander brought a problem to pgsql-hackers: he logged into his Windows domain as Maghag, his PostgreSQL role was maghag, and Kerberos faithfully delivered the principal with the capital M. Windows treats user names case-insensitively but preserves whatever case the user typed at login; PostgreSQL role matching is exact. The result is authentication that fails or succeeds depending on how the user felt about the shift key that morning. The parameter that came out of the discussion (in 8.1) makes the server match the client principal against the requested role, and against pg_ident.conf user-map entries, without regard to case; krb_realm comparisons go case-insensitive along with it.
The default is off because Tom Lane insisted, and he was right. On an MIT or Heimdal realm, FOO@REALM and foo@REALM can be two different principals; turn this on and PostgreSQL merges them at the door, which is a security hole with a configuration setting for a name. His condition in the thread stands as the complete tuning guide: do not enable it “unless you are certain you are using a case-insensitive KDC.” Active Directory is one. If your realm is AD, turn it on and stop debugging phantom authentication failures; if it is MIT or Heimdal, leave it off and fix the case mismatch in pg_ident.conf instead, where you can see it.
If you use GSSAPI against Active Directory, the configuration is: a dedicated keytab in krb_server_keyfile, krb_caseins_users = on, and everything else in pg_hba.conf, where per-connection policy belongs. (What the server does with credentials the client offers to hand over is gss_accept_delegation, a separate question with a separate post.) If you do not use GSSAPI, these are among the few parameters in this series you can ignore with a completely clear conscience.