Re: one time password integration

[Greg Hudson]

On 7/31/24 14:22, Charles Hedrick via Kerberos wrote:

The comments suggest that with TCP if there isn't an answer within 10 sec, it 
then tries all servers.


This comment is outdated; I missed it when making the behavior changes. 
Starting in release 1.22, once a KDC accepts a connection, the client 
will not initiate communications with other KDCs; it will wait 
indefinitely or until the total request timeout for that KDC (and any 
previously contacted KDCs) to answer.


Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

krb5-1.21.3 is released

[Greg Hudson]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

The MIT Kerberos Team announces the availability of MIT Kerberos 5
Release 1.21.3.  Please see below for a list of some major changes
included, or consult the README file in the source tree for a more
detailed list of significant changes.

Retrieving krb5-1.21.3
==

You may retrieve the krb5-1.21.3 sources from the following URL:

https://kerberos.org/dist/

The homepage for the krb5-1.21.3 release is:

https://web.mit.edu/kerberos/krb5-1.21/

Further information about Kerberos 5 may be found at the following
URL:

https://web.mit.edu/kerberos/


Major changes in 1.21.3 (2024-06-26)


This is a bug fix release.

* Fix vulnerabilities in GSS message token handling [CVE-2024-37370,
  CVE-2024-37371].

* Fix a potential bad pointer free in krb5_cccol_have_contents().

* Fix a memory leak in the macOS ccache type.
-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEExEk8tzn0qJ+YUsvCDLoIV1+Dct8FAmZ8kr4ACgkQDLoIV1+D
ct8cAxAAxtt3wCoPDRubEb2ZcdIdOoNCWOCu7fvXL6vI2fTdv+BXYVfGjpqHq7+r
XNVlKSqMuBLI+vJZtlcY7S0pJSgAqnoQwPd/W/6fZbJxqcCmgs9Zr14T9ODlSBxI
+Lv79dJWCSgt2+5LYTqzIDbomU3Ab5jDPSyfVSUX3t9g+JD4Ndw0Vw3xL+n9y+Ao
LY4PgZeWNW9mhBp6KpnWiln9jdTaJzN/oFmK2usXrmC332B6XQqjDV0c8lgJMwUN
/Zcmbq5ITbaLlpuf5rztbiTrW5Mx92UVMG1IAQleISKADkO/+u6UgU2BhqblL6L7
ynf7T6KrUshf1ZJYj2Xo+sYfvo6Xp/1OJjxHHV4mBbtf2JR9TpT8BmwEHrgbhU9V
NWDZLDAtcxCQ93hKnJiO3BKqioaxpNEs1wSIK1M3fdWcuNf/T/JG/Rq6VaoPIo0w
NtZUloAaL2HV6gOkBWd6ke9oGIOUyCYZD2AhPacfBxfZ9Rs0r5aDHkFzoyLqxqkJ
4XNBOM9Qkw9hLitY9exqg1Csx6PA0gN6x6XhErlEIE5/oC4jgBAtCbdXpDpA3s8u
lui8VrZw8luzwT6UZadrTwCPP/ulF+2kn93OK5hKPl1WXSHvPUmC/0yzm8iZyLKV
U6V/MFjNGTN0vG05BBHhaTlN8I9DuS5a9bnXdjEK7EUWlu3wyKw=
=Gs39
-END PGP SIGNATURE-
___
kerberos-announce mailing list
kerberos-annou...@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos-announce

Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Re: honoring the TRUSTED_FOR_DELEGATION KDC MS-SFU Kerberos Protocol Extensions flag?

[Greg Hudson]

On 4/30/24 12:49, Ken Hornstein via Kerberos wrote:

First off, I would advise you to NOT look at upstream Heimdal, because
that's not helpful because it's not actually the code in question.
Instead maybe look at the actual Heimdal source code used on MacOS X?


To expand on this: the Apple forks of open-source projects are available 
at opensource.apple.com, and at 
https://github.com/apple-oss-distributions (not sure if the latter is 
official or community-maintained).


I looked at the Apple fork of Heimdal and didn't find any obvious code 
change to honor ok-as-delegate by default.  In fact, it doesn't even 
implement enforce_ok_as_delegate.  But both versions do implement a 
ccache config setting called "realm-config" and enforce ok-as-delegate 
if the 1 bit is set in the first byte of the value.  Nothing in Heimdal 
or Apple's fork of it sets realm-config, but the macOS native ccache 
implementation or login system might do so.  James could perhaps this 
test theory by setting KRB5CCNAME to FILE:something, running kinit -f, 
and seeing if ssh will forward those tickets.


Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Re: Force to change password for users

[Greg Hudson]

On 4/19/24 08:06, Carlos Lopez wrote:

[...] AS_REQ [...] REQUIRED PWCHANGE: us...@mydom.org for 
krbtgt/mydom@mydom.org, Password has expired
[...] AS_REQ [...] NEEDED_PREAUTH: us...@mydom.org for 
kadmin/chang...@mydom.org, Additional pre-authentication required
[...] AS_REQ [...] ISSUE: [...] us...@mydom.org for kadmin/chang...@mydom.org

But in the client side, user can login without problems and no password change 
is requested.


These are the messages I would expect in the log, including user1 
getting a ticket to perform a password change.


You say the user can log in.  Do they have tickets, or do you just mean 
a login session is authorized based on the Kerberos interaction?  What 
client-side software is being used?


Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Re: query about a possible "KRB5KEYLOGFILE" feature, to log session keys

[Greg Hudson]

On 3/17/24 23:33, Richard E. Silverman wrote:
I have a patch to libkrb5 which implements a feature similar to the 
SSLKEYLOGFILE environment variable that’s now in pretty wide use for 
TLS: it logs session keys to a keytab named by KRB5KEYLOGFILE. The main 
use for this, just as with the TLS version, is to decrypt packet 
captures with Wireshark; the latter’s KRB5 dissector takes a keytab as 
input.


I think that would be a reasonable feature to add.


Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Re: Stateless PKINIT?

[Greg Hudson]

On 3/15/24 06:15, Yoann Gini wrote:
Informations about the principal (name and everything) could be 
extracted from the certificate. Principal and certificate contains the 
same informations.


To issue a ticket, the KDC doesn't need to know directory-type 
information such as real names, but it does need to know 
Kerberos-specific policy information like "how long can the ticket 
expiration time be".  That information could presumably be standardized 
across clients, which is why I suggested a template principal.


Other option I wonder is using the LDAP backend to answer dynamic 
content (we have an LDAP gateway in our codebase, so we can use it as a 
backend API between MIT Kerberos and our identity store).


Doing so the main issue would be to know what Kerberos need to write, to 
handle it.


The KDC does not need to write to the KDB, although it will attempt to 
do writes to maintain account lockout state (which is irrelevant to the 
configuration at hand).  Attempts to write can be disabled via the 
settings documented here:


https://web.mit.edu/kerberos/krb5-latest/doc/admin/lockout.html#disable-lockout

When synthesizing a client principal entry (or creating a template), be 
sure to include the KRB5_KDB_REQUIRES_PRE_AUTH and KRB5_KDB_DISALLOW_SVR 
principal flags.


Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Re: Stateless PKINIT?

[Greg Hudson]

On 3/14/24 15:27, Ken Hornstein via Kerberos wrote:

Is there a way when using PKINIT to not need any internal list of
principals but to rely on the validity of the certificate to proxy the
certificate identity into the Kerberos ticket?


I know what all of those words are, but I'm unclear what they mean all
together.  I think you mean _this_ step:


I believe Yoann is asking for a KDC configuration where the KDB contains 
server principal entries (including a krbtgt entry) but no client 
principal entries.  PKINIT does not require client long-term keys, and 
other client principal fields (except for the name) could be taken from 
a template entry.


MIT krb5 does not currently have this ability with the built-in KDB 
modules.  It could be done with a custom KDB module, but that module 
would also have to provide all of the regular KDB functionality for the 
server principal entries, and the KDB interface isn't designed to be 
stackable (meaning it isn't trivial to implement an overlay).


Alternatively, I think it would be a relatively simple change to the 
core KDC code to support this: do_as_req.c:lookup_client() could look up 
a template at a fixed name (WELLKNOWN/CLIENT-TEMPLATE or something) if 
the regular client lookup fails, and substitute in the requested name.



It looks like there is some code in the MIT KDC to perform such
a lookup; the database plugin API contains a function called
krb5_db_get_s4u_x509_principal(), which takes a client certificate.


This KDB method is there to support S4U2Self requests where the 
requesting server presents an X.509 certificate instead of a cient 
principal name.  It


Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Re: 3 kerberos security issues

[Greg Hudson]

On 3/1/24 07:13, Alexander Bergmann via Kerberos wrote:

We got notified via NVD about 3 new security issues. Right now there
seams to be no upstream reference. Could someone please comment on this?

CVE-2024-26458: Memory leak at /krb5/src/lib/rpc/pmap_rmt.c
CVE-2024-26461: Memory leak at /krb5/src/lib/gssapi/krb5/k5sealv3.c
CVE-2024-26462: Memory leak at /krb5/src/kdc/ndr.c


These CVEs appear to be the result of someone running a static analysis 
tool over the MIT krb5 code base and assigning CVEs to each resulting 
defect, without performing any additional impact analysis or upstream 
consultation.


The pmap_rmt.c leak only affects pmap_rmtcall(), which is unused by the 
rest of the krb5 code base and likely unused by anyone else.


The k5sealv3.c leak affects an encoding function, and happens on a 
bounds check which likely cannot be triggered with any choice of 
memory-valid API inputs.  (The bounds check was itself introduced to 
quash a different static analysis defect.)


The ndr.c leak also affects an encoding function, and triggers if the 
input contains invalid UTF-8.  This one might be triggerable by a 
request (though it may require elevated privilege), but I would not have 
requested a CVE for it myself.


I will fix these on the mainline, but I only expect to assign a ticket 
to the third one.


Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Re: Using PKINIT with ECC

[Greg Hudson]

> So is there a way to submit a feature request for ECDSA support in MIT
> Kerberos ?

I've filed a PR for this at https://github.com/krb5/krb5/pull/1328 .  If
you're in a position to test it, that would be helpful, as the internal
softpkcs11 (which we use for testing) didn't previously have ECDSA
support.

Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Re: Using PKINIT with ECC

[Greg Hudson]

On 11/20/23 14:09, Ken Hornstein via Kerberos wrote:

I guess what I was thinking was maybe not EVERY pkiDebug() call, but
more all of the ones that report errors.


I think we're in agreement.  Setting an extended error message should 
generally be sufficient, as it should get trace logged by libkrb5 or 
included in the KDC log.


Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Re: Using PKINIT with ECC

[Greg Hudson]

On 11/19/23 12:00, Ken Hornstein via Kerberos wrote:

I have mentioned this before, but ... is there any interest in adding
additional trace points for every place where the old "pkiDebug" calls
are made?  Hidden errors when doing PKINIT are the bane of my existence
and I feel that I'm not the only one.  I understand there are concerns
about making the trace log too verbose but I think every error could
generate a trace message and it wouldn't add too much to the trace output
when everything was working.


I would be happy to have more trace logging to diagnose PKINIT errors, 
but converting every pkiDebug() call probably wouldn't meet the criteria 
for good trace logging.  We've already made a few passes in this area, 
most recently one from you which went into release 1.20 (commit 
34625d594c339a077899fa01fc4b5c331a1647d0).


Based on this thread, it is clear that there is still room for 
improvement in the handling of PKCS11 errors.  While we mostly handle 
OpenSSL errors through the oerr() wrapper which trace logs the OpenSSL 
error queue and sets an extended error message, we don't have any such 
wrapper for PKCS11 errors.  In this case, we now know that C_SignInit() 
failed; here is the handling for that error:


if ((r = id_cryptoctx->p11->C_SignInit(id_cryptoctx->session, &mech,
   obj)) != CKR_OK) {
pkiDebug("C_SignInit: %s\n", pkcs11err(r));
return KRB5KDC_ERR_PREAUTH_FAILED;
}

So only the generic "Preauthentication failed" message shows up in the 
trace log (at the libkrb5 level) while the old debugging would have 
indicated the failed operation and the PKCS11 error string.


Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Re: Using PKINIT with ECC

[Greg Hudson]

On 11/15/23 23:22, Goetz Golla wrote:

* Does MIT Kerberos support PKINIT with Elliptic Curves as described
in RFC 5349 ?


A P-384 EC client certificate works in my tests, with either krb5-1.17 
or the current code, as long as the KDC is also running MIT krb5.


Ken is correct that there is a hardcoded reference to RSA in the source:

p7si->digest_enc_alg->algorithm =
OBJ_nid2obj(NID_sha256WithRSAEncryption);

and this probably means the CMS signature has a piece of incorrect 
metadata when an EC certificate is used.  But this field is not used 
when generating the signature contents and is ignored by OpenSSL when 
verifying the signature (when the KDC is running MIT krb5).



* Could it be that for ECC client certificates the KDC certificate
also needs the be ECC ?


In my tests the KDC certificate was an RSA cert, so no.

Of course, my experience doesn't match yours.  From your trace, I 
believe that the failure occurs in the client code, not on the KDC, so 
inspecting the KDC logs would not help.  But the trace log does not 
contain any detailed information about the failure.


You can sometimes improve the diagnostics for PKINIT failures by 
removing the long-term keys associated with the principal, so that 
authentication does not fall back to encrypted timestamp:


  kadmin purgekeys -all user

If that doesn't help, it may be necessary to build the code with 
debugging symbols and and step through it to find out where it is failing.


Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Re: renew ticket failed

[Greg Hudson]

On 11/8/23 16:13, Dong Ye wrote:

   we encountered an issue where we can't renew the ticket before the
ticket expires. Seems the ticket is renewable but its renew_till time is
before its end_time. How is it possible?


It's possible if the ticket was requested that way ("kinit -l 2h -r 1h" 
for instance).  For a period of time (1.12 through 1.15) the MIT krb5 
KDC issued non-renewable tickets for such requests, but that was found 
to be disruptive to scripts, so it once again issues renewable tickets 
whose end times can't be extended.


Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Re: Question about Windows S4U support

[Greg Hudson]

On 11/8/23 09:23, JianJun Li wrote:

In fact,   principle "host/win11client.mylab@mylab.com" exists.  By Wireshark I can 
see Windows sends "host/win11client.mylab@mylab.com"  as sname, KDC converts the 
sname to host\/win11client.mylab@mylab.com.
I have a look at the code but find no parameters or setting can change this 
behavior.


I can give a detailed but ultimately not very helpful answer:

As Ken explained in part, the wire representation of principals in 
Kerberos is the ASN.1 DER encoding of a name-type and a sequence of 
strings.  Microsoft created a name type NT-ENTERPRISE which puts an 
email-address-like string in the first string element.  When you see 
"host\/..." in your log, that is the MIT krb5 library's string 
representation of an NT-ENTERPRISE principal.


RFC 6806 section 5 describes this name type as conveying alias names, to 
be used in the client field of an AS-REQ to a KDC with a directory 
service that can map email addresses to canonical principal names. 
However, Microsoft's implementation now also uses this type in server 
names during under some circumstances, including some S4U operations. 
[MS-KILE] 3.3.5.1.1 defines semantics for server name lookup of 
NT-ENTERPRISE principals (in terms of underlying facilities specific to 
Active Directory); [MS-SFU] unfortunately does not seem to say precisely 
when they are used.  I had thought they were only used for cross-realm 
S4U2Self operations where it is necessary to communicate the requesting 
service's realm to the client realm, but based on your log it sounds 
like they are also used for same-realm S4U2Self requests made by Windows 
clients.


Although MIT krb5 has S4U2Self and S4U2Proxy logic in the KDC code, it 
does not implement NT-ENTERPRISE lookup.  The translation from 
NT-ENTERPRISE {"host/win11client.mylab@mylab.com"} to NT-PRINCIPAL 
{"host", "win11client.mylab.com"} currently has to be done within the 
KDB layer, either by using an encompassing piece of software with a KDB 
module (such as Samba), or by setting up an explicit alias in the LDAP 
KDB module (the BDB and LMDB modules do not support aliases).  I believe 
the situation could be improved by performing this translation within 
the KDC for TGS service lookups, but that improvement, although simple 
in concept, would require careful testing.



The digitally signed Privilege Attribute Certificate (PAC) that contains the 
authorization information for client user in realm MYLAB.COM could not be 
validated.
  This error is usually caused by domain trust failures; Contact your system 
administrator.


I don't know exactly what is causing this error on the Windows side, 
especially if it only happens some of the time.  I will note that when 
used with any of the built-in KDB modules (BDB, LMDB, or LDAP), MIT 
krb5's KDC includes a minimal PAC with no SID or group information. 
Encompassing software such as Samba is required to supply a complete PAC 
within issued tickets.  This limitation may be unrelated to the error 
given that the error does not always occur.


Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Re: Removing deprecated keys

[Greg Hudson]

On 10/31/23 21:16, Dan Mahoney (Gushi) wrote:
We've recently gone through all the hard work of switching off 3des on 
our kdcs and rolling all the things, but one of the things we note is 
that some of our users still have the keys with the old enctypes 
present.  Is there a way to delete just those deprecated keys, without 
forcing a password change?


I don't believe we have that feature currently; the closest we have is 
the kadmin purgekeys command, but that command (and its associated 
libkadm5 RPC) only removes whole key versions.


It would be possible to write a C program using libkdb5 to crawl the 
database and remove the desired keys; I can't think of any simpler 
approach.  I believe common practice is just to force password changes, 
or wait until password maximum lifetimes force changes over time.


If you're at the point of not relying on any des3-cbc-sha1 keys, you can 
set a permitted_enctypes in [libdefaults] on the KDC that does not 
include it (a value of "DEFAULT -des3" should work).  Then the KDC will 
ignore those keys while continuing to allow the other ones to be used.


Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Re: RFC 4121 & acceptor subkey use in MIC token generation

[Greg Hudson]

On 10/24/23 15:50, Ken Hornstein via Kerberos wrote:
[Disputing the following comment in k5sealv3.c:]

First, we can't really enforce the use of the acceptor's subkey,
if we're the acceptor; the initiator may have sent messages
before getting the subkey.  We could probably enforce it if
we're the initiator.



I was under the impression
that when you're doing mutual authentication (which in my experience
is pretty much all of the time) you can't send any other GSSAPI tokens
until authentication is complete and if authentication is complete then
you can definiteley be assured any subkeys have already been exchanged.
Clearly Heimdal enforces this and other than this obviously wrong client
code I am not aware of any operational issues.  Am I wrong?  I admit
that is always a possibility!


I believe mutual authentication is frequently omitted for HTTP 
negotiate, but that's a minor point as in that case there's no acceptor 
subkey.


Whether the initiator can generate per-message tokens before receiving 
the subkey depends on whether the mechanism returned the prot_ready 
state (RFC 2743 section 1.2.7) to the caller after generating the 
initiator token.  RFC 4121 does not mention prot_ready; I couldn't say 
whether that's an implicit contraindication on setting the bit.  I'm not 
aware of any krb5 mechs setting the bit at that point in the initiator, 
although I recall Nico talking about maybe wanting to do so.


The comment was written twenty years ago by a developer no longer 
working for MIT, and I don't recall having any conversations about it 
before this one.


Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Re: Kerberos PAC decoding support

[Greg Hudson]

On 8/24/23 02:18, Ondrej Valousek wrote:

I am wondering if it is reasonable to request the MIT library to support PAC 
decoding (possibly in form of Named Attributes) so that the information there 
could be used in calling application, I.e.:


PAC buffers are available via these name attributes:

  urn:mspac: (for the whole PAC)
  urn:mspac:logon-info
  urn:mspac:credentials-info
  urn:mspac:server-checksum
  urn:mspac:privsvr-checksum
  urn:mspac:client-info
  urn:mspac:delegation-info
  urn:mspac:upn-dns-info

libkrb5 doesn't do any NDR decoding, so that part has to be done by the 
application.


Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

krb5-1.21.2 is released

[Greg Hudson]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

The MIT Kerberos Team announces the availability of MIT Kerberos 5
Release 1.21.2.  Please see below for a list of some major changes
included, or consult the README file in the source tree for a more
detailed list of significant changes.

Retrieving krb5-1.21.2
==

You may retrieve the krb5-1.21.2 sources from the following URL:

https://kerberos.org/dist/

The homepage for the krb5-1.21.2 release is:

https://web.mit.edu/kerberos/krb5-1.21/

Further information about Kerberos 5 may be found at the following
URL:

https://web.mit.edu/kerberos/


Major changes in 1.21.2 (2023-08-14)


This is a bug fix release.

* Fix double-free in KDC TGS processing [CVE-2023-39975].
-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEExEk8tzn0qJ+YUsvCDLoIV1+Dct8FAmTcPH0ACgkQDLoIV1+D
ct/CUA/+PL2U0dcWUXR1gMBhlJ/4PNo0ElpnYZ06VG2VKvLfNnf4iMAHNbmZt1Kh
tZTvbseJYm/ESXuXxuBA8tP8dcbZCu0YzdkREbwvnDiAiLxOFU3HrwnGDUNeIVST
P9Kn/ewD0oa2yPuEN+AxQ9jPJ1gqGvJmbSvGE9Z9eJIPFtAevM8zKbL0uepiQkWf
lqAGil9ltVOQr85Ioyn5feOsi/qOVX6sm+aIHYnRGlP1YEwhR+bRg+oS+PD1djC/
hUbUMVXOi4nTNLnC2c+vb36TYbgSz5FjR0ccHIJZYWWqEUaDiXwcnrHUJAZUSQrN
0YlHaN26Q/9oo0OJpuFui2umNFGig6kGRadvaiP7vRK5yc6d8a6IMCm9/hdM93eF
4GNcZdD6olG2TcWdZwBhodV/+nk6bxkc5k8rE5oxR9VMC06qJrXWr7JxXLr4uGX7
sgx9MIQH9W3pPdaZHjFRYrUjla+hkHskKd7jSQqlRdsIG7CPBA+GXDF+9bhxtfg8
jQsrFbOlc5W5yZhVhvEYvDByZ1/wQJD5tQGPef3hWDMEj98mj1CZOFtIaIG9OOYi
phSHAyz+JTfkTxZsSc44LQY3wu2grTUArr1tyYVNqxYnb5GuXxeNWE8GQB5j4PhF
+0DIcROK12nL2AZkEY6FPShA4sNGQ0bKwoG+YiE2N2JL/OKhBQw=
=xP+o
-END PGP SIGNATURE-
___
kerberos-announce mailing list
kerberos-annou...@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos-announce

Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

krb5-1.21.1 and krb5-1.20.2 are released

[Greg Hudson]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

The MIT Kerberos Team announces the availability of MIT Kerberos 5
Releases 1.21.1 and 1.20.2.  Please see below for a list of some major
changes included, or consult the README file in the source tree for a
more detailed list of significant changes.

Retrieving krb5-1.21.1 and krb5-1.20.2
==

You may retrieve the krb5-1.21.1 and krb5-1.20.2 sources from the
following URL:

https://kerberos.org/dist/

The homepages for the krb5-1.21.1 and krb5-1.20.2 releases are:

https://web.mit.edu/kerberos/krb5-1.21/
https://web.mit.edu/kerberos/krb5-1.20/

Further information about Kerberos 5 may be found at the following
URL:

https://web.mit.edu/kerberos/


Major changes in 1.21.1 (2023-07-10) and 1.20.2 (2023-07-06)


These are bug fix releases.

* Fix potential uninitialized pointer free in kadm5 XDR parsing
  [CVE-2023-36054].

* Fix read overruns in SPNEGO parsing (already included in 1.21).

* Compatibility fix for autoconf 2.72 (already included in 1.21).
-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEExEk8tzn0qJ+YUsvCDLoIV1+Dct8FAmS2yjIACgkQDLoIV1+D
ct8tDg/+ImlYd/Xw8+NFGkMuHpjWzIGcactAAolly5IJ8AVPPD6bOVG8U0U2ZrY7
cBHMfNxQyznk/lHhZogVLb0eP3VwBLtUDTdLX3RJ1Nm6/OFAmcpnletOZCAotcqz
FVYfcNWftOfPDNudFWtMA0g5+5gKMs7IbyJWwSJNM0pdzYKAleuSApG9ppKMeEsA
ztMjplVLGxEZiNrWdWxjHevT+/LDVRO9inW4QowSRD+u0DztygzZOAYBd8QkHGKH
4NgZfWjDukUCJkgRLC1UmyPP/3rbuyqnVGhMKblreYBfCArhxYyNvz5NHB12LnM/
IvHg7t42B/q4EhllwX/+tYCZJ7zUvKXckK1LnN16CZMPJZ69fDwjplOn6qeK9TKV
E69AUrRxL2IDqG/zh+BZSFVFrInJWNrNymaLzFuwUi9e1prPenMHYGKN8ycF5KOC
/zIexRxeVoPY/pkT26Csv8+U5QLqEJmaZIw8VsMc8PUQLWT/LCUyqZdd5PGVkUCo
yowLJhrLVi+93Uwj+v9IB+8PYsT2cl7V4kB+ua3yrZs0OgOn2XcqvCpbHzEWVYfI
YKYRoXqs39kkflQ41pf/g3r4GMCerKBwePLFmf41+JbniSBnhUSY+c50b3kQ7CNY
mP2u+eLe3Mvq324w0BjzZeNSMMEdYUOOsxr0I6sRHhLJmWrTZKE=
=qJTF
-END PGP SIGNATURE-
___
kerberos-announce mailing list
kerberos-annou...@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos-announce

Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

krb5-1.21 is released

[Greg Hudson]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

The MIT Kerberos Team announces the availability of MIT Kerberos 5
Release 1.21.  Please see below for a list of some major changes
included, or consult the README file in the source tree for a more
detailed list of significant changes.

RETRIEVING KERBEROS 5 RELEASE 1.21
==

You may retrieve the Kerberos 5 Release 1.21 source from the
following URL:

https://kerberos.org/dist/

The homepage for the krb5-1.21 release is:

https://web.mit.edu/kerberos/krb5-1.21/

Further information about Kerberos 5 may be found at the following
URL:

https://web.mit.edu/kerberos/

and at the MIT Kerberos Consortium web site:

https://www.kerberos.org/


PAC transitions
===

Beginning with release 1.20, the KDC will include minimal PACs in
tickets instead of AD-SIGNEDPATH authdata.  S4U requests (protocol
transition and constrained delegation) must now contain valid PACs in
the incoming tickets.  Beginning with release 1.21, service ticket
PACs will contain a new KDC checksum buffer, to mitigate a hash
collision attack against the old KDC checksum.  If only some KDCs in a
realm have been upgraded across versions 1.20 or 1.21, the upgraded
KDCs will reject S4U requests containing tickets from non-upgraded
KDCs and vice versa.

Triple-DES and RC4 transitions
==

Beginning with the krb5-1.21 release, the KDC will not issue tickets
with triple-DES or RC4 session keys unless explicitly configured using
the new allow_des3 and allow_rc4 variables in [libdefaults].  To
facilitate the negotiation of session keys, the KDC will assume that
all services can handle aes256-sha1 session keys unless the service
principal has a session_enctypes string attribute.

Beginning with the krb5-1.19 release, a warning will be issued if
initial credentials are acquired using the des3-cbc-sha1 encryption
type.  Beginning with the krb5-1.21 release, a warning will also be
issued for the arcfour-hmac encryption type.  In future releases,
these encryption types will be disabled by default and eventually
removed.

Beginning with the krb5-1.18 release, all support for single-DES
encryption types has been removed.


Major changes in 1.21 (2023-06-05)
==

User experience:

* Added a credential cache type providing compatibility with the macOS
  11 native credential cache.

Developer experience:

* libkadm5 will use the provided krb5_context object to read
  configuration values, instead of creating its own.

* Added an interface to retrieve the ticket session key from a GSS
  context.

Protocol evolution:

* The KDC will no longer issue tickets with RC4 or triple-DES session
  keys unless explicitly configured with the new allow_rc4 or
  allow_des3 variables respectively.

* The KDC will assume that all services can handle aes256-sha1 session
  keys unless the service principal has a session_enctypes string
  attribute.

* Support for PAC full KDC checksums has been added to mitigate an
  S4U2Proxy privilege escalation attack.

* The PKINIT client will advertise a more modern set of supported CMS
  algorithms.

Code quality:

* Removed unused code in libkrb5, libkrb5support, and the PKINIT
  module.

* Modernized the KDC code for processing TGS requests, the code for
  encrypting and decrypting key data, the PAC handling code, and the
  GSS library packet parsing and composition code.

* Improved the test framework's detection of memory errors in daemon
  processes when used with asan.
-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEExEk8tzn0qJ+YUsvCDLoIV1+Dct8FAmR+vpAACgkQDLoIV1+D
ct9UkxAAy2RjigQHq5EflPJBfRWUB6olwpOJRoNKWL17iUKoRh4ZtJe7pUt1dcdQ
8W/3p1oTgnk1yWMkUQCP2RR5YlmmTllB+/umUjwBQzvFtvjTfoWhvURVsJbTfyi1
SN4tUKvPlizd6dNM/08ad9A4IN7LD+8qlP1k6qgjzL0eXYHrMoDXYXZNUmi/Ekse
VdHnW9ols1P6rqSfD5x86r8QoflYbAit4tylOf6xAfDeBuQiJmEvl0fYkRGr6gGJ
Gaep55XZcgxKisyHuJZh5w7+iE9FiZff5xsGKBxT/BzdUWoI+6Wot9CWnMcaHjaO
Eg9ohgfk3dY9XH5SsG0Xzb7yrRSy2zeuGHoB+GfeUx8vFBGYCxApmpV89zX/5g75
FVOd5TPCuZrfR0hbBwHrKAPE3/WEslRU5zTduHEK38IGQ9++YxuphH6W9/aYBiHJ
9Dzcn5G7W9o5r3WL967/CfH6BHispTYoE07CQfjL22cb9euwD44UdLS/g1qijbED
MlEaC45afN3aXAPSV+D4fPe/7d/5iYAc5BT6U+P/hlZkJOAIOLPMM+FeaHW6gGKy
x+Ip5I45i2ZVc+b8OUI3jXonYRIg5ADxbvZt2Eu4WYFd22ipEyjwQCBqaXuXWE0P
VRgX11z1iZjKdAZcwzaDfyzXO6Una+CVfsKf6i2wKdTJrSAnVUQ=
=CUot
-END PGP SIGNATURE-
___
kerberos-announce mailing list
kerberos-annou...@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos-announce

Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Re: help with OTP

[Greg Hudson]

On 4/25/23 20:01, Ken Hornstein via Kerberos wrote:

First, there's about 500x ways for PKINIT to go wrong, and when it does
go wrong 99% of the time you fall back to a password so it's hard to
figure out exactly what failed.


Assuming the kadmin client and KDC are running 1.12 or later, you can 
create WELLKNOWN/ANONYMOUS with the -nokey option (instead of -randkey) 
to disable the password fallback.  Or you can "kadmin.local purgekeys 
-all WELLKNOWN/ANONYMOUS" to remove the principal's long-term keys once 
it already exists.  If this is done you should get PKINIT error messages 
from kinit -n if the KDC offered PKINIT and the client couldn't make it 
work, like this:


$ kinit -n
kinit: Pre-authentication failed: No pkinit_anchors supplied while 
getting initial credentials


(The PKINIT doc page still says to create WELLKNOWN/ANONYMOUS with 
-randkey, even though it talks about the -nokey option for client 
principals.  I will work on documentation updates based on this thread.)


Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Re: Is there a way to steer kinit to a specific kdc?

[Greg Hudson]

On 4/5/23 00:52, Dan Mahoney (Gushi) wrote:
Can neither mit kinit nor the heimdal one supplied with BSD systems by 
default, not just be forced to a single KDC?


It can't, and the library APIs don't really enable it.  A program could 
use krb5_init_creds_step() or krb5_tkt_creds_step() to compose KDC 
requests and do its own network transport, but kinit isn't in the 
business of doing its own network stuff and it doesn't use the _step APIs.


Adding an init_creds option to specify a KDC host would raise some 
questions.  Does the application specify a hostname or an address?  Can 
it specify specifically TCP or UDP or the fallback order?  What about https?


At this time I would rather see an externally-maintained KDC probe 
application using the _step APIs (or for people to keep doing this with 
faked-up krb5.conf files) than accept the complexity of building this 
into the MIT krb5 kinit and the API.


Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Re: appl/simple/client/sim_client.c uses internal APIs

[Greg Hudson]

On 2/24/23 06:15, Florian Weimer wrote:

I need to fix Authen::Krb5 (a Perl wrapper) not rely on this krb5
internals.  Obviously, this is going to stay a krb5 wrapper, and won't
switch to GSSAPI.  So I'd really appreciate if someone would fix the
appl/simple/client/sim_client.c example not to rely on , so
that I can apply the parallel changes to the Perl port of this example
code.


Done:

https://github.com/krb5/krb5/commit/9139a60c94c24e41109574e84e7cda9c2dc3fb38

If possible, the Perl client code should be changed to use 
AP_OPTS_USE_SUBKEY, in addition to removing the replay cache calls.


Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Re: appl/simple/client/sim_client.c uses internal APIs

[Greg Hudson]

On 2/23/23 12:34, Sam Hartman wrote:

I also think that the simple client referred to in the subject has a
bunch of anti-patterns.
As an example, I don't think it integrity protects or encrypts its
exchanges


I think appl/simple actually does protect messages but appl/sample does not.

It looks like the uses of krb5_gen_portaddr() and krb5_gen_replay_name() 
in sim_client.c don't do anything after commit 
dcb853ac32779b173f39e19c0f24b0087de85771 so they can be removed (I just 
didn't realize it at the time).


Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Re: Question about release cadence

[Greg Hudson]

On 2/21/23 05:09, Lars Francke wrote:

Are there any specific plans for 1.21?


I expect 1.21 to come out in the spring, but not in the next month.

Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Re: Using a stub krb5.conf with "include"

[Greg Hudson]

On 12/12/22 14:04, John Devitofranceschi wrote:

% cat mykrb5.conf
[libdefaults]
default_ccache_name = FILE:/my_ccache_location/krbcc_%{uid}

include /etc/krb5.conf



I cannot find a description of the behaviour of the ‘include’ directive with 
respect to this kind of thing.


https://web.mit.edu/kerberos/krb5-latest/doc/admin/conf_files/krb5_conf.html#structure

is the documentation we have on the include directive.  Your example 
should work.



If the system krb5.conf defines default_ccache_name, will my setting take 
precedence for my application when I set  
KRB5_CONFIG=/my_config_location/mykrb5.conf in its environment?


In the profile model, a relation can have one or more values, with the 
order of values determined by the order of appearance.  Some variables 
have a defined meaning for multiple values (like "kdc" in a realm 
section), but most variables, including default_ccache_name, only have 
meaning for a single value.


Unfortunately, different parts of the code are not consistent in how 
they handle multiple values for a single-value variable.  For variables 
handled through libkrb5, like default_ccache_name, the first value is 
used.  So in your example, your default_ccache_name setting would take 
precedence over one defined in the system krb5.conf, because it was read 
first.


Variables handled through libkadm5 instead use the last value.  The 
ancient history here is that the kadmin system was written by a 
different organization than the one that wrote the rest of krb5. 
Changing libkadm5 to be consistent with libkrb5 would have the potential 
to break configurations during upgrades, though it might be worth doing 
anyway.


The profile library has the concept of marking a section or subsection 
as "final", preventing further amendments to that section.  But that 
concept does not apply to individual relations (although it was 
erroneously documented as applying to them prior to 1.17.1).


Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

krb5-1.20.1 and krb5-1.19.4 are released

[Greg Hudson]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

The MIT Kerberos Team announces the availability of MIT Kerberos 5
Releases 1.20.1 and 1.19.4.  Please see below for a list of some major
changes included, or consult the README file in the source tree for a
more detailed list of significant changes.

Retrieving krb5-1.20.1 and krb5-1.19.4
==

You may retrieve the krb5-1.20.1 and krb5-1.19.4 sources from the
following URL:

https://kerberos.org/dist/

The homepages for the krb5-1.20.1 and krb5-1.19.4 releases are:

https://web.mit.edu/kerberos/krb5-1.20/
https://web.mit.edu/kerberos/krb5-1.19/

Further information about Kerberos 5 may be found at the following
URL:

https://web.mit.edu/kerberos/


Triple-DES transition
=

Beginning with the krb5-1.19 release, a warning will be issued if
initial credentials are acquired using the des3-cbc-sha1 encryption
type.  In future releases, this encryption type will be disabled by
default and eventually removed.

Beginning with the krb5-1.18 release, single-DES encryption types have
been removed.


Major changes in 1.20.1 and 1.19.4 (2022-11-15)
===

These are bug fix releases.

* Fix integer overflows in PAC parsing [CVE-2022-42898].

* Fix null deref in KDC when decoding invalid NDR.

* Fix memory leak in OTP kdcpreauth module.

* Fix PKCS11 module path search.
-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEExEk8tzn0qJ+YUsvCDLoIV1+Dct8FAmNzxmgACgkQDLoIV1+D
ct/AtRAAiQ8LFqalOMok97OuagdHipmdHRxD8cXgOyb06Zbe4ZddOG3PIErNyAYA
3sDTD/u8jrZ6hA5EWVJMPc13onV8jA1VDRrmDOgN2CekKxZATHMfuQ4Chm+HUUcf
/FGjpKmGuPeZoDOnW0CBvzsGkaqRbv6cohQmuBb8FrjJnYUycPpVQr/+qWgmjbGu
wGOE+k/weZpzWEolKa3q2S9Uho3DletUkX6mqkFlYI+aKPjQAg008r7P6tR7dkUk
RX+JgE0SwrmWF9vKpvU/JV5fJGNJ5X0tTJqSrCuvxme56ClKqmaOxFhsRcS6miMY
csBeczRyHvJjZmpIP9e4WwKI9wLrR7GCYCQqL/x4RNaRDdIzF2dgeS5QFDoOJIe7
vsuxdOR5+nArkv7cyCYf7AmCZjc8Yx7ucrDq+d25fniv8dT9tIpogJyJfKIwIGHh
MVNEg1vqnHZ3VOP1i+FOhzp6fOegNzKMsN7MtvIZKbZIV9V8F+7XhZtCgWgdNlWW
nZ/DFr+SwgXiyOVN+cor4E1rMP7brNu59rI4aA5lVlJIfMsYVXnWzQ5H1hDOC5w/
snkPXtgkRdcCO9HTiTwNWC4nK2dbguu90/EnoFtP1mjmemmQU5U0QJ19JUQ9CHbK
Hmprwhs11AeImoc/ePUYfmvYCCuxgPcp3VPEZwgDsF2VCDWbrJw=
=ZJWv
-END PGP SIGNATURE-
___
kerberos-announce mailing list
kerberos-annou...@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos-announce

Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

MITKRB5-SA-2022-001 Vulnerabilities in PAC parsing

[Greg Hudson]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

MITKRB5-SA-2022-001

MIT krb5 Security Advisory 2022-001
Original release: 2022-11-15
Last update: 2022-11-15

Topic: Vulnerabilities in PAC parsing

CVE-2022-42898: integer overflow vulnerabilities in PAC parsing

SUMMARY
===

Three integer overflow vulnerabilities have been discovered in the MIT
krb5 library function krb5_parse_pac().

IMPACT
==

An authenticated attacker may be able to cause a KDC or kadmind
process to crash by reading beyond the bounds of allocated memory,
creating a denial of service.  A privileged attacker may similarly be
able to cause a Kerberos or GSS application service to crash.

On a 32-bit platform, an authenticated attacker may be able to cause
heap corruption in a KDC or kadmind process, possibly leading to
remote code execution.  A privileged attacker may similarly be able to
cause heap corruption in a Kerberos or GSS application service running
on a 32-bit platform.

An attacker with the privileges of a cross-realm KDC may be able to
extract secrets from a KDC process's memory by having them copied into
the PAC of a new ticket.

AFFECTED SOFTWARE
=

Kerberos and GSS application services using krb5-1.8 or later are
affected.  kadmind in krb5-1.8 or later is affected.  The krb5-1.20
KDC is affected.  The krb5-1.8 through krb5-1.19 KDC is affected when
using the Samba or FreeIPA KDB modules.

FIXES
=

* Upcoming releases in the krb5-1.19 and krb5-1.20 series will contain
  fixes for these vulnerabilities.

* The patch for krb5-1.20.x is available at

  https://web.mit.edu/kerberos/advisories/2022-001-patch-r120.txt

  A PGP-signed patch is available at

  https://web.mit.edu/kerberos/advisories/2022-001-patch-r120.txt.asc

* The patch for krb5-1.19.x is available at

  https://web.mit.edu/kerberos/advisories/2022-001-patch-r119.txt

  A PGP-signed patch is available at

  https://web.mit.edu/kerberos/advisories/2022-001-patch-r119.txt.asc

REFERENCES
==

This announcement is posted at:

  https://web.mit.edu/kerberos/advisories/MITKRB5-SA-2022-001.txt

This announcement and related security advisories may be found on the
MIT Kerberos security advisory page at:

https://web.mit.edu/kerberos/advisories/index.html

The main MIT Kerberos web page is at:

https://web.mit.edu/kerberos/index.html

CVE:
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-42898

ACKNOWLEDGMENTS
===

One of the integer overflow vulnerabilities was discovered by
oss-fuzz.

CONTACT
===

The MIT Kerberos Team security contact address is
.

DETAILS
===

A PAC (Privilege Attribute Certificate) is a Kerberos authorization
data type specified by Microsoft.  PACs are parsed by application
services and KDCs after the PAC is extracted from a decrypted ticket.
Attacking an application service requires a high level of privilege,
as the attacker must possess the long-term key of the service to
insert a crafted invalid PAC into a ticket that the service can
decrypt.  To attack a KDC or kadmind, the attacker must possess the
long-term key of a principal in the KDC realm, but does not require a
high level of privilege.

There are three potential overflow vulnerabilities in
krb5_pac_parse():

1. krb5_pac_parse() reads a buffer count from the serialized PAC,
which can be any unsigned 32-bit value.  It then computes a header
length from the buffer count, and returns an error if the header
length is larger than the serialized PAC length.  If the buffer count
is 2^28 or higher, the header length computation will overfow, and the
result may be less than or equal to the PAC length.

If the header length check is defeated in this manner,
krb5_pac_parse() will attempt to parse metadata for at least 2^28
buffers, exceeding the bounds of the serialized PAC.  In most cases,
parsing beyond the end of the PAC will encounter invalid metadata and
the parse operation will fail, with no harmful consequences.  In some
cases the process may be terminated with a segmentation violation.

2. krb5_pac_parse() computes a reallocation size based on the buffer
count.  If the buffer count is 2^28 or higher, the size computation
will overflow on 32-bit platforms, and the function will allocate
insufficient space to store buffer metadata.  On 64-bit platforms the
size computation cannot overflow.

An insufficient storage allocation will result in heap corruption when
buffer metadata is read.  The attacker has a significant degree of
control over what data is written beyond the end of the allocated heap
region.

3. For each buffer, krb5_pac_parse() reads a 64-bit offset and a
32-bit length.  The function returns an error if the sum of the offset
and length exceeds the length of the serialized PAC.  If the sum
exceeds 2^64, the offset and length may be erroneously allowed.  A
later read of the buffer may cause the process to crash.  If it does
not, the buffer contents may contain secrets located in process
memory.  A KDC may c

Re: GSS-API error gss_accept_sec_context: Request ticket server HTTP/ not found in keytab

[Greg Hudson]

On 11/11/22 10:33, Kerberos Enthusiast wrote:

It seems, if multiple servers supply separate keytabs, then the
subsequent kerberos auth request targeted for multiple kerberos servers
with separate keytabs and application keep on
updating "default_keytab_name" global variable and it causes some of the
authentication requests to fail and it throws this error


There is no global variable named default_keytab_name in MIT krb5. 
There is a krb5.conf configuration variable with this name, but it is 
never changed by the GSS or Kerberos libraries.



*"GSS-API error gss_accept_sec_context: Request ticket server HTTP/ not
found in keytab" *(major code - 186a5, d)


This message is a little bit puzzling, because the principal name 
("HTTP/") is incomplete, and because the message of this form in the 
code includes a parenthetical about the ticket kvno.



Using this api *krb5_gss_register_acceptor_identity() *to set the default
keytab file for kerberos authentication.


This function sets a thread-specific global variable.  It should work to 
invoke it before each call to gss_acquire_cred(), or before each call to 
gss_accept_sec_context() using the default acceptor credential.  Or:



Can we use any other gss_api to maintain the local context of the keytab
file and send this keytab for every authentication request?


gss_acquire_cred_from() allows the caller to specify a keytab name when 
acquiring credentials.  See:


https://web.mit.edu/kerberos/krb5-latest/doc/appdev/gssapi.html#credential-store-extensions

Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

MIT krb5 security release on 2022-11-15

[Greg Hudson]

There will be an MIT krb5 security advisory on November 15, 2022, with
corresponding patch releases 1.20.1 and 1.19.4.  The KDC, kadmind, and
GSS and Kerberos application servers are affected.  The impact is
significantly reduced on 64-bit platforms.
___
kerberos-announce mailing list
kerberos-annou...@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos-announce

Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Re: Kerberos protocol transition with unconstrained delegation (i.e. TGT impersonation)

[Greg Hudson]

On 10/27/22 12:36, Jeffrey Hutzelman wrote:

You don't need libkadm5 for any of this -- all you need to print a service
ticket (even a TGT) is the service's key. Heimdal comes with a program,
kimpersonate, which does this and could easily be used as a basis for your
impersonation service.


MIT krb5 has a sort-of equivalent: "kinit -k -t KDB: username".  The KDC 
is still in the loop, but no password or keytab for the user is 
required.  (Add "-S krbtgt/OTHERREALM" for a cross-realm TGT.)



Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Re: Authentication Indicators and Cross Realm Trust

[Greg Hudson]

On 9/30/22 16:06, Machin, Glenn Douglas via Kerberos wrote:

Can someone tell me if a TGT containing an authentication indicator will work 
over to a service principal in another realm which has a cross realm trust 
relationship?


Authentication indicators are currently only accepted within the same 
realm; cross-realm service ticket requests do not preserve the 
indicators from the cross-realm TGT.


Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Re: kadmin not working after server migration, but kdc works

[Greg Hudson]

On 9/21/22 03:45, Wouter Verhelst wrote:
> default_principal_expiration = 0

This value is failing to parse as a timestamp.  Removing this line
appears to clear up the config parsing error, and the default should
have the same effect.

I see that the documentation for default_principal_expiration says "The
default value is 0, which means no expiration date."  I see how someone
would get that from the code when writing the documentation, but clearly
the documented default should be something that parses.  (I think you'd
have to write out the beginning of the POSIX time epoch--in local
time--in something like mmddhhmmss format to get this default.)  The
whole concept of default_principal_expiration as an absolute time seems
suspect to me; I have trouble imagining a productive realm configuration
where every new principal by default expires on some particular fixed date.

I don't see any meaningful differences between the current code in this
area and the code going back fifteen years or so.  So I'm not sure how
this broke during a migration.

Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Re: kadmin not working after server migration, but kdc works

[Greg Hudson]

On 9/20/22 10:19, Wouter Verhelst wrote:
> I can log in to the server; "kinit" works just fine. However, kadmind
> refuses to start, and when I run "kadmin.local", I get:
> 
> root@lounge ~ # kadmin.local
> Authenticating as principal root/ad...@grep.be with password.
> kadmin.local: Required parameters in kdc.conf missing while initializing 
> kadmin.local interface

This is one of our worst error messages (see
https://krbdev.mit.edu/rt/Ticket/Display.html?id=8247 ).

>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.

Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Re: can realms get "aliased" when there is a one-way trust? or, what is going on here?

[Greg Hudson]

On 8/4/22 13:18, Jerry Shipman wrote:
> It seems that when a user tries to get a service ticket for the
> afs/mit.foo.cornell@foo.cornell.edu (which doesn't exist), he will
> wind up with two tickets, one for
> afs/mit.foo.cornell@foo.cornell.edu and one for
> afs/mit.foo.cornell@mit.foo.cornell.edu. But this is odd, because
> afs/mit.foo.cornell@foo.cornell.edu doesn't exist.

Kerberos has the concept of "referrals" for TGS requests, which are
defined in RFC 6806.  If the FOO.CORNELL.EDU KDC finds that
afs/mit.foo.cornell.edu doesn't exist in its database, but can determine
that it should be in MIT.FOO.CORNELL.EDU, then instead of issuing a
service ticket, it may issue a cross-realm TGT for MIT.FOO.CORNELL.EDU.
 The client will then follow the referral to MIT.FOO.CORNELL.EDU and get
a afs/mit.foo.cornell@mit.foo.cornell.edu ticket.

How the result is cached depends on the client software.  For MIT krb5,
prior to 1.18 the resulting ticket is cached under both the requested
name and the final ticket service name.  In 1.18 and later the ticket is
only cached under the requested name, but klist shows the ticket service
name if it differs, like this:

08/04/22 14:52:52  08/05/22 14:50:28  a/x...@krbtest1.com
Ticket server: a/x.d@REFREALM

> But isn't that dangerous, because b...@mit.foo.cornell.edu and
> b...@foo.cornell.edu are totally different entities! Why would it do
> that? Is there a way to turn that off?

The theory behind referrals is that service principal names are
generally unique across realms, because they incorporate FQDNs.  So a
client looking for a ticket for afs/mit.foo.cornell.edu generally
doesn't need to know which realm takes responsibility for authenticating
that name; its KDC can make that decision.

Client names are of course much less likely to be unique across realms;
"fred" may refer to a completely different user in different realms even
if they have cross-realm relationships.

Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Re: Help with replication

[Greg Hudson]

On 7/16/22 05:00, Bill MacAllister wrote:
> 2022-07-16T08:17:57.049587+00:00 kdc-iad-1 kpropd[630]:
> /usr/sbin/kpropd: Key table entry not found while initializing
> /usr/sbin/kpropd interface, retrying

Usually this is a hostname canonicalization issue.  You can set the
environment variable KRB5_TRACE to a filename, start kpropd, and look in
the file to see what principal is being looked up.

Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Re: Creating a principal using the kadmin C API

[Greg Hudson]

On 5/9/22 10:09, Teo Klestrup Röijezon wrote:
> On Saturday, May 7, 2022 8:24:58 AM CEST Greg Hudson wrote:
>> I think this is a bug; the init functions and kadm5_get_config_params()
>> should use the profile object from the context argument.  I have a
>> candidate patch that passes tests.
[...]
> As long as we can get it working with either a new release or a temporary 
> soft 
> fork I'm not massively worried about backporting to older versions. 
> Especially 
> since this is purely a client issue.

I made this change on the mainline, though it didn't make it into the
1.20 release.

https://github.com/krb5/krb5/commit/49a857808b918440793daa81c8fe352326623fef

Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Re: Using an alternate principal for ssh

[Greg Hudson]

On 5/31/22 12:05, Dan Mahoney wrote:
> On most of our boxes, ssh is the ONLY kerberized app, but there's no 
> provision in krb5.conf to say what the default principal based on a username 
> is.  None of the PAM modules seem to be able to set it, either.  I conjured 
> up an elaborate way to do this by forcing the .k5logindir to be something the 
> users couldn't touch, and forcing a create for each user, but this doesn't 
> help the password case.
> 
> Does anyone know of a simple way to accomplish this?  There are some clients, 
> like mobile ones, where, VPN or no, kinit'ing is not an option.

The OpenSSH sshd code decides the principal name, not libkrb5.  Looking
at the OpenSSH auth-krb5.c, I don't think there's any configurability;
it picks a principal name of
authctxt->pw->pw_name (except on AIX), parses that, and calls
krb5_get_init_creds_password().

Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

krb5-1.20 is released

[Greg Hudson]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

The MIT Kerberos Team announces the availability of MIT Kerberos 5
Release 1.20.  Please see below for a list of some major changes
included, or consult the README file in the source tree for a more
detailed list of significant changes.

RETRIEVING KERBEROS 5 RELEASE 1.20
==

You may retrieve the Kerberos 5 Release 1.20 source from the
following URL:

https://kerberos.org/dist/

The homepage for the krb5-1.20 release is:

https://web.mit.edu/kerberos/krb5-1.20/

Further information about Kerberos 5 may be found at the following
URL:

https://web.mit.edu/kerberos/

and at the MIT Kerberos Consortium web site:

https://www.kerberos.org/


PAC transition
==

Beginning with release 1.20, the KDC will include minimal PACs in
tickets instead of AD-SIGNEDPATH authdata.  S4U requests (protocol
transition and constrained delegation) must now contain valid PACs in
the incoming tickets.  If only some KDCs in a realm have been upgraded
across version 1.20, the upgraded KDCs will reject S4U requests
containing tickets from non-upgraded KDCs and vice versa.


Triple-DES transition
=

Beginning with the krb5-1.19 release, a warning will be issued if
initial credentials are acquired using the des3-cbc-sha1 encryption
type.  In future releases, this encryption type will be disabled by
default and eventually removed.

Beginning with the krb5-1.18 release, single-DES encryption types have
been removed.


Major changes in 1.20 (2022-05-26)
==

Administrator experience:

* Added a "disable_pac" realm relation to suppress adding PAC authdata
  to tickets, for realms which do not need to support S4U requests.

* Most credential cache types will use atomic replacement when a cache
  is reinitialized using kinit or refreshed from the client keytab.

* kprop can now propagate databases with a dump size larger than 4GB,
  if both the client and server are upgraded.

* kprop can now work over NATs that change the destination IP address,
  if the client is upgraded.

Developer experience:

* Updated the KDB interface.  The sign_authdata() method is replaced
  with the issue_pac() method, allowing KDB modules to add logon info
  and other buffers to the PAC issued by the KDC.

* Host-based initiator names are better supported in the GSS krb5
  mechanism.

Protocol evolution:

* Replaced AD-SIGNEDPATH authdata with minimal PACs.

* To avoid spurious replay errors, password change requests will not
  be attempted over UDP until the attempt over TCP fails.

* PKINIT will sign its CMS messages with SHA-256 instead of SHA-1.

Code quality:

* Updated all code using OpenSSL to be compatible with OpenSSL 3.

* Reorganized the libk5crypto build system to allow the OpenSSL
  back-end to pull in material from the builtin back-end depending on
  the OpenSSL version.

* Simplified the PRNG logic to always use the platform PRNG.

* Converted the remaining Tcl tests to Python.
-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEExEk8tzn0qJ+YUsvCDLoIV1+Dct8FAmKQAGgACgkQDLoIV1+D
ct9NnBAAxbuqwI/OQrXdCnMZyMMD3Oc4ODvx+5Zmt93owaZ4RSx6WwS8FNIlcFjX
C47JbF79uwh817GMGJUCdnH7pI+hxzBmxxs1F0j+7nLWF+vDs9mPHxMkWOiY9ZNu
8ADE3XRyHSgGOOb0zbndPS3RsbYnsHMQfbtNIbxNIJfyTF32wmPrsuGlhhEKEzu2
7m8V8DBfL5PwMLefsl8Mu45xqD8II7eg5HjIe7kmEbGseDS2C5XOrj4ieWm++0Pc
dfl1eHKyuCWkUaJyBBjIGRe+WL8D/OKRkXrtIgMcX7AwFdnRrMDqDduoD9vNQvGE
4PNcORkCdw4R7UWv2qXOvoxHKz/Bv6ctkd94FRsGoJrFeOIf+0L53y2Zf+s+ntVC
p70glQhcAZr/wdKPm2V1QmuIib+y7bZRBcIcbmEZcjexQaIzUHFdwMzm3Y8MAGJu
h8GZ7tktGAQWdgUKRFP2ZlDnUEl6a7GgmoOyUcgo2RxDgiunBcdgLVNeVkkEZCPv
xKdntPgcgrObb6J73JfHZLWBZ6bMpaEm9MziEP50ZvITlD2Q+CxyCJo9fbgqvhXf
z6JaNiVWR0blHGpQA8eeUW6bToEjndYPumxbGyRRfTIpcaAZYyeY9MFBiDJmDM98
U4oPRd15Ws1swsuc+EsJKUo+OiCLj7saF87WSE2Kke+SOfo8evA=
=aPCW
-END PGP SIGNATURE-
___
kerberos-announce mailing list
kerberos-annou...@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos-announce

Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Re: Always prompting for OTP

[Greg Hudson]

On 5/10/22 14:49, Russ Allbery wrote:
>> 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.

I will try to explain again.

The Kerberos protocol was designed to be somewhat resistant to phishing.
 If I set up a rogue KDC and somehow convince clients to authenticate,
the clients do not simply send me their passwords.  This resistance
isn't perfect; by asking for encrypted timestamp I can probably get the
client to send a ciphertext that I can use to conduct an offline attack,
and I can probably influence the client to use a fast string-to-key
function by pretending to only support an older encryption type.  But
it's still a goal.

FAST OTP does not have any phishing resistance, at least in the mode
that is used in practice.  Whatever the user types in as the OTP value
is simply sent to the KDC to be inspected raw.  On the positive side,
FAST OTP can only work over FAST, and one can presume that the FAST
armor key was obtained in a way that authenticates the KDC to the
client.  So it's not as easy to receive client authentications as a
rogue KDC as it would be in the original protocol.  But depending on the
scenario it might still be possible.  pam_krb5 has some idea of the
authentication scenario (it's a system login of some kind), but libkrb5
does not.

If an OTP client preauth module used the password as the OTP value, that
would make it easier for a KDC to completely subvert the phishing
resistance of the original Kerberos protocol.  Again, prompting
separately isn't a perfect solution as users confronted with an "Enter
OTP Token Value" prompt are as likely as not to simply re-enter the
password.  But it would still be worrisome.

> 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.

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.

Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Re: Always prompting for OTP

[Greg Hudson]

On 5/10/22 11:47, BuzzSaw Code wrote:
> I'm trying to understand if the behavior I'm seeing is by design or a bug.
[...]
> It seems like the original credentials that were passed in, which is the
> valid OTP "pin+password", are tossed by the krb5 library routines once the
> KDC responds asking for preauth and the anonymous FAST conversation is done
> no matter what.

This is by design.  The basic Kerberos protocol does not reveal the
password to the KDC, but FAST OTP does reveal the OTP value (encrypted
within the FAST channel).  So for libkrb5 to transparently send the
password to the KDC when the KDC asks for FAST OTP would have security
implications.

pam_krb5 could work around this decision via its prompter callback, and
that might be reasonable to implement as an option.

Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Re: Creating a principal using the kadmin C API

[Greg Hudson]

Many apologies; this got filed into my spam folder and I only just found it.

On 4/11/22 11:09, Teo Klestrup Röijezon wrote:
> profile_init_vtable() (or building it with profile_add_relation()) would be 
> ideal, yes. 
[...]
> However, the kadm5_init_*() family of functions (via init_any()) calls 
> kadm5_get_config_params(), which in turn always loads its own profile by 
> calling 
> krb5_aprof_init() with a hard-coded choice of either DEFAULT_PROFILE_PATH or 
> DEFAULT_KDC_PROFILE. This _is_ possible to override with environment 
> variables, but that's a pretty big ask when linking to the library in-process.

I think this is a bug; the init functions and kadm5_get_config_params()
should use the profile object from the context argument.  I have a
candidate patch that passes tests.

Unfortunately I don't think there's a viable workaround beyond the
options you have already considered.

Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Re: Creating a principal using the kadmin C API

[Greg Hudson]

On 4/7/22 16:19, Lars Francke wrote:
> We tried to use kadm5_create_principal_3 and kadm5_randkey_principal_3 but
> we seem to be running into an issue. Ideally we'd like to call this
> function with a handle (+ context) with an in-memory krb5.conf but that
> does not seem to work so we create the files and refer to them in the
> profile but kadmin still seems to load (is this related to the
> "alt_profile"?) a file from a default location which means it'll use the
> wrong connection details.

krb5_init_context_profile() lets you supply a profile object.  If this
is created with profile_init_path(), the application should be able to
strictly control which file is used.

It is possible to create an in-memory profile with
profile_init_vtable().  Perhaps it would be nicer if one could create an
empty in-memory profile object and populate it with
profile_add_relation(), but that is not currently implemented.

Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

krb5-1.19.3 and krb5-1.18.5 are released

[Greg Hudson]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

The MIT Kerberos Team announces the availability of MIT Kerberos 5
Releases 1.19.3 and 1.18.5.  Please see below for a list of some major
changes included, or consult the README file in the source tree for a
more detailed list of significant changes.

Retrieving krb5-1.19.3 and krb5-1.18.5
==

You may retrieve the krb5-1.19.3 and krb5-1.18.5 sources from the
following URL:

https://kerberos.org/dist/

The homepages for the krb5-1.19.3 and krb5-1.18.5 releases are:

https://web.mit.edu/kerberos/krb5-1.19/
https://web.mit.edu/kerberos/krb5-1.18/

Further information about Kerberos 5 may be found at the following
URL:

https://web.mit.edu/kerberos/


Triple-DES transition
=

Beginning with the krb5-1.19 release, a warning will be issued if
initial credentials are acquired using the des3-cbc-sha1 encryption
type.  In future releases, this encryption type will be disabled by
default and eventually removed.

Beginning with the krb5-1.18 release, single-DES encryption types have
been removed.


Major changes in 1.19.3 and 1.18.5 (2022-03-14)
===

These are bug fix releases.

* Fix a denial of service attack against the KDC [CVE-2021-37750].
-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEExEk8tzn0qJ+YUsvCDLoIV1+Dct8FAmIvtaAACgkQDLoIV1+D
ct8GUg/+L7k2DFp/2zS6yBggE8lQAjidO8tUoPXLRZ0Y+95pSCkQd+6DmMW1JX2Q
kBs/ka6BD9NKEaLELETQ1B2GDVIrJXR5H7K9dtzqej4hrOnX7BCWsBsTwyT5hv/0
CtyMo1oTIYSC41jgoav4hFJhcAM6001a9whvygRh2zYxylWc2mHJ9f9+J0xVw1qg
wY7s3wFXf+iPu1E89cgDw7ln3zJNPu22iBoRLoOHs/2NxyVRL+NBPftUg7GfDeNz
hSQ+nrgaJE6x/RkTR8F3OA/GjqdkYVwR1Rvp0qJcaRit9747cIpeNzd7Lr5H0GZW
0qIAv6qjJ26uhXNpLHogAO1Fsyiz8Ir31NGHO3ah0cwAbciZOFsZNE2V7NNVsGEx
jl+0uUVp3ydPf6EMB1F3puzv4Wv0YtBMyA0lojSzeKR1pPQ5ZAkWCbOX+eR2x7YO
/Z1eGlzSZSi48ohKSRm7ULNRCdONlITtB7cupAF0Y6azUhabETwEQImoKQMus0PF
aSX+SyaksNv0RZKmNaVGBaZe70HFx7XX01fTgvYTBSq0J7+d03jYpTfceoaeykmo
gaGmrGI2swPgH/6Y3VeBpD9/Zq/iM+orZr0IChcw94uHMxGUvzCcW8DN7qR05JT/
fUqkq4xsdWr6ZVuxyrN62Fv4fBgQA2NLar1Bn9i3/UY3L6Ol5eM=
=y/2g
-END PGP SIGNATURE-
___
kerberos-announce mailing list
kerberos-annou...@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos-announce

Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Re: KDC timeout for MIT Kerberos?

[Greg Hudson]

On 2/9/22 12:49 PM, Russ Allbery wrote:
> 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?

There's no configuration setting.  An application can install a send
hook (krb5_set_kdc_send_hook()), but that would require reimplementing a
lot of logic just to change the timeout.

Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Re: Replica KDC has no support for encryption type

[Greg Hudson]

On 2/4/22 2:19 AM, Dr. Lars Hanke wrote:
> additional info: SASL(-1): generic failure: GSSAPI Error: Unspecified 
> GSS failure.  Minor code may provide more information (KDC has no support for 
> encryption type)

It might help to compare the KDC log entry for this TGS request on the
old and new KDC.

During a TGS request, "KDC has no support for encryption type" can mean
that the KDC could not select an encryption type for the session key.
The session key enctype must be present in (1) the enctypes listed in
the KDC request, (2) the KDC's permitted_enctypes if set, and (3) the
enctypes supported by the server DB entry (which is usually the enctypes
of the server's long-term keys, unless overridden by the
session_enctypes string attribute).

Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Re: Debugging why KRB5_KTNAME isn't working

[Greg Hudson]

On 1/27/22 12:01 PM, Brian J. Murrell wrote:
> I am trying to debug why having KRB5_KTNAME set in the environment of a
> process is not actually making that process use that keytab file but
> instead is using the default /etc/krb5.keytab.

There are three possible reasons why environment variables might be
ignored.  First, Postfix might be asking for a secure krb5 context
(krb5_init_secure_context()).  Second (and I think the most likely), the
process may be running with elevated privilege as determined by
secure_getenv().  A setuid or setgid bit on the executable could be
enough to trigger this.  Third, as Ken suggested, the program might
clean up its own environment.

If any of these are true, then you have limited options to affect the
program behavior from outside of the process.  You can change the
default keytab location in /etc/krb5.conf, but that would be global (and
of course you can't point the program at a different config file via
environment variable because those are ignored).

Of course, the program itself can provide configuration for the keytab
file.  I couldn't find any gss_ or krb5_ calls in the Postfix source
code (looking at Viktor Dukhovni's git mirror), so I don't have any
immediate insight as to whether that's currently possible or what would
need to change.

Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Re: Internal credentials cache error for server principal - 1765328188

[Greg Hudson]

On 1/5/22 7:52 AM, Vato Kvantaliani wrote:
> Error: Unspecified GSS failure. Minor code may provide more information
> (Internal credentials cache error)

This error message came up in April:

https://mailman.mit.edu/pipermail/kerberos/2021-April/022630.html

It's hard to be sure that the cause is the same without knowing more
about the setup.  In that case the cause was multiple threads or
processes trying to refresh the ccache from a client keytab at the same
time.

To address this issue, I implemented atomic replacement for most
credential cache types:

https://github.com/krb5/krb5/commit/371f09d4bf4ca0c7ba15c5ef909bc35307ed9cc3

However, it will be some time before this works its way into a Kerberos
for Windows release.  I'm not sure I can offer concrete advice since I
am not familiar with PowerBI.

Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Re: Correct procedure to add a new enctype

[Greg Hudson]

On 12/16/21 4:38 AM, Dario García Díaz-Miguel wrote:
> Currently we have two supported and default enctypes for tkt and tgs. 
> However, now we have an application that does not support our current 
> supported enctypes so we have to add a new enctype.
> 
> Which is the correct procedure to add this enctype and to generate an 
> additional key for this enctype for each principal involved?
> 
> I suppose that the enctype used will be the strongest one of the supported 
> enctype keys existing for that principal.

You need to ensure the following:

* If the KDC has a permitted_enctypes setting, it needs to include the
new enctype.

* Server principals for the application must have a long-term key of
only that enctype (use "-e enctype" when provisioning the keytab).

* Clients must include that enctype in TGS requests they make.  This is
controlled by default_tgs_enctypes, or (in 1.18 and later) by
permitted_enctypes if default_tgs_enctypes isn't set.

It should not be necessary to change supported_enctypes.

The krb5 libraries do not have a concept of relative enctype strength.
Instead, they go by preference order when multiple enctypes are listed.
 So make sure to list the better ones first.

For more information, see:

https://web.mit.edu/kerberos/krb5-latest/doc/admin/enctypes.html

Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Re: 2FA with krb5

[Greg Hudson]

On 10/8/21 7:45 AM, Ken Hornstein wrote:
>> I mean, this might be dumb, but why not have the kdc able to speak to
>> pam modules directly?

> Kerberos is "I am going to take your password which I already know,
> convert it into an encryption key, and use it to verify your Kerberos
> request".  Kerberos needs to know the password/factor to make that
> happen, where the typical 2FA API only tells you "is this token good
> or not?".

I think Dan was assuming one of the cases where the KDC received a 2FA
value and needs an oracle, such as FAST OTP.

One concern is that PAM modules must operate synchronously (unless I'm
badly mistaken), so the KDC process would be blocked if the module has
to talk to a remote server.  You can get away with that if your
population of 2FA users is small and the oracle is fast, but OTP oracles
are often deliberately slow to answer.  We developed an async kdcpreauth
interface and async RADIUS code to address that problem for FAST OTP.

Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Re: Compiling krb5-1.18.4 on Linux

[Greg Hudson]

On 10/5/21 3:24 PM, Jim Shi wrote:
> configure: error: cannot compute sizeof (time_t)
> See `config.log' for more details

This error typically means the compiler configuration isn't working at
that point in the autoconf script, and you have to (as suggested) look
at config.log for more details to determine why.

Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Re: supported enctypes: what is the net effect of removing 3des?

[Greg Hudson]

On 10/3/21 5:34 AM, Dan Mahoney (Gushi) wrote:
> My reading of "supported_enctypes" is simply that it will stop kadmin/the 
> KDC from generating NEW keys of an older type, correct?

Correct.  (The KDC doesn't generate long-term keys, so only
kadmind/kadmin.local and kdb5_util are affected.  Also note that a
kadmin client can specify an enctype/salttype list when creating new key
sets, in which case supported_enctypes is ignored.)

> That if I do a 
> cpw without -keepold, those keys will be removed -- but otherwise, the KDC 
> will not act as though a user with 3des-only keys doesn't exist.

Correct.  Removing an enctype from permitted_enctypes causes the KDC to
ignore keys of that type, but supported_enctypes is only about new
long-term keys.

> Changing it should not break any authentication or tickets?

Correct.

Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Re: master key type in kdc.conf

[Greg Hudson]

On 10/3/21 3:36 AM, Dan Mahoney (Gushi) wrote:
> We're in the process of rolling our mkey to get off 3des, and we found 
> that someone in the before-times has put this line in our kdc.conf:
> 
> master_key_type = des3-hmac-sha1
[...]
> Would things break if I just took this line out?  Or would the kdc fail to 
> start because a K/M of the default enctype isn't present yet?

>From a review of the code, I am pretty sure that this setting is only
used when the mkey is entered from the keyboard (including during KDB
creation).  Assuming you are using a stash file, you should be able to
remove this setting.

Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Re: kfw-4.1: ms2mit in virtual setups?

[Greg Hudson]

On 9/17/21 5:14 PM, John Devitofranceschi wrote:
> I can see that “AllowTGTSessionKey” is set to ‘1’ in the virtual registry.  
> Is that not sufficient? Any way around this?

The current documentation of AllowTgtSessionKey says: "With active
Credential Guard in Windows 10 and later versions of Windows, you cannot
enable sharing the TGT session keys with applications anymore."  That's
from:
https://docs.microsoft.com/en-us/troubleshoot/windows-server/windows-security/kerberos-protocol-registry-kdc-configuration-keys

There's more on Credential Guard at:
https://docs.microsoft.com/en-us/windows/security/identity-protection/credential-guard/credential-guard

Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Re: Query regarding S4U2Self protocol extension

[Greg Hudson]

On 7/23/21 4:38 PM, Vipul Mehta wrote:
> I did some testing with Windows KDC and it will set forwardable flag in
> S4U2Self service ticket in either of the following cases:
> 
> 1) TrustedToAuthForDelegation is set to true in Service A account.
> 
> 2) Service A TGT used in S4U2Self has forwardable flag set and
> msDS-AllowedToDelegateTo list is empty on Service A account.
> I am not able to understand why msDS-AllowedToDelegateTo needs to be empty
> in the 2nd case.
> 
> Is the behavior of MIT KDC the same as Windows KDC ?

We have an analog of the TrustedToAuthForDelegation flag, called
ok_to_auth_as_delegate.  We don't check for an empty
allowed-to-delegate-to list.

> Service ticket used in S4U2Proxy need not be forwardable if resource
> based constrained delegation is used i.e.
> principalsAllowedToDelegateTo option is
> configured on Service B.

Note that, as of 2019, the forwardable flag must be set on the evidence
ticket if the delegation is authorized in both directions (on the
intermediate service and the target service).  We implemented this
counterintuitive behavior in the MIT KDC for consistency.

There is some reason to think this might be changing.  This article
(noted by Isaac):

https://support.microsoft.com/en-us/topic/managing-deployment-of-rbcd-protected-user-changes-for-cve-2020-16996-9a59a49f-20b9-a292-f205-da9da0ff24d3

talks about a protection measure that "unifies the logic for
Resource-Based Constrained Delegation (RBCD) with the original
constrained delegation."  We have asked Microsoft for clarification.

Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

krb5-1.19.2 and krb5-1.18.4 are released

[Greg Hudson]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

The MIT Kerberos Team announces the availability of MIT Kerberos 5
Releases 1.19.2 and 1.18.4.  Please see below for a list of some major
changes included, or consult the README file in the source tree for a
more detailed list of significant changes.

Retrieving krb5-1.19.2 and krb5-1.18.4
==

You may retrieve the krb5-1.19.2 and krb5-1.18.4 sources from the
following URL:

https://kerberos.org/dist/

The homepage for the krb5-1.19.2 and krb5-1.18.4 releases are:

https://web.mit.edu/kerberos/krb5-1.19/
https://web.mit.edu/kerberos/krb5-1.18/

Further information about Kerberos 5 may be found at the following
URL:

https://web.mit.edu/kerberos/


Triple-DES transition
=

Beginning with the krb5-1.19 release, a warning will be issued if
initial credentials are acquired using the des3-cbc-sha1 encryption
type.  In future releases, this encryption type will be disabled by
default and eventually removed.

Beginning with the krb5-1.18 release, single-DES encryption types have
been removed.


Major changes in 1.19.2 and 1.18.4 (2021-07-22)
===

These are bug fix releases.

* Fix a denial of service attack against the KDC encrypted challenge
  code [CVE-2021-36222].

* Fix a memory leak when gss_inquire_cred() is called without a
  credential handle.
-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEExEk8tzn0qJ+YUsvCDLoIV1+Dct8FAmD/BgkACgkQDLoIV1+D
ct97ZQ/+LC3g5O11HvP268D0UXG/rKX308J8+AfbSmfQoUkJ/g7FT/ruoV5b9H38
vMZoEeDS0irAl6w4a4Y8HlHJs1McL+5SFo9DG/0dmLt8MVFW5qmDuaiHqkxz1Pzz
n8/54YXDu5/mpVAW5WVyfiMVW5yGx8ty4RnupF9Ko9mv/SbplAL2NwZzweDQUyaH
5F1krQ08fd8AutN+Rl42IwInNOLoiV0+PotQZGPqhJL6OGYyURVUfOb7XexrNFMQ
JwKUOsCyD4SpJ01a7QPl5IKlUzZlomLh+gvZlCIK3Ke9mVpM5DeaGVOmI3F4tHWd
ZFO4g7t6lfnLIqyZO8o2gfCP11G9P7I1OeOPoLBIP0HU2gdMFU/tfq7xqDFPYHAR
Dh3BxBYAKb02LWOY9zZWVEe0GOQ1cano6QYeyYtuVBqJVqqGG0omXdqJsPyFj4BO
HtzRk1PqWRFshAL7ABdmwUYbAg7FXH0tQBte34CzdVQZhOQxBcaSO950K1crn73X
VQh0OUlL9EFG8CJ3Lxck/VUtv4onp+X9mkGFkDd8tTkPhEbhTr7Jx5RZZ/oOvdVn
mAbXBBeLIjqWQfs2MngH9jVytfoG8o5mKA7iQnt68BUL0u0jKPupUTGV4rV0BebB
CwWUyWbIEisuv5rF6aa4CoU2vXcdtnZ12vl89TkwQw3zA+V1vaQ=
=68WE
-END PGP SIGNATURE-
___
kerberos-announce mailing list
kerberos-annou...@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos-announce

Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Re: gss_localname() with multiple KDC/User Directories + Apache + mod_auth_gssapi

[Greg Hudson]

On 7/19/21 10:32 AM, Tobias Kritten (EXT) wrote:
> [libdefaults]
> default_realm = WORKSTATION.OFFICE
> [realms]
[...]
> WORKSTATION.OFFICE= {
[...]
> }
> CORPORATE.LOCAL = {
[...]
>   auth_to_local = RULE:[1:$1@$0](.*@CORPORATE\.LOCAL)s/@.*//
> }

auth_to_local is always looked up in the default realm, not in the realm
of the principal being authorized.  This is why the rule has to do the
annoying dance of explicitly including the realm in the [] part,
matching it in the () part, and removing it in the s// part.  Fixing
this historical botch isn't trivial since the obvious fixes would be
likely to break existing deployments.  (The same problem applies to
auth_to_local_names, which is even worse since there's no workaround
aside from not doing any cross-realm.)

> [Tue Jul 06 12:08:41.148773 2021] [auth_gssapi:error] [pid 30765:tid 
> 140024582170368] [client 192.168.212.52:0] GSS ERROR gss_localname() failed: 
> [The operation or option is not available or unsupported (No such file or 
> directory)]

The error message is obscured due to a fallback in the mechglue with
insufficient attention to error prioritization.  Better prioritization
would yield GSS_S_FAILURE with a minor code of KRB5_NO_LOCALNAME ("No
local name found for principal name").

Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Re: weak regex/glob in listprincs in kadmin (on ldap)?

[Greg Hudson]

On 7/11/21 9:23 PM, Chris Hecker wrote:
> From looking at the code in src/lib/kadm5/srv/svr_iters.c 
> 
>  
> it seems like the listprincs command should support [] patterns like 
> che[ca]* but it doesn't in my version (1.15.1 on centos with ldap 
> backend).  listprincs chec* works of course.

With the LDAP KDB module, the expression is applied at the KDB layer via
an LDAP filter expression, as well as at the libkadm5 layer.  LDAP
filter expressions can only handle '*' globbing.  Possibly the LDAP KDB
module should check if [] or ? is in the glob pattern and return all
results (like the other KDB modules do for all match expressions).

> Is there a recommended way of using the kadm5 interface to iterate 
> through tons of principals? [...] I'm trying figure out which princs
> have passwords that are about to expire.

You might try "kdb5_util tabdump -n princ_tktpolicy" if you can run on a
KDC, or variations of that.

Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Re: Radius failover server for OTP Preauthentication

[Greg Hudson]

On 6/18/21 11:59 AM, Abdelkader Chelouah wrote:
> It is my understanding that the *server* field (radius server) accepts 
> only one *host:port* endpoint. For high availability purpose, is it 
> possible to specify multiple endpoint ?

It is not.  The recommended approach for this is to run a local RADIUS
proxy server on the KDC host.

Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Re: Retiring Triple-DES

[Greg Hudson]

On 5/18/21 12:38 AM, Dan Mahoney (Gushi) wrote:
> Are there any plans to make a similar page regarding triple-des?  (We're 
> undergoing this at the day job, after having 3des as our single allowed 
> enctype).  It would be useful to hae a current checklist.

See:

http://web.mit.edu/kerberos/krb5-latest/doc/admin/enctypes.html#migrating-away-from-older-encryption-types

Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Re: Version 1.19.1 compilation issue - RedHat Linux

[Greg Hudson]

On 5/12/21 8:17 AM, Vipul Mehta wrote:
> Getting following error:
> gic_keytab.c:185: error: ‘etype_list’ may be used uninitialized in this
> function

This is a false positive (etype_list can only be used uninitialized if
k5_canonprinc() returns zero candidates without erroring out, and it
doesn't do that).  But I will likely add an initializer for etype_list
as I think the function is clearer that way.

In general I found that maybe-uninitialized warnings are almost always
false positives and depend a lot on the compiler version, which is why I
attempted to turn them off.  Apparently that's not possible in that
particular version of gcc, without also turning off errors for
-Wuninitialized (which are much less likely to be false positives).

> At top level:
> cc1: warning: unrecognized command line option "-Wno-maybe-uninitialized"

> In config.log, i can see that configure script is not able to identify that
> the option is not supported as gcc gives warning instead of error:

Interesting.  More recent versions of gcc seem to silently ignore
unrecognized -Wno- flags, while clang continues to print a warning
rather than error.

This is a minor problem, but having a working test for -Wno- options
would be an improvement.

> It compiles fine if i remove "error=uninitialized" to allow uninitialized
> variables.
> Is it safe to compile without it ?

Yes.

> What is the version of gcc used to build and test MIT Kerberos in dev
> environment ?

At the moment, gcc 7.5.0 in my dev environment, plus whatever version of
gcc is on the Github Actions runners.

Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Re: Integration of Duo with MIT Kerberos?

[Greg Hudson]

On 4/26/21 2:36 PM, Ben Poliakoff wrote:
> On that thread there was some talk about MIT's implementation, possible
> eventual open sourcing of said implementation and/or creating a
> newer/cleaner implementation using SPAKE-2.
> 
> Did anything ever come if this? We'd certainly love to be able to
> selectively integrate second factors such as Duo with our MIT krb5 KDCs.

Unfortunately no.  The MIT implementation isn't in a releasable state,
and we haven't made any significant progress on implementing second
factors in SPAKE.

Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Re: Is there a "batchable" way to do ktutil list

[Greg Hudson]

On 4/21/21 3:56 AM, Dan Mahoney (Gushi) wrote:> Dayjob has a puppet fact
that, under freeBSD, uses "ktutil list" to get
> the kvno of a given host.
[...]
> Is there another command that is more script-friendly?  If not, can 
> someone share a good way to pass args to the MIT ktutil?

I think you want klist -k.  (Dameon suggested k5srvutil; its "list"
subcommand just runs klist -k.)

Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Re: Concurrency issues with FILE ccache

[Greg Hudson]

On 4/9/21 11:35 AM, Osipov, Michael (LDA IT PLM) wrote:
> I am quite sure that this is a race condition where stat() is performed,
> file does not exist, open() with write is performed, in parallel it is
> already created and the later call returns in EEXIST.

I agree, except I think it's just unlink() and open(O_CREAT|O_EXCL)
calls with no stat().  I had erroneously assumed that the unexpected
error was happening inside fcc_store() because of "Failed to store
credentials" in the message, but that string turns out to be from
get_in_tkt.c in a block of code that also calls krb5_cc_initialize().

The fcc_initialize() EEXIST self-race has existed since 1.0.  I'd
speculate that the original developers' assumption was that lots of
processes might be competing to use a file ccache, but that creating
ccaches would be a rare and one-at-a-time affair (happening at login or
when a user runs "kinit").  With client keytab support, that is no
longer the case; it's easy to have multiple threads or processes
competing to create or refresh a cache as part of gss_acquire_cred() or
gss_init_sec_context().

Just fixing the fcc_initialize() race wouldn't really solve the problem;
there would still be a window between krb5_cc_initialize() and
krb5_cc_store_cred() where other threads (or processes) would see an
initialized cache with no TGT in it, and would fail the
gss_init_sec_context() call.  This ticket describes that problem and
some possible solutions:

  https://krbdev.mit.edu/rt/Ticket/Display.html?id=7707

Heimdal has implemented option 5.  I'm not wild about it and it won't
work with other ccache types, but it's a working stopgap and it can
always be backed out in favor of a different solution later.

Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Re: Adding thread id to KRB5_TRACE format output

[Greg Hudson]

On 4/6/21 11:58 AM, Osipov, Michael (LDA IT PLM) wrote:
> based on some debugging issues it would be really helpful to see after 
> [] also the [] in KRB5_TRACE output. As far as I can see it is 
> printed in krb5int_trace(). Unfortunately, there is no portable (POSIX) 
> way to retrieve to retrieve it. Luckily, I have extended some code in 
> Tomcat Native recently to cover this on several platforms [1]. Code for 
> even more BSDs can be found here [2].

You can file a ticket by sending mail to krb5-b...@mit.edu.

There are some challenges to making this work, particularly the weak
binding we have between libkrb5/libkrb5support and libpthreads on some
platforms.  But it's probably doable.


Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Re: Concurrency issues with FILE ccache

[Greg Hudson]

On 4/6/21 11:48 AM, Osipov, Michael (LDA IT PLM) wrote:
> gssapi.raw.misc.GSSError: Major (851968): Unspecified GSS failure.  Minor 
> code may provide more information, Minor (11): Failed to store 
> credentials: Internal credentials cache error (filename: /tmp/krb5cc_1000)

This is not expected, and bears investigation.  It suggests an EINVAL,
EEXIST, EFAULT, EBADF, or EWOULDBLOCK error from one of the I/O
operations performed by fcc_store(), none of which are expected.  If
you're building libkrb5, you could try modifying interpret_error() to
pass those error codes through in order to find out which one is happening.

Getting multiple cache entries for a service is normal when multiple
threads or processes initiate contexts to the same (new) service within
a short window.

Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Re: GSSAPI sequence numbers

[Greg Hudson]

On 3/26/21 3:26 PM, Jake Scott wrote:
> I took the naive approach of handling the initial sequence numbers by
> simply casting the uint32 value from the authenticator and AP-REP encpart
> to uint64.  However that causes compatibility issues with the MIT
> implementation that appears to cast first to a signed int32 and then to the
> GSSAPI uint64.

I think that may have been a bug introduced in 2008.  In release 1.6,
the GSSAPI code fetched the Kerberos sequence number into a uint32, but
using a function accepting an int32 *, which caused compiler warnings.
Commit abcfdaff756631d73f49103f679cafa7bc45f14e (later merged in commit
0ba5ccd7bb3ea15e44a87f84ca6feed8890f657d) the warnings were squashed by
changing the variable to an int32, apparently without regard to the
behavior change for Kerberos sequence numbers in the 2^31..2^32-1 range.

Due to earlier history with sequence number and ASN.1 encoding bugs, MIT
and Heimdal both generate Kerberos sequence numbers in the range
0..2^30-1 by masking with 0x3FFF (see krb5_generate_seq_number() in
both implementations).  I would speculate that Microsoft and Java do the
same.  That could explain why the behavior change might have gone unnoticed.

Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Re: Sanity checking asn.1_encode patch

[Greg Hudson]

On 3/18/21 4:53 PM, Tony Rodriguez wrote:
> I am new to kerberos.   How can I sanity test that recursion within 
> asn.1_encode stops after 31? Does kerberos have any command line 
> utilities to test asn.1_encode?  If so, what are they and which 
> parameters must I pass? If not, does someone have example code that I 
> can compile to test the recursion level logic works as expected?

I've attached the test program I wrote to verify the problem.  Run it
with a numeric buffer size argument.  With the unpatched code I was able
to produce a stack overflow with a buffer size of 9.
#include 
#include 
#include 

krb5_error_code
decode_krb5_ap_req(const krb5_data *output, krb5_ap_req **rep);

int main(int argc, char **argv)
{
char *buf;
size_t i, len = atoi(argv[1]);
krb5_data d;

assert(len % 2 == 0);
buf = malloc(len);
for (i = 0; i < len; i += 2) {
buf[i] = 0x6e;
buf[i + 1] = 0x80; /* indefinite length */
}
d.data = buf;
d.length = len;
#ifdef HEIMDAL
krb5_ap_req r;
krb5_decode_ap_req(NULL, &d, &r);
#else
krb5_ap_req *r;
decode_krb5_ap_req(&d, &r);
#endif
return 0;
}


Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

krb5-1.19.1 is released

[Greg Hudson]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

The MIT Kerberos Team announces the availability of MIT Kerberos 5
Release 1.19.1.  Please see below for a list of some major changes
included, or consult the README file in the source tree for a more
detailed list of significant changes.

RETRIEVING KERBEROS 5 RELEASE 1.19.1


You may retrieve the Kerberos 5 Release 1.19.1 source from the
following URL:

https://kerberos.org/dist/

(The distribution URL has changed from previous releases.  The same
contents are available at the old URL.)

The homepage for the krb5-1.19.1 release is:

https://web.mit.edu/kerberos/krb5-1.19/

Further information about Kerberos 5 may be found at the following
URL:

https://web.mit.edu/kerberos/

and at the MIT Kerberos Consortium web site:

https://www.kerberos.org/


Triple-DES transition
=

Beginning with the krb5-1.19 release, a warning will be issued if
initial credentials are acquired using the des3-cbc-sha1 encryption
type.  In future releases, this encryption type will be disabled by
default and eventually removed.

Beginning with the krb5-1.18 release, single-DES encryption types have
been removed.


Major changes in 1.19.1 (2021-02-18)


This is a bug fix release.

* Fix a linking issue with Samba.

* Better support multiple pkinit_identities values by checking whether
  certificates can be loaded for each value.

Major changes in 1.19 (2021-02-01)
==

Administrator experience:

* When a client keytab is present, the GSSAPI krb5 mech will refresh
  credentials even if the current credentials were acquired manually.

* It is now harder to accidentally delete the K/M entry from a KDB.

Developer experience:

* gss_acquire_cred_from() now supports the "password" and "verify"
  options, allowing credentials to be acquired via password and
  verified using a keytab key.

* When an application accepts a GSS security context, the new
  GSS_C_CHANNEL_BOUND_FLAG will be set if the initiator and acceptor
  both provided matching channel bindings.

* Added the GSS_KRB5_NT_X509_CERT name type, allowing S4U2Self
  requests to identify the desired client principal by certificate.

* PKINIT certauth modules can now cause the hw-authent flag to be set
  in issued tickets.

* The krb5_init_creds_step() API will now issue the same password
  expiration warnings as krb5_get_init_creds_password().

Protocol evolution:

* Added client and KDC support for Microsoft's Resource-Based
  Constrained Delegation, which allows cross-realm S4U2Proxy requests.
  A third-party database module is required for KDC support.

* kadmin/admin is now the preferred server principal name for kadmin
  connections, and the host-based form is no longer created by
  default.  The client will still try the host-based form as a
  fallback.

* Added client and server support for Microsoft's KERB_AP_OPTIONS_CBT
  extension, which causes channel bindings to be required for the
  initiator if the acceptor provided them.  The client will send this
  option if the client_aware_gss_bindings profile option is set.

User experience:

* kinit will now issue a warning if the des3-cbc-sha1 encryption type
  is used in the reply.  This encryption type will be deprecated and
  removed in future releases.

* Added kvno flags --out-cache, --no-store, and --cached-only
  (inspired by Heimdal's kgetcred).
-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEExEk8tzn0qJ+YUsvCDLoIV1+Dct8FAmAu0XMACgkQDLoIV1+D
ct9bWxAAgl5LWF577CRqroFq3xtkBioS4hIO7grm2f2D22xrF162ydXVERT1ZFZX
SRfPdaS1sqZz+oxGgZuOJEBVJTqtdwim4LJYuAJErUxJiOlXSKXOrZa0RQM62yYG
BiSrf3UDqI2DV5OsC3WCuHCyoSBsf0fjumxPA2o53o68xfRNfU+q9CtLmDsUIkmS
1xihBVCUDpyj2WKqn0kwFIi/Rnm2R3hGLizBOXx3ndyA3LoALHBK9UWht0NnBOgY
X/ebRuERWUPTbC8kWOKSt+pVCmDxskeJjqXvjw82vkIZZVXzDA6Q8eBKy9d0FIrK
laUvuZ4lGQyjaeWmJF/nk1K1QrNe41gt5RR9o6pLLL40ZkP1BG+bSr459yHRBeNz
XoWz1/xn5wsGu+ZBM4UCbEsBV2dvuKwC+6ufrDWzFXq/DEF+YVGbnByPydr21mhe
cNiNLo1G1kIRdh3wkVDPU4giW2KB5EnobSVpzLDl3xLyVGpD08Y6MHU7s64wNBN1
HEbxzP4gmGHXJdFZGAUrt9TKPEMIw42L8bAR9UBNVHJglmglwdehVHMTqQqt2zxn
Qm3Yj+ytQlrJTwJ8pUSHX6r5d9Uw6AwVNpwqq7h9O2+/oEVboqK2Ejwz3PZyEv/K
g9a8YYHRcHMLy641ImsB91sB3IKIEcdXm12i34zcCuQPpaj0G8k=
=SeZu
-END PGP SIGNATURE-
___
kerberos-announce mailing list
kerberos-annou...@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos-announce

Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

krb5-1.19 is released

[Greg Hudson]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

The MIT Kerberos Team announces the availability of MIT Kerberos 5
Release 1.19.  Please see below for a list of some major changes
included, or consult the README file in the source tree for a more
detailed list of significant changes.

RETRIEVING KERBEROS 5 RELEASE 1.19
==

You may retrieve the Kerberos 5 Release 1.19 source from the
following URL:

https://kerberos.org/dist/

(The distribution URL has changed from previous releases.  The same
contents are available at the old URL.)

The homepage for the krb5-1.19 release is:

https://web.mit.edu/kerberos/krb5-1.19/

Further information about Kerberos 5 may be found at the following
URL:

https://web.mit.edu/kerberos/

and at the MIT Kerberos Consortium web site:

https://www.kerberos.org/


DES no longer supported
===

Beginning with the krb5-1.19 release, single-DES encryption types are
no longer supported.


Major changes in 1.19 (2021-02-01)
==

Administrator experience:

* When a client keytab is present, the GSSAPI krb5 mech will refresh
  credentials even if the current credentials were acquired manually.

* It is now harder to accidentally delete the K/M entry from a KDB.

Developer experience:

* gss_acquire_cred_from() now supports the "password" and "verify"
  options, allowing credentials to be acquired via password and
  verified using a keytab key.

* When an application accepts a GSS security context, the new
  GSS_C_CHANNEL_BOUND_FLAG will be set if the initiator and acceptor
  both provided matching channel bindings.

* Added the GSS_KRB5_NT_X509_CERT name type, allowing S4U2Self
  requests to identify the desired client principal by certificate.

* PKINIT certauth modules can now cause the hw-authent flag to be set
  in issued tickets.

* The krb5_init_creds_step() API will now issue the same password
  expiration warnings as krb5_get_init_creds_password().

Protocol evolution:

* Added client and KDC support for Microsoft's Resource-Based
  Constrained Delegation, which allows cross-realm S4U2Proxy requests.
  A third-party database module is required for KDC support.

* kadmin/admin is now the preferred server principal name for kadmin
  connections, and the host-based form is no longer created by
  default.  The client will still try the host-based form as a
  fallback.

* Added client and server support for Microsoft's KERB_AP_OPTIONS_CBT
  extension, which causes channel bindings to be required for the
  initiator if the acceptor provided them.  The client will send this
  option if the client_aware_gss_bindings profile option is set.

User experience:

* kinit will now issue a warning if the des3-cbc-sha1 encryption type
  is used in the reply.  This encryption type will be deprecated and
  removed in future releases.

* Added kvno flags --out-cache, --no-store, and --cached-only
  (inspired by Heimdal's kgetcred).
-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEExEk8tzn0qJ+YUsvCDLoIV1+Dct8FAmAYjoQACgkQDLoIV1+D
ct9NVxAAxALOYNGBunYb2tCBl0xud82lf3VQyJAx+H4X1UyJ/inzWMzXGPP8RXmF
fAalZ2NoojUm5crPQ7xyMvHjrLPxEujK7pxL2Cw5RIvIaxivTXNk2CLQ5XXQTL/m
Sg2cl5nICr7pggplgFeXUROaZ7XK+qtCJZM+hBXkISfAVo4AHKK3EJc4SYaZYl/c
JrAHdvE6dzVeuNNvAAlJvI6an6bcFRZTzF7XyXxVb58uiSfR0ymMpt+tDkHLB68h
XxPVqTsAkOLccCEpp/fCi8zUh/Ga/VtPG2OxRl5kz0rdqJLYm5lomh90RaAb6GXc
nADhla3vldRSOTDPUmK8d9nJnHGD0svy8VLTi4o7CaYFKTJ4Thy2IlimhRJBPJPH
mJ1QoHEghaOvXhxFp8YKbFMr7DKqM4FfXMfPTTng9cOPyqBEbIirimaGEfMMlz+h
bij/So8U5Eeo5czktfWjPDPoSzpeE9xj08WGBbC5xs+pH+heIxrdNFekiDLGmVKb
ABwF543XqgUXpykpYUw6zXWq2ME8J+TPT/tGvnbD7o585Fw1CCwZyM5+2lxozP44
XJvKQjzlhnl2xYzGEAHMoqmMBTYx2Jz0WbHpBAQgyWPT3vY2d+MQGZOqjlIesHvJ
Jvalvgj4Ey3sAJnH4AdcWbAvINp8fgZrS9DEtYD7iI6kRxbr0Fc=
=mmNx
-END PGP SIGNATURE-
___
kerberos-announce mailing list
kerberos-annou...@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos-announce

Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Re: Kerberos for Windows Logging

[Greg Hudson]

On 1/28/21 11:59 AM, Patrick Norman wrote:
> Hey all, I am looking into using Kerberos for Windows in a POC I am doing.
> I am having trouble getting logging to work

The [logging] section is for krb5kdc and kadmind, which are not part of
the Windows build.

If you want to use trace logging, just set the KRB5_TRACE environment
variable to a filename.

Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Re: Detecting Crypto backend

[Greg Hudson]

On 1/21/21 12:12 PM, rachit chokshi wrote:
> Any pointers on how to find out current backend used by an installation?

We don't have an interrogation mechanism and the runtime behavior is to
mostly indistinguishable, but on Linux or similar you can use OS
mechanisms.  ldd on libk5crypto.so.3.1 should show a dependency on
libcrypto, nm should show dependencies on EVP functions, and sotruss on
kinit or kvno should show calls into libcrypto.

Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

krb5-1.17.2 is released

[Greg Hudson]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

The MIT Kerberos Team announces the availability of MIT Kerberos 5
Release 1.17.2.  Please see below for a list of some major changes
included, or consult the README file in the source tree for a more
detailed list of significant changes.

RETRIEVING KERBEROS 5 RELEASE 1.17.2


You may retrieve the Kerberos 5 Release 1.17.2 source from the
following URL:

https://kerberos.org/dist/

(The distribution URL has changed from previous releases.  The same
contents are available at the old URL.)

The homepage for the krb5-1.17.2 release is:

https://web.mit.edu/kerberos/krb5-1.17/

Further information about Kerberos 5 may be found at the following
URL:

https://web.mit.edu/kerberos/

and at the MIT Kerberos Consortium web site:

https://www.kerberos.org/

Feedback based on experiences with the SPAKE pre-authentication
mechanism and the LMDB-based KDB module would be greatly appreciated,
as it will help us decide when these features are ready to become
defaults in a future release.  Please send feedback to
kerberos at mit.edu.


DES transition
==

The Data Encryption Standard (DES) is widely recognized as weak.  The
krb5-1.7 release contains measures to encourage sites to migrate away
from using single-DES cryptosystems.  Among these is a configuration
variable that enables "weak" enctypes, which defaults to "false"
beginning with krb5-1.8.


Major changes in 1.17.2 (2020-11-17)


This is a bug fix release.

* Fix a denial of service vulnerability when decoding Kerberos
  protocol messages.

* Fix a locking issue with the LMDB KDB module which could cause KDC
  and kadmind processes to lose access to the database.

* Fix an assertion failure when libgssapi_krb5 is repeatedly loaded
  and unloaded while libkrb5support remains loaded.

* Fix a null deference when processing a CAMMAC with an invalid
  service verifier.

Major changes in 1.17.1 (2019-12-11)


This is a bug fix release.

* Fix a bug preventing "addprinc -randkey -kvno" from working in
  kadmin.

* Fix a bug preventing time skew correction from working when a KCM
  credential cache is used.

Major changes in 1.17 (2019-01-08)
==

Administrator experience:

* A new Kerberos database module using the Lightning Memory-Mapped
  Database library (LMDB) has been added.  The LMDB KDB module should
  be more performant and more robust than the DB2 module, and may
  become the default module for new databases in a future release.

* "kdb5_util dump" will no longer dump policy entries when specific
  principal names are requested.

Developer experience:

* The new krb5_get_etype_info() API can be used to retrieve enctype,
  salt, and string-to-key parameters from the KDC for a client
  principal.

* The new GSS_KRB5_NT_ENTERPRISE_NAME name type allows enterprise
  principal names to be used with GSS-API functions.

* KDC and kadmind modules which call com_err() will now write to the
  log file in a format more consistent with other log messages.

* Programs which use large numbers of memory credential caches should
  perform better.

Protocol evolution:

* The SPAKE pre-authentication mechanism is now supported.  This
  mechanism protects against password dictionary attacks without
  requiring any additional infrastructure such as certificates.  SPAKE
  is enabled by default on clients, but must be manually enabled on
  the KDC for this release.

* PKINIT freshness tokens are now supported.  Freshness tokens can
  protect against scenarios where an attacker uses temporary access to
  a smart card to generate authentication requests for the future.

* Password change operations now prefer TCP over UDP, to avoid
  spurious error messages about replays when a response packet is
  dropped.

* The KDC now supports cross-realm S4U2Self requests when used with a
  third-party KDB module such as Samba's.  The client code for
  cross-realm S4U2Self requests is also now more robust.

User experience:

* The new ktutil addent -f flag can be used to fetch salt information
  from the KDC for password-based keys.

* The new kdestroy -p option can be used to destroy a credential cache
  within a collection by client principal name.

* The Kerberos man page has been restored, and documents the
  environment variables that affect programs using the Kerberos
  library.

Code quality:

* Python test scripts now use Python 3.

* Python test scripts now display markers in verbose output, making it
  easier to find where a failure occurred within the scripts.

* The Windows build system has been simplified and updated to work
  with more recent versions of Visual Studio.  A large volume of
  unused Windows-specific code has been removed.  Visual Studio 2013
  or later is now required.
-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEExEk8tzn0qJ+YUsvCDLoIV1+Dc

krb5-1.18.3 is released

[Greg Hudson]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

The MIT Kerberos Team announces the availability of MIT Kerberos 5
Release 1.18.3.  Please see below for a list of some major changes
included, or consult the README file in the source tree for a more
detailed list of significant changes.

RETRIEVING KERBEROS 5 RELEASE 1.18.3


You may retrieve the Kerberos 5 Release 1.18.3 source from the
following URL:

https://kerberos.org/dist/

The homepage for the krb5-1.18.3 release is:

https://web.mit.edu/kerberos/krb5-1.18/

Further information about Kerberos 5 may be found at the following
URL:

https://web.mit.edu/kerberos/


DES no longer supported
===

Beginning with the krb5-1.18 release, single-DES encryption types are
no longer supported.


Major changes in 1.18.3 (2020-11-17)


This is a bug fix release.

* Fix a denial of service vulnerability when decoding Kerberos
  protocol messages.

* Fix a locking issue with the LMDB KDB module which could cause KDC
  and kadmind processes to lose access to the database.

* Fix an assertion failure when libgssapi_krb5 is repeatedly loaded
  and unloaded while libkrb5support remains loaded.

Major changes in 1.18.2 (2020-05-21)


This is a bug fix release.

* Fix a SPNEGO regression where an acceptor using the default
  credential would improperly filter mechanisms, causing a negotiation
  failure.

* Fix a bug where the KDC would fail to issue tickets if the local
  krbtgt principal's first key has a single-DES enctype.

* Add stub functions to allow old versions of OpenSSL libcrypto to
  link against libkrb5.

* Fix a NegoEx bug where the client name and delegated credential
  might not be reported.

Major changes in 1.18.1 (2020-04-13)


This is a bug fix release.

* Fix a crash when qualifying short hostnames when the system has no
  primary DNS domain.

* Fix a regression when an application imports "service@" as a GSS
  host-based name for its acceptor credential handle.

* Fix KDC enforcement of auth indicators when they are modified by the
  KDB module.

* Fix removal of require_auth string attributes when the LDAP KDB
  module is used.

* Fix a compile error when building with musl libc on Linux.

* Fix a compile error when building with gcc 4.x.

* Change the KDC constrained delegation precedence order for
  consistency with Windows KDCs.

Major changes in 1.18 (2020-02-12)
==

Administrator experience:

* Remove support for single-DES encryption types.

* Change the replay cache format to be more efficient and robust.
  Replay cache filenames using the new format end with ".rcache2" by
  default.

* setuid programs will automatically ignore environment variables that
  normally affect krb5 API functions, even if the caller does not use
  krb5_init_secure_context().

* Add an "enforce_ok_as_delegate" krb5.conf relation to disable
  credential forwarding during GSSAPI authentication unless the KDC
  sets the ok-as-delegate bit in the service ticket.

* Use the permitted_enctypes krb5.conf setting as the default value
  for default_tkt_enctypes and default_tgs_enctypes.

Developer experience:

* Implement krb5_cc_remove_cred() for all credential cache types.

* Add the krb5_pac_get_client_info() API to get the client account
  name from a PAC.

Protocol evolution:

* Add KDC support for S4U2Self requests where the user is identified
  by X.509 certificate.  (Requires support for certificate lookup from
  a third-party KDB module.)

* Remove support for an old ("draft 9") variant of PKINIT.

* Add support for Microsoft NegoEx.  (Requires one or more third-party
  GSS modules implementing NegoEx mechanisms.)

* Honor the transited-policy-checked ticket flag on application
  servers, eliminating the requirement to configure capaths on
  servers in some scenarios.

User experience:

* Add support for "dns_canonicalize_hostname=fallback""`, causing
  host-based principal names to be tried first without DNS
  canonicalization, and again with DNS canonicalization if the
  un-canonicalized server is not found.

* Expand single-component hostnames in host-based principal names when
  DNS canonicalization is not used, adding the system's first DNS
  search path as a suffix.  Add a "qualify_shortname" krb5.conf
  relation to override this suffix or disable expansion.

Code quality:

* The libkrb5 serialization code (used to export and import krb5 GSS
  security contexts) has been simplified and made type-safe.

* The libkrb5 code for creating KRB-PRIV, KRB-SAFE, and KRB-CRED
  messages has been revised to conform to current coding practices.

* The test suite has been modified to work with macOS System Integrity
  Protection enabled.

* The test suite incorporates soft-pkcs11 so that PKINIT PKCS11
  support can always be tested.
-BEGIN PGP SIGNATURE--

Re: CVE-2020-17049

[Greg Hudson]

On 11/17/20 12:53 PM, Jeffrey Altman wrote:
> Just to set the record straight, Kerberos service tickets have never
> been renewable unless they were obtained as initial tickets.  Only
> TGTs are renewable.  This is true for MIT and Heimdal as well as
> Active Directory.

Both initial and non-initial non-TGTs are renewable with MIT krb5:

$ make testrealm
$ kadmin.local modprinc -maxrenewlife 1d host/small-gods
$ kadmin.local modprinc -maxrenewlife 1d user
$ kadmin.local modprinc -maxrenewlife 1d krbtgt/KRBTEST.COM
$ kinit -S host/small-gods -l 10m -r 20m
Password for u...@krbtest.com:
$ kinit -R -S host/small-gods
$ kinit -l 10m -r 20m user
Password for u...@krbtest.com:
$ kvno host/small-gods
host/small-g...@krbtest.com: kvno = 1
$ kinit -R -S host/small-gods
$

There is even a messaging service at MIT that makes use of renewable
service tickets.

Prior to release 1.9 the MIT krb5 KDC supported renewing service
tickets, but the client library did not:
https://krbdev.mit.edu/rt/Ticket/Display.html?id=6699 .

> It used to be the case that "kinit -r" would fail if the requested
> principal was "disallow-renewable".   I don't remember if it was because
> the KDC refused to issue any ticket when renewable was requested or if
> it was the client library rejecting the ticket because it didn't satisfy
> the request.

That was KDC-side.  For MIT krb5, the KDC behavior changed in release
1.12 to just issue a non-renewable ticket in this case.

Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Re: Selective kdc discovery

[Greg Hudson]

On 11/5/20 12:53 AM, Paul B. Henson wrote:
> We're currently using DNS SRV records and all of our kdc's seems to have
> fairly equal load. Are DNS SRV records handled differently in terms of
> distributing load, or is that just a side effect of the resolver handing
> them back in a different order for each lookup?

SRV records contain a priority and a weight.  The MIT krb5
implementation orders the records by priority and ignores the weight.
If all records have the same priority, we don't randomize the order, but
the DNS resolver will typically will.

(Heimdal actually uses the weight fields, so that part varies by
implementation.)

> There's no mechanism for load balancing when using file based
> kdc configuration?

Correct.

Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Re: Selective kdc discovery

[Greg Hudson]

On 10/29/20 2:13 PM, Paul B. Henson wrote:
> In the krb5.conf file, you can specify kdc's statically, but there is no 
> mechanism for prioritizing them or indicating which ones should be tried 
> first.

In the MIT krb5 implementation, they are tried in the order specified,
with a 1s delay in between.  I can't speak to the Java implementation,
unfortunately.

> You can also specify one or more master_kdc's, but based on the 
> documentation those are only accessed in the case of a password failure 
> on one of the regular kdc entries? If, hypothetically, all of the 
> regular kdc entries timeout, would the master_kdc entries still be used, 
> or would the request simply fail at that point with an unreachable kdc 
> error?

The request would fail with an unreachable error, in the MIT implementation.

Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Re: libkrb5 failed to alloc memory

[Greg Hudson]

On 10/25/20 1:31 AM, Ming Zhi wrote:
> I have encountered a very rare situation, that the libkrb5 raised an
> exception with the message "malloc: invalid size (unsorted)", and the host
> process quit afterwards.

This message is an indication that the heap was corrupted prior to the
malloc() call.  You might be able to use valgrind to determine where the
heap corruption occurred.

> At the same time, sssd_kcm kept at very high CPU
> usage till kinit succeeded.

I don't have any insight into this part.

Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Re: Kerberos AES256 and constants

[Greg Hudson]

On 10/11/20 6:16 AM, Egor wrote:
> Good day.
> I am searching for detailed AES256 kerberos algorithm implementation.
> I am interested espeсially in nfold algorithm in it. I know, how nfold 
> algorithm works, but it is very important for me to know, which constants 
> except string "kerberos" are used in key derivation with the help of nfold 
> algorithm. I have heard that these constants depends on the type of traffic 
> packet (AS_REG, AS_REP, TGS_REP)
> Could you please help to find it, it is very important?

RFC 3961 and 3962 are the references here.  RFC 3961 defines the overall
framework and (in section 5) the simplified profile.  RFC 3962 defines
the AES-SHA1 enctypes using the simplified profile.

In the simplified profile, the protocol key is used to derive three
subkeys named Kc, Ke, and Ki.  Ke and Ki are used for encryption (Ki for
the integrity tag, Ke to encrypt the plaintext) and Kc is used for the
checksum operation.  The derivation of these subkeys is specified at the
very end of RFC 3961 section 5.3.  The n-folded constant used in these
derivations is the key usage number (as a four-byte big-endian integer)
with a different byte appended for each subkey.

The key usage number is determined by the Kerberos or application
protocol operation being performed.  Specific key usage numbers are
defined in RFC 4120 section 7.5.1 and in the ad hoc registry at:
https://github.com/krb5/krb5-assignments/blob/master/key-usage

As you noted, the constant "kerberos" is also used at the end of the
string-to-key operation.

Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Re: cpw ignoring password policies

[Greg Hudson]

On 8/13/20 1:51 AM, Dario García Díaz-Miguel wrote:
> I can change all the time the password of the principal with that policy 
> applied despite the minimum password life described.

That's true.  The kadmin server code deliberately only checks the
minimum life if a principal is changing its own password.

> Also I'm able to apply old passwords and the history is not being respected, 
> but I'm afraid that's the expected behavior because of the LDAP database 
> module.

Right, LDAP password history is implemented in release 1.15 but not in 1.12.

> I understand that cpw is more like the administration password changing tool 
> and in order to be able to change the password whenever it requires by the 
> system administrator, the minimum password life is not being applied.
> But then, Any ideas about how could we proceed?

I guess you could print a kadmin ticket for the user from the KDB and
then authenticate with it:

kinit -k -c somefilename -t KDB: -S kadmin/admin username
kadmin -c somefilename -q "cpw -pw password username"

kinit -t KDB: support was added in release 1.9, so should be available.

Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Re: cpw ignoring password policies

[Greg Hudson]

On 8/12/20 5:39 AM, Dario García Díaz-Miguel wrote:
> kadmin -k -t $KEYTABLOCATION -p $SERVICEPRINCIPAL -q "cpw $PRINCIPAL -pw 
> $PASSWORD"
> 
> What we found is that this command ignores the password policy assigned to 
> the principal, including all the complexity rules and history options. No 
> matter if the command is launched in a kadmin console interactive mode, 
> policies are totally ignored.
> 
> If we use:
> 
> kpasswd $PRINCIPAL

That's unexpected, and it's not the behavior I see in a test environment:

$ kadmin.local addpol -minlength 6 testpol
$ kadmin.local modprinc -policy testpol user
$ kadmin -k -p user/admin cpw -pw pw user
change_password: Password is too short while changing password for
"u...@krbtest.com".
$ kadmin.local cpw -pw pw user
change_password: Password is too short while changing password for
"u...@krbtest.com".

What software and version is running on the kadmin server?

Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Re: Issues getting Kerberos to work with realmd and Active Directory

[Greg Hudson]

On 7/30/20 1:00 PM, Wesley Taylor wrote:
> I am confused because when I run 'adcli update --verbose' it says it updated 
> the keytab at /etc/krb5.keytab and outputs the same account name (which I am 
> assuming is the principal for the computer) as adcli testjoin. I am really 
> scratching my head about this, what am I doing wrong here?

It might help to send a transcript of the klist -k output and the kinit
commands.

Note that the case of principal names is significant on the MIT krb5
side, and generally isn't on Windows.

You can set the environment variable KRB5_TRACE to get additional
information about what commands are trying to do behind the scenes, e.g.
"KRB5_TRACE=/dev/stdout kinit -k host/hostname@REALM".

Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Re: Avoiding Pre-Auth/Auth Principal State Disclosure

[Greg Hudson]

On 7/1/20 3:55 PM, Chris Hecker wrote:
>> For example, if we treated single-component principals as users,
> anyone with a user/admin principal (or user/root, which has no status in
> the code but is a common convention for elevated access) would probably
> still be detectable by an attacker.
> 
> Not sure I follow this, why wouldn’t they be treated like a normal princ
> if we had this obscurity feature?

The difficulty is in making a "normal princ" look identical to an actual
normal princ.

Let's say we added this obscurity setting to the KDC in the following
naive way: if an unauthenticated AS request comes in and the client
principal isn't found in the DB, we send PREAUTH_REQUIRED.  If the
request contains preauth (of a recognizable "real" preauth type) then we
send PREAUTH_FAILED.

Service principals can (and frequently do) authenticate as clients.
Because they have random keys, they don't generally require preauth
(partly because preauth would be a waste of round trips when the key is
random, and partly because PREAUTH_REQUIRED has undesirable legacy
semantics when applied to service principals).  So without first
authenticating as a legitimate client, the attacker can distinguish
between a dummy response and a real response for a service principal.
Perhaps we don't care about obscuring valid service principals, but if
we do, we have to instead respond to AS requests for service-principal
clients with a dummy ticket (of a size indistinguishable from a
legitimate ticket) encrypted in a random key, instead of a
PREAUTH_REQUIRED.  And because there is no formal distinction between
user principals and service principals, we can't trivially determine
whether the client principal (if it existed) would be for a user or for
a service.

Additionally, in a PREAUTH_REQUIRED error, we have to send etype-info
based on the request's enctype preference order and the client and
server principals' supported enctypes.  There's no client principal
entry, so what enctypes do we assume are supported by the client?
Perhaps we consult supported_enctypes.  What if the administrator just
recently began a transition from aes-sha1 to aes-sha2 enctypes?  Most
real principals will only have aes-sha1 keys, but supported_enctypes
lists the aes-sha2 enctypes.  In this situation it's easy to distinguish
dummy responses from those for most real principals.

The use of more advanced preauth mechanisms might further muddy things;
for instance, principals intended to authenticate with PKINIT might have
no keys, and therefore no etype-info.  Perhaps we allow the
administrator to create a template principal which has similar metadata
to the majority of user principals, and use that for dummy responses.
Now we're asking a lot from the administrator, and any kind of enctype
or preauth transition would still create classes of users who are
distinguishable from the template.

We'd also have to consider whether to include TGS requests in the threat
model.  If the attacker is an insider or has compromised just one client
account, they can try to build their valid principal list using TGS
requests instead of AS requests.  If we're just trying to obscure user
principals this might not be too hard, assuming users have DISALLOW_SVR
set.  We'd have to send back S_PRINCIPAL_UNKNOWN instead of
MUST_USE_USER2USER when the service principal has that flag.
(Additional attention might need to be given to the user-to-user code
path, as the attacker could try user-to-user with a bogus TGT.)  If
we're also trying to obscure service principals, the problem becomes
much harder; we'd have to issue dummy service tickets for invalid
services, again making sure the ticket size isn't distinguishable, and
making the choice of ticket session key enctype indistinguishable from a
normal service principal.  Issuing dummy service tickets would create
many problems for legitimate users, such as breaking
dns_canonicalize_hostname=fallback.

Finally, none of the above analysis considers side channels.  If a dummy
response takes a measurably different amount of time for the KDC to
synthesize than a normal response, an attacker still might be able to
distinguish valid from invalid principal names.

Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Re: Avoiding Pre-Auth/Auth Principal State Disclosure

[Greg Hudson]

On 7/1/20 1:53 AM, Eric Hattemer wrote:
> I know pre-auth is a special case where you'd need to provide a 
> plausible challenge for non-existent accounts.  But is there maybe a 
> setting to treat unknown principals as if they had pre-auth disabled, 
> request a password, and just send back invalid password / encryption 
> failed no matter what?

We don't have a setting like that.  The closest nod we have in the code
to this desire is a "vague errors" setting for the KDC, which can only
be turned on at compile time (or via ptrace, I guess) and causes the KDC
to yield generic errors instead of useful ones.  But that setting still
allows an attacker to easily distinguish between "client principal
requires preauth" and "client principal not found".

Because the Kerberos principal namespace isn't formally divided between
users and services, any obscurity feature would probably have some edge
cases.  For example, if we treated single-component principals as users,
anyone with a user/admin principal (or user/root, which has no status in
the code but is a common convention for elevated access) would probably
still be detectable by an attacker.

Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Re: A possible small bug in SPNEGO handling when dealing with NETAPP servers

[Greg Hudson]

On 6/29/20 6:22 PM, Richard Sharpe wrote:
> The code was directly extracting the length from the buffer but (as
> you can see from the capture attached in the Session Setup Response)
> NetApp encodes the length of the OID in a longer form as 0x82 0x00
> 0x09 instead of the short-form 0x09.

RFC 4178 section 4 specifies that "the encoding of the SPNEGO protocol
messages shall obey the Distinguished Encoding Rules (DER) of ASN.1, as
described in [X690]."

X.690 section 10.1 (Distinguished Encoding Rules, length forms)
specifies that "The definite form of length encoding shall be used,
encoded in the minimum number of octets."

So this is pretty clearly a NetApp bug.  Has a report been filed with them?

Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Re: krb5-18.2: MDB_BAD_RSLOT: Invalid reuse of reader locktable slot

[Greg Hudson]

On 6/18/20 4:53 AM, rachit chokshi wrote:
> *LMDB read failure (path: /var/kerberos/krb5kdc/principal.mdb):
> MDB_BAD_RSLOT: Invalid reuse of reader locktable slot*

After some off-list debugging, I determined that the LMDB reader table
entries for krb5kdc and kadmind appear as stale to other processes and
can be reclaimed, because both daemons open the DB before daemonizing.

I have filed a ticket and a pull request:

https://krbdev.mit.edu/rt/Ticket/Display.html?id=8918
https://github.com/krb5/krb5/pull/1088

Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Re: Integrating Kerberos with a Java application using JAAS

[Greg Hudson]

On 6/12/20 10:05 AM, Aparajita Singh wrote:
> [Caused by GSSException: Failure unspecified at GSS-API level (Mechanism
> level: Invalid argument (400) - Cannot find key of appropriate type to
> decrypt AP REP - AES256 CTS mode with HMAC SHA1-96)]

Most likely the long-term key of the service as seen by the KDC does not
match the entry in the keytab of the service.

Each time you run the kadmin "ktadd" command, new keys are generated for
the service, with a new key version number (kvno), and are added to the
keytab on whatever machine you run it as.  Any existing keytab file
elsewhere is invalidated by the generation of new keys.

Since you are using the same client and service principal name (why?),
you may have provisioned keytab files for the same principal name on the
client and server hosts.  If you really need to use the same client and
server principal name, you will need to provision one keytab file and
copy it around (with scp or similar) rather than provision it separately
on each machine.

You can use "kvno zookeeper/stage-kdc-zk-2f...@stage.fdp.kafka" on the
client to see what kvno of tickets the KDC issued to the client.  You
can use "klist -k" or "klist -k -t /path/to/keytab" to see the kvno
present in a keytab file.

As an aside, the instructions you reference are from 17 years ago.
Please refer to https://web.mit.edu/kerberos/krb5-latest/doc/


Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Re: MIT Kerberos Master principal deletion

[Greg Hudson]

On 6/10/20 10:32 PM, Harshawardhan Kulkarni wrote:
> We have a Kerberised Hadoop Cloudera Custer. KDC Admin server is on one of
> the nodes. We don't have a failover node for KDC server yet. On the KDC
> admin server while doing a clean up activity for unwanted kdc principals, I
> deleted the master key principal (K/m...@realm.com) We never took a kdc dump
> of the master key. So we don't have a backup to restore from.
> 
> Is there any way I can restore the master key principal?

Unfortunately, it doesn't look like our tools provide any good recovery
options for this case, so I think you're stuck recreating the Kerberos
database.

I will file a ticket that it shouldn't be possible to delete the K/M
principal entry.

Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Re: Replacing master/slave terminology

[Greg Hudson]

On 6/10/20 3:48 PM, Nate Coraor wrote:
> I'd like to propose that an effort be made to replace master/slave
> terminology in MIT and Heimdal implementations at some future milestone.

MIT krb5 switched to using "replica" for non-primary KDCs as of release
1.17.  This was an easy change technically, as the old term was only
used in a user-visible way in documentation and in the name of one
profile relation.  The pull request for that change was here:
https://github.com/krb5/krb5/pull/851

Replacing the term "master" is a larger technical challenge.  We use
that term in a DNS SRV record label (_master_kdc), and migrating that
would come with a cost in network traffic and latency.  Aside from the
kprop architecture, we also use the term "master key" to describe the
key used to encrypt long-term keys in the KDC database.

I have rationalized to myself that the term "master" is the less
problematic of the two terms, as it is used in a lot of different
contexts (such as physical master keys, martial arts masters, master
plumbers, and master recordings of records).  But I don't know if that
rationalization is adequate; from recent discussion I know that git's
use of "master" for the initial default branch name has become a point
of contention.

Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Re: Hi All,

[Greg Hudson]

On 5/26/20 2:54 AM, Ming Zhi wrote:
> But with GSSAPI, I cannot find an official way to set the hook between the
> `context' creation and the start of kdc traffic, as is done in a single
> function `gss_init_sec_context'. The worst situation is that I need to get
> hands dirty to change the source code.

Unfortunately I don't think we have a good solution here.  We have a
"locate" pluggable interface [1] which might work (basically, have it
always return a local service, which then parses out the realm name from
the request).

I am personally fond of the idea of having a krb5 interface to control
the per-thread krb5_context object used by the GSS mech, for situations
like these.  But other people have disliked the idea, so I haven't
implemented it.

[1] https://web.mit.edu/kerberos/krb5-latest/doc/plugindev/locate.html

Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Re: rdns, past and future

[Greg Hudson]

On 5/26/20 5:09 PM, Ken Dreyer wrote:
> In public cloud environments or Kubernetes environments, PTR records
> are difficult or impossible for administrators to set. We increasingly
> have to tell users to set "rdns = fallback" or "rdns = false".

Note that dns_canonicalize_hostname and rdns are separate settings.
dns_canonicalize_hostname supports "fallback", but rdns only supports
true or false (and only takes effect when DNS canonicalization happens).

If a PTR record is not set at all, the library should by default use the
forward canonicalization result.  The problem happens when there is a
PTR record, but it has a non-useful value.

> I'm wondering what the original purpose of Kerberos' rdns feature was.
> Why would a client want or need to do hostname canonicalization?

Forward DNS canonicalization was a convenience for cnames and
non-qualified hostnames.  We now have a qualify_shortname feature to
address single-label names by adding a domain suffix, but it only
appeared in 1.18.

The additional reverse canonicalization step was, to the best of my hazy
understanding, aimed specifically at a historical element of the Athena
computing environment at MIT, most likely a pool of dialups which
load-balanced via A record.

We know that the rdns=true default is an inconvenience for many
environments.

> I'm also wondering if we will ever be able to default MIT Kerberos'
> rdns setting to "fallback" or "false" in a future version. IMHO this
> would make it easier to deploy Kerberos applications in modern hosting
> environments.

I floated the idea of changing the rdns default to false some years ago,
and got the sense that it would be traumatic to a number of existing
deployments.  Client library upgrades are generally not intentional, so
warning people via release notes doesn't really help.

Changing the default for dns_canonicalize_hostname to "fallback" would
be less likely to be traumatic.  Fedora is starting to put
dns_canonicalize_hostname=fallback in their shipped default krb5.conf.
(They have put rdns=false in this file since 2013.)  If there isn't much
fallout, we might change the library default in 1.19.  That change
wouldn't help when the forward-but-not-reverse-canonicalization result
is best, but it does help if the originally entered name or its
shortname-qualified version is correct.

We had a design floating around for a protocol extension where the KDC
could set a "please don't canonicalize" ticket flag.  Unfortunately no
progress has been made on this idea.

Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Re: Password Encryption

[Greg Hudson]

On 5/22/20 2:29 PM, Joshua Brodie wrote:
> How can I find out the out of the box default password encryption used?

Kerberos doesn't encrypt passwords(*), but it does store long-term keys
derived from the passwords.  This derivation, called the "string-to-key"
operation for the encryption type, is one-way; you can't decrypt a
long-term key to get at the original password.  You can perform a
dictionary attack (trying lots of potential passwords to see if they
result in the same key).  The string-to-key operations for AES and
Camellia enctypes are deliberately slow in order to frustrate dictionary
attacks, whereas the older single-DES, triple-DES, and RC4 enctypes have
very fast string-to-key operations.

The default set of encryption types used for new principals is listed as
the default value of supported_enctypes here:

https://web.mit.edu/kerberos/krb5-latest/doc/admin/conf_files/kdc_conf.html#realms

> On a getprinc -- there are 8 shown -- are these all used for the principal?

Yes, for that principal entry there are string-to-key results for all
eight encryption types.  camellia256-cts-cmac and camellia128-cts-cmac
have never been in the default value for supported_enctypes, so the
default was not used for that principal.

(*) Kerberos password-change operations do involve encrypting passwords
for transport over the wire from the client to the admin server.  But
the KDC doesn't store decryptable passwords in the database.

Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

krb5-1.18.2 is released

[Greg Hudson]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

The MIT Kerberos Team announces the availability of MIT Kerberos 5
Release 1.18.2.  Please see below for a list of some major changes
included, or consult the README file in the source tree for a more
detailed list of significant changes.

RETRIEVING KERBEROS 5 RELEASE 1.18.2


You may retrieve the Kerberos 5 Release 1.18.2 source from the
following URL:

https://kerberos.org/dist/

The homepage for the krb5-1.18.2 release is:

https://web.mit.edu/kerberos/krb5-1.18/

Further information about Kerberos 5 may be found at the following
URL:

https://web.mit.edu/kerberos/


DES no longer supported
===

Beginning with the krb5-1.18 release, single-DES encryption types are
no longer supported.


Major changes in 1.18.2 (2020-05-21)


This is a bug fix release.

* Fix a SPNEGO regression where an acceptor using the default
  credential would improperly filter mechanisms, causing a negotiation
  failure.

* Fix a bug where the KDC would fail to issue tickets if the local
  krbtgt principal's first key has a single-DES enctype.

* Add stub functions to allow old versions of OpenSSL libcrypto to
  link against libkrb5.

* Fix a NegoEx bug where the client name and delegated credential
  might not be reported.

Major changes in 1.18.1 (2020-04-13)


This is a bug fix release.

* Fix a crash when qualifying short hostnames when the system has no
  primary DNS domain.

* Fix a regression when an application imports "service@" as a GSS
  host-based name for its acceptor credential handle.

* Fix KDC enforcement of auth indicators when they are modified by the
  KDB module.

* Fix removal of require_auth string attributes when the LDAP KDB
  module is used.

* Fix a compile error when building with musl libc on Linux.

* Fix a compile error when building with gcc 4.x.

* Change the KDC constrained delegation precedence order for
  consistency with Windows KDCs.

Major changes in 1.18 (2020-02-12)
==

Administrator experience:

* Remove support for single-DES encryption types.

* Change the replay cache format to be more efficient and robust.
  Replay cache filenames using the new format end with ".rcache2" by
  default.

* setuid programs will automatically ignore environment variables that
  normally affect krb5 API functions, even if the caller does not use
  krb5_init_secure_context().

* Add an "enforce_ok_as_delegate" krb5.conf relation to disable
  credential forwarding during GSSAPI authentication unless the KDC
  sets the ok-as-delegate bit in the service ticket.

* Use the permitted_enctypes krb5.conf setting as the default value
  for default_tkt_enctypes and default_tgs_enctypes.

Developer experience:

* Implement krb5_cc_remove_cred() for all credential cache types.

* Add the krb5_pac_get_client_info() API to get the client account
  name from a PAC.

Protocol evolution:

* Add KDC support for S4U2Self requests where the user is identified
  by X.509 certificate.  (Requires support for certificate lookup from
  a third-party KDB module.)

* Remove support for an old ("draft 9") variant of PKINIT.

* Add support for Microsoft NegoEx.  (Requires one or more third-party
  GSS modules implementing NegoEx mechanisms.)

* Honor the transited-policy-checked ticket flag on application
  servers, eliminating the requirement to configure capaths on
  servers in some scenarios.

User experience:

* Add support for "dns_canonicalize_hostname=fallback""`, causing
  host-based principal names to be tried first without DNS
  canonicalization, and again with DNS canonicalization if the
  un-canonicalized server is not found.

* Expand single-component hostnames in host-based principal names when
  DNS canonicalization is not used, adding the system's first DNS
  search path as a suffix.  Add a "qualify_shortname" krb5.conf
  relation to override this suffix or disable expansion.

Code quality:

* The libkrb5 serialization code (used to export and import krb5 GSS
  security contexts) has been simplified and made type-safe.

* The libkrb5 code for creating KRB-PRIV, KRB-SAFE, and KRB-CRED
  messages has been revised to conform to current coding practices.

* The test suite has been modified to work with macOS System Integrity
  Protection enabled.

* The test suite incorporates soft-pkcs11 so that PKINIT PKCS11
  support can always be tested.
-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEExEk8tzn0qJ+YUsvCDLoIV1+Dct8FAl7H/sUACgkQDLoIV1+D
ct8sRRAAkSLkpUrOU7cMxFFDCds+ffAgMuKraNHGGje5Pp1Tij0KZPiaw3azrKMU
npw6WGgaYy3RuaWY/4K6DdQak1MePadgR4KjB0hm1FN88DlM3IiXv26Sf2E8/Lx0
MtF02/+iIR6bFnvQ2ZJSzDUC9AB+P6oBBh2loxZTnQWm7w+ClZaqeQeoYh2Xiudu
5w5hJEfiwZq6FaX/zvwFR7ySpQj6hYJoBgFlVHe5M0aFbNsozDf7Xv/OQunPLzsw
FZzAJPgy12UoeXmfxeRwSiM6VrJEQDUfbsNlf/LfOial+w2uErCC1G9JURBO9FAq
9/IFrFScEDSDyGey+KFlqqDBE7C4qDAjLT+iLDgd

Re: cTime and KrbError

[Greg Hudson]

On 5/19/20 10:56 AM, Luke Hebert wrote:
> So I've been searching around trying to understand cTime. While dealing
> with a ticket renewal issue. I know that this is supposed to be the
> client's current time. The question is what conditions cause cTime to print
> out in Java debug as being from 1981. This isn't the start of epoch.
> 
> My assumption looking at the RFC for KRBError would suggest to me that
> something went wrong and the authenticator could not decode the request and
> the fields are omitted in the Error response. Thus resulting in a default
> value being printed for what would be a time based field.

For a KRB-ERROR resulting from a TGS request, the MIT krb5 KDC would
normally omit the ctime and cusec fields.  It looks like a Heimdal KDC
would copy them from the request authenticator.  I don't know what
Microsoft KDCs do.

347262666 does not seem like a recognizable default value; I have no
idea where it could be coming from.

Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Re: Upgrading 1.14 to 1.18.1 -- Cannot allocate memory?

[Greg Hudson]

On 5/8/20 3:18 PM, Leonard J. Peirce wrote:
> I am testing the upgrade from 1.14 to 1.18.1.  I copy the database
> directory over and attempt to start krb5kdc and kadmind but both
> fail.  Syslog shows for krb5kdc
> 
> Cannot allocate memory - while creating main loop

"while creating main loop" is a hint here, but unfortunately "Cannot
allocate memory" probably doesn't speak to the true cause.  If there any
other KDC or kadmind log messages preceding that one, they may help.
Since you built the sources yourself, you could try debugging through
startup using gdb, particularly looking into loop_setup_network().
strace is another option for collecting more information.

There were significant changes to KDC and kadmind network configuration
in 1.15.  I haven't seen a report like this before, but it's possible
that the changes interact badly with your specific configuration.

Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Re: KDC with openldap backend, ldap replication, can it chase referrals?

[Greg Hudson]

On 4/14/20 3:34 PM, Andreas Hasenack wrote:> Can mit kerberos (1.17 for
the purpose of this conversation) using the
> openldap backend (kldap) chase ldap referrals when it tries to write
> to an openldap replica, which is read-only?
> 
> In other words, can I list both the openldap primary and its read-only
> replica in krb5.conf's ldap_servers parameter?

I don't believe we support this.  This came up a number of years ago:

https://krbdev.mit.edu/rt/Ticket/Display.html?id=7754

and we haven't written the callback code to do a non-anonymous bind when
chasing a referral.

Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

krb5-1.18.1 is released

[Greg Hudson]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

The MIT Kerberos Team announces the availability of MIT Kerberos 5
Release 1.18.1.  Please see below for a list of some major changes
included, or consult the README file in the source tree for a more
detailed list of significant changes.

RETRIEVING KERBEROS 5 RELEASE 1.18.1


You may retrieve the Kerberos 5 Release 1.18.1 source from the
following URL:

https://kerberos.org/dist/

The homepage for the krb5-1.18.1 release is:

https://web.mit.edu/kerberos/krb5-1.18/

Further information about Kerberos 5 may be found at the following
URL:

https://web.mit.edu/kerberos/


DES no longer supported
===

Beginning with the krb5-1.18 release, single-DES encryption types are
no longer supported.


Major changes in 1.18.1 (2020-04-13)


This is a bug fix release.

* Fix a crash when qualifying short hostnames when the system has no
  primary DNS domain.

* Fix a regression when an application imports "service@" as a GSS
  host-based name for its acceptor credential handle.

* Fix KDC enforcement of auth indicators when they are modified by the
  KDB module.

* Fix removal of require_auth string attributes when the LDAP KDB
  module is used.

* Fix a compile error when building with musl libc on Linux.

* Fix a compile error when building with gcc 4.x.

* Change the KDC constrained delegation precedence order for
  consistency with Windows KDCs.

Major changes in 1.18 (2020-02-12)
==

Administrator experience:

* Remove support for single-DES encryption types.

* Change the replay cache format to be more efficient and robust.
  Replay cache filenames using the new format end with ".rcache2" by
  default.

* setuid programs will automatically ignore environment variables that
  normally affect krb5 API functions, even if the caller does not use
  krb5_init_secure_context().

* Add an "enforce_ok_as_delegate" krb5.conf relation to disable
  credential forwarding during GSSAPI authentication unless the KDC
  sets the ok-as-delegate bit in the service ticket.

* Use the permitted_enctypes krb5.conf setting as the default value
  for default_tkt_enctypes and default_tgs_enctypes.

Developer experience:

* Implement krb5_cc_remove_cred() for all credential cache types.

* Add the krb5_pac_get_client_info() API to get the client account
  name from a PAC.

Protocol evolution:

* Add KDC support for S4U2Self requests where the user is identified
  by X.509 certificate.  (Requires support for certificate lookup from
  a third-party KDB module.)

* Remove support for an old ("draft 9") variant of PKINIT.

* Add support for Microsoft NegoEx.  (Requires one or more third-party
  GSS modules implementing NegoEx mechanisms.)

* Honor the transited-policy-checked ticket flag on application
  servers, eliminating the requirement to configure capaths on
  servers in some scenarios.

User experience:

* Add support for "dns_canonicalize_hostname=fallback""`, causing
  host-based principal names to be tried first without DNS
  canonicalization, and again with DNS canonicalization if the
  un-canonicalized server is not found.

* Expand single-component hostnames in host-based principal names when
  DNS canonicalization is not used, adding the system's first DNS
  search path as a suffix.  Add a "qualify_shortname" krb5.conf
  relation to override this suffix or disable expansion.

Code quality:

* The libkrb5 serialization code (used to export and import krb5 GSS
  security contexts) has been simplified and made type-safe.

* The libkrb5 code for creating KRB-PRIV, KRB-SAFE, and KRB-CRED
  messages has been revised to conform to current coding practices.

* The test suite has been modified to work with macOS System Integrity
  Protection enabled.

* The test suite incorporates soft-pkcs11 so that PKINIT PKCS11
  support can always be tested.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBAgAGBQJelQbvAAoJEAy6CFdfg3LfzjMP/jVVKN+yytysLvgaxgl4owYA
bg8aJkyNrxec2w9d/ySUA0KvCwhI8g9Hg7I/fhlYKn4x5EXaPJ8CNTYFSO7FiOXS
fCrE23gv25x43jcnxdIwGwZ1YJh7vUrLb6GGSDW96exdfbZAGdE8M6UTeUOYQLxc
h6e1j79BqT+j2Bc5y0+UbA6X0HoKtLd4gWcrtVQ3CH1vP4Ln8kUVt+O+LuW6l/5k
3+8MHLaHcqtez5oW82K3uj2PXlEv+43MS17mkXww9dl7HMWWn83e55jfpYIhy5bW
+Xh+OPDvPfOZA3DEt7Q3XCG3j6V7bf3oJ5FyoBGDAOz1yxq+pVFnpJH8crebHyor
v5uRZyXFvDKvsCsMYV6BUauF3lTVarBo09UroGjpW78mLAd6IDnEJYlr5tUtIJj/
2jyulKH6GCMHizBLeopK/25C9Nv/Fv9jOmUhREdZuO+2hD5JRv84PT4pPKqFBEiW
KR5WuaLhzCPQRdM+5ICAOkdWq6iJIKcZ1OflFxu93kmv5Zvk9m8naU0a7PnreR2X
8Xy8rHVu6/xROffBJyig+nFh3sya3av9KDzXemU5GhQAkN+k2R5tMgFYHi9h2abQ
/6ZHYtL+aKJMUioY/gj1NNqzIwgGrygTJ9bDZyweO63vUMgtgGwbMEJuDXJFGwMv
NIb3nnoZH7hGdr7he5Wj
=HJif
-END PGP SIGNATURE-
___
kerberos-announce mailing list
kerberos-annou...@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos-announce
_

Re: What form is the timestamp in the KRB5_TRACE log (and why)

[Greg Hudson]

On 4/3/20 10:21 AM, Todd Grayson wrote:
> Ok but does that mean Unix Epoch time conversion should be working, or is
> there some other form of secret decoder ring that is used to translate to
> system time?

It's just system time.

$ date; KRB5_TRACE=/dev/stdout kvno user
Fri Apr  3 10:58:03 EDT 2020
[...]
[12194] 1585925883.499498: Retrieving u...@krbtest.com [...]
[...]
$ date -d '@1585925883'
Fri Apr  3 10:58:03 EDT 2020

Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Re: Upgrading KDC from 1.15 to 1.18

[Greg Hudson]

On 3/20/20 5:36 PM, Yegui Cai wrote:
> https://web.mit.edu/kerberos/krb5-1.5/krb5-1.5.4/doc/krb5-install/Upgrading-Existing-Kerberos-V5-Installations.html

If you are upgrading the software on the current host, simply stop the
old KDC and kadmind processes and start the new ones.

If you are migrating between hosts as part of the upgrade, you can just
copy the database directory after stopping the old KDC and kadmind
processes.

If you do choose to dump and load, omit the "dump -ov" and "load
-update" steps.  They haven't been necessary since release 1.3.  Release
1.18 removed support for the ovsec dump format, which is why you get the
"dump header bad" error trying to load it.

Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Re: Nuances of MIT Kerberos prompting

[Greg Hudson]

On 3/9/20 1:32 AM, Russ Allbery wrote:
>> 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?

Yes.  For this prompter call, name is NULL, banner is the formatted
expiration warning, and num_prompts is 0.
> 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.

Ah, two responder calls, not two prompter calls.  I was looking at the
wrong code paths.

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.

(The real reason kinit isn't affected is that it doesn't use a responder
callback.)

Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos