[TUHS] YP / NIS / NIS+ / LDAP

[Grant Taylor]

On 11/06/2018 12:07 AM, Mantas Mikulėnas wrote:
> 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.

> 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



-- 
Grant. . . .
unix || die

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3982 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20181106/34257534/attachment.bin>