7 Nov
2018
7 Nov
'18
1:58 a.m.
On Tue, Nov 6, 2018 at 9:18 PM Grant Taylor via TUHS <tuhs(a)minnie.tuhs.org>
wrote:
Kerberos does include modern enctypes (such as aes128/aes256), but from
what *little* I understand about this part, it's still not as good as the
modern protocols. (E.g. complete lack of PFS – the same client or server
always uses the same master key until it's manually rotated...)
On the bright side, the *authentication* of Kerberos is solid as far as
I've heard. (Which, again I know very little about this part, but I do
remember someone saying that it has an actual security proof, as well as
being decently quantum-resistant.)
Usually, yes.
(There is no technical reason why it couldn't run inside TLS, it's just
redundant – OpenLDAP doesn't mind but e.g. Active Directory explicitly
refuses to use both encryption layers at once. If you use TLS, you can
still use GSSAPI auth, but it insists that you turn off the GSSAPI
signing/sealing.)
(This reminds me that I've noticed at least one of the MIT Kerberos
developers here in TUHS, who would surely know more about this than I've
gathered through barely few years of messing around.)
--
Mantas Mikulėnas
On 11/06/2018 12:07 AM, Mantas Mikulėnas wrote:
Though from what I've seen on their mailing list, MIT Kerberos developers
seem to recommend using GSSAPI at minimum, rather than the raw Kerberos
APIs.
These days the modification generally consists of
pam_krb5 added to the
system's PAM configuration.
Hum.... I need to do some reading on that.
And similarly – in other protocols (IMAP, SMTP,
IRC, the same LDAP) one
can authenticate a session via SASL, which usually wraps GSSAPI, which
usually wraps Kerberos.
*nod*
Complicating things is that implementations can choose to bypass SASL
and do the GSSAPI interaction directly. Or take things even further and
do the Kerberos interaction directly.
Yet another reason why all these things are complicated. So many
choices that impact other choices in the same problem domain.
Well, they can use it, but they don't have to. It's up to the developer in
the end. The earlier kerberized protocols did, because they didn't have any
other encryption layer. Most recent protocols establish encryption in any
case (be it TLS or SSHv2 or something else) so they just don't bother
calling the SASL (or GSSAPI) seal functions.
You're right, it's primarily an
authentication protocol.
:-)
But due to the way it works, it *also* negotiates
a 'session key'
between
the user and the service, which then may be used
for transport
encryption
(sealing).
Does that mean that the protocols would need to retain the session key
and use it for their other non-Kerberos specific protocols? I.e. the
rsh daemon would need to use the session key to encrypt / decrypt the
rsh data, after and independent of the Kerberos authentication process.
It's not commonly used as far as I know –
most new protocols already
have their own security layers such as TLS or SSH.
ACK
I worry that other encryption protocols / methods have far surpassed
Kerberos' encryption capability / strength.
Actually LDAP is the only still-widespread
protocol that comes to mind
whose implementations frequently make use of Kerberos-based encryption
(via GSSAPI).
O.o‽
This sounds like it would be independent of LDAP over SSL (TCP 636).
Would this Kerberos specified encryption be run over the standard LDAP
port (TCP 389)?
This is especially common in Active Directory
environments, where the
DCs might not have a valid TLS certificate.
O.o‽
I'm going to have to go pick my AD guru's brain after reading that.
(I seem to recall kerberized Telnet didn't
survive because it was
limited to DES/3DES for an odd reason. Didn't quite understand why that
was the case, though.)
#questionsQuestions