From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: tuhs-bounces@minnie.tuhs.org X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=0.9 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,HTML_MESSAGE,MAILING_LIST_MULTI, RCVD_IN_DNSWL_NONE,SUBJ_ALL_CAPS autolearn=no autolearn_force=no version=3.4.2 Received: from minnie.tuhs.org (minnie.tuhs.org [45.79.103.53]) by inbox.vuxu.org (OpenSMTPD) with ESMTP id 0303a901 for ; Tue, 6 Nov 2018 21:44:11 +0000 (UTC) Received: by minnie.tuhs.org (Postfix, from userid 112) id 74643A22A0; Wed, 7 Nov 2018 07:44:10 +1000 (AEST) Received: from minnie.tuhs.org (localhost [127.0.0.1]) by minnie.tuhs.org (Postfix) with ESMTP id EC391A22B7; Wed, 7 Nov 2018 07:43:44 +1000 (AEST) Received: by minnie.tuhs.org (Postfix, from userid 112) id 9F571A22A1; Wed, 7 Nov 2018 05:58:25 +1000 (AEST) Received: from mail-ot1-f47.google.com (mail-ot1-f47.google.com [209.85.210.47]) by minnie.tuhs.org (Postfix) with ESMTPS id 155FFA22A0 for ; Wed, 7 Nov 2018 05:58:20 +1000 (AEST) Received: by mail-ot1-f47.google.com with SMTP id g27so12630623oth.6 for ; Tue, 06 Nov 2018 11:58:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=oLD9MJaeh5OWLm+aLRWm+mxMYHHp0tq0t2AdMPHJH0Q=; b=cbqtL3Sfd5AahswPRVsnS62rq8AMDUKiV749400S1dB1eN2dgIaUz+oiaxzaUPNNIe NTaVQoG3iOBPmvspdX3gzv9Jd/RF4+BFKrIbI9RuIW0aW9D0RG9uMAYtLcwrCcPATO/V uNi1PEHblBq03XE0eWpxjdAkctG509So8/71PxEIvRy4EsTMGU38PFp9muNaLjbMLJwK hFRm3Brdmr2Qi4Wjl0htNcuc5CLBepgQ3mYBgOaix16sNKM/WZloa13hkX6zIcjVVEAs mzejnaMOqt347E6p2h/gTwyjBX8uWzYHDgiRF56iwW7Rg9C3N+2IOZ4eC8FTJfZjSp9a NPbw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=oLD9MJaeh5OWLm+aLRWm+mxMYHHp0tq0t2AdMPHJH0Q=; b=Ao4IReS1j2Nxih0+V1m6NI/aU2buVLtchFWesTnXwKj4bapcQfCXRM1IiKOpryschz KmVflTiIVuijeCuLviqVrOZI5QSajYd0ZjMhUp+KlLCcxXIrUDWuYuVJqbi3u0uFpOC6 a/X50jz9OnX/M+j8ihZ+FXXDXLz434i8+Gbxku5/2yG1i4pbmP5nIpQbCHjWax+yUhXT Xa21qC9v5S8dUycoMae5P2cQUD9+vqjrcnxp9w1maMPCkuSqe1oDtfeFLni8NwYs1+fF jBN8qIPMleYwqZJs0S1QojRPdOOrLveTugWImHpHX/ghFZFUnSnmtFUqh+NSncGYskb9 Urng== X-Gm-Message-State: AGRZ1gIDcn2RJ4yiqrVtPiIRbQwjKeu/l4KvNwmgiT/z0eSr+CP0kHgh We75DoZP2y0G9h5apzgWR1iccVymlWGqvqp1WP0= X-Google-Smtp-Source: AJdET5eoCz7we7BM+xSeYhxtXvs03GHRS8jC0LGd0nziz8cHbwaC4Jxyw/+LTUEVlo16olAS6vDL4dnT+34O/N/yeEs= X-Received: by 2002:a9d:4335:: with SMTP id s50mr13896249ote.224.1541534298815; Tue, 06 Nov 2018 11:58:18 -0800 (PST) MIME-Version: 1.0 References: <0289fa26-d157-8a65-389e-61dd7a01fcc4@spamtrap.tnetconsulting.net> <7d595808-fff7-4c1c-d969-362693ab2672@spamtrap.tnetconsulting.net> <4d85ccda-7200-b6e7-8a27-5832e3bdcdba@spamtrap.tnetconsulting.net> In-Reply-To: <4d85ccda-7200-b6e7-8a27-5832e3bdcdba@spamtrap.tnetconsulting.net> From: =?UTF-8?Q?Mantas_Mikul=C4=97nas?= Date: Tue, 6 Nov 2018 21:58:04 +0200 Message-ID: To: gtaylor@tnetconsulting.net Content-Type: multipart/alternative; boundary="0000000000004a42dc057a046c45" Subject: Re: [TUHS] YP / NIS / NIS+ / LDAP X-BeenThere: tuhs@minnie.tuhs.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: The Unix Heritage Society mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: tuhs@minnie.tuhs.org Errors-To: tuhs-bounces@minnie.tuhs.org Sender: "TUHS" --0000000000004a42dc057a046c45 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Nov 6, 2018 at 9:18 PM Grant Taylor via TUHS wrote: > On 11/06/2018 12:07 AM, Mantas Mikul=C4=97nas 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 =E2=80=93 in other protocols (IMAP, SMTP, IRC, the same L= DAP) 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. > 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. > > 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. > 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. > > > It's not commonly used as far as I know =E2=80=93 most new protocols al= ready > > 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. > 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 =E2=80=93 the same client or s= erver 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.) > > > 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=E2=80=BD > > 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)? > Usually, yes. (There is no technical reason why it couldn't run inside TLS, it's just redundant =E2=80=93 OpenLDAP doesn't mind but e.g. Active Directory explici= tly 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 is especially common in Active Directory environments, where the > > DCs might not have a valid TLS certificate. > > O.o=E2=80=BD > > 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 > (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.) --=20 Mantas Mikul=C4=97nas --0000000000004a42dc057a046c45 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Tue, Nov 6,= 2018 at 9:18 PM Grant Taylor via TUHS <tuhs@minnie.tuhs.org> wrote:
On 11/06/2018 12:07 AM, Mantas Mikul=C4=97nas wrote:
> These days the modification generally consists of pam_krb5 added to th= e
> system's PAM configuration.

Hum....=C2=A0 I need to do some reading on that.

> And similarly =E2=80=93 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.=C2=A0 Or take things even further a= nd
do the Kerberos interaction directly.

T= hough from what I've seen on their mailing list, MIT Kerberos developer= s seem to recommend using GSSAPI at minimum, rather than the raw Kerberos A= PIs.
=C2=A0

Yet another reason why all these things are complicated.=C2=A0 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&#= 39; between
> the user and the service, which then may be used for transport encrypt= ion
> (sealing).

Does that mean that the protocols would need to retain the session key
and use it for their other non-Kerberos specific protocols?=C2=A0 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.
=

Well, they can use it, but they don't = have to. It's up to the developer in the end. The earlier kerberized pr= otocols did, because they didn't have any other encryption layer. Most = recent protocols establish encryption in any case (be it TLS or SSHv2 or so= mething else) so they just don't bother calling the SASL (or GSSAPI) se= al functions.
=C2=A0

> It's not commonly used as far as I know =E2=80=93 most new protoco= ls 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.

Kerberos does include modern enctypes (such as aes128/aes256), but= from what *little* I understand about this part, it's still not as goo= d as the modern protocols. (E.g. complete lack of PFS =E2=80=93 the same cl= ient or server always uses the same master key until it's manually rota= ted...)

On the bright side, the *authentication* o= f Kerberos is solid as far as I've heard. (Which, again I know very lit= tle about this part, but I do remember someone saying that it has an actual= security proof, as well as being decently quantum-resistant.)
= =C2=A0

> 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=E2=80=BD

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)?

Usually, yes.

(There is no technical reason why it couldn't run insid= e TLS, it's just redundant =E2=80=93 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 tur= n off the GSSAPI signing/sealing.)
=C2=A0

> This is especially common in Active Directory environments, where the =
> DCs might not have a valid TLS certificate.

O.o=E2=80=BD

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

(This reminds me th= at I've noticed at least one of the MIT Kerberos developers here in TUH= S, who would surely know more about this than I've gathered through bar= ely few years of messing around.)

--
Mantas Mikul=C4=97nas
--0000000000004a42dc057a046c45--