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 64208d75 for ; Tue, 6 Nov 2018 09:14:18 +0000 (UTC) Received: by minnie.tuhs.org (Postfix, from userid 112) id 8E387A245A; Tue, 6 Nov 2018 19:14:17 +1000 (AEST) Received: from minnie.tuhs.org (localhost [127.0.0.1]) by minnie.tuhs.org (Postfix) with ESMTP id DA1E0A22F9; Tue, 6 Nov 2018 19:13:53 +1000 (AEST) Received: by minnie.tuhs.org (Postfix, from userid 112) id 1B11DA2162; Tue, 6 Nov 2018 17:07:50 +1000 (AEST) Received: from mail-ot1-f42.google.com (mail-ot1-f42.google.com [209.85.210.42]) by minnie.tuhs.org (Postfix) with ESMTPS id 1AF50A215E for ; Tue, 6 Nov 2018 17:07:44 +1000 (AEST) Received: by mail-ot1-f42.google.com with SMTP id k98so297660otk.3 for ; Mon, 05 Nov 2018 23:07:44 -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=sEq0RWMz4VQXY4n35Ymd/ITbq+M+Kiy73nPrij90y3M=; b=XXkV+smaavIMdjUIaMJdOUvJ5tm9c63XqIdeM4Q0FA2f89mnDcS/lEE5WzcvmFRRYL 3ApUpgs+zrTWYsyg+Fd3J8KzDvQi1ueWd0XtdSE7EFUCU/hckgzuF4EL2dTzhwG4/NSJ ZoSAnygmJumuz4P1XMl8rkxi7cq28D4C/Fb7lDjIbO47UpyINyGHMiViMSlGo3HTKHmk T2oG0icu2vAgfO2SCLN6QJQY766NIolgWp64h+IkRBxt7PKP634cY3crcbBYTB9RU12C eaiMORZHvqNlfZ9HtEfNftily1knC2SE/eavrfmu+uqk6RaVspVbYiTdLKTPdSXTl3U2 p99g== 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=sEq0RWMz4VQXY4n35Ymd/ITbq+M+Kiy73nPrij90y3M=; b=m6GTLdSFOTqY5wZH3YtWavU4cmDK/WeVhIrLhmy6cjdFQDv2CwpICCaulj0Ne2H0Xq XRg2CbYtfSMg+/FlEDKo7p2dLvn9W5UzYTYLWFISEjBIf/73tfL6t9i6m96NHxlgouzY 9RXnaFniqn40WxSbE0EMpJ+HnZxro4xfDxtmG41NvjJwnUWxXKN9WBZlHpD4l62JC1Jj yxposHYRQuFtMusQX4hHoUieol43+3hhBgh8bVTE8C29hp/dvP4rlyUjRXuHl6Kl/c4p 7w23i5RcAmNlZNZ7fkTXgTWFG3mLEUpcy/EpZMy47KZRnQJxamrlvYumC8zSZDh0XjbR YlBg== X-Gm-Message-State: AGRZ1gKgvNU/Mv+ZvsfwmFgIFh/A8W4sDNYPrrDJO5p+YjvXu4tzz20I bAGonFAAR8+Ic2fOpKa8cHLX8MuHL34nvBfxvG4= X-Google-Smtp-Source: AJdET5eIA9sI6aG9QKRs1ro30PPxS02tcvjvzixPtsZLYX/Xx4Kve/93WnwXHzpc0jw79Od640wL1Ez63qdzIOEts4k= X-Received: by 2002:a9d:4c01:: with SMTP id l1mr1561160otf.242.1541488063272; Mon, 05 Nov 2018 23:07:43 -0800 (PST) MIME-Version: 1.0 References: <0289fa26-d157-8a65-389e-61dd7a01fcc4@spamtrap.tnetconsulting.net> <7d595808-fff7-4c1c-d969-362693ab2672@spamtrap.tnetconsulting.net> In-Reply-To: <7d595808-fff7-4c1c-d969-362693ab2672@spamtrap.tnetconsulting.net> From: =?UTF-8?Q?Mantas_Mikul=C4=97nas?= Date: Tue, 6 Nov 2018 09:07:31 +0200 Message-ID: To: gtaylor@tnetconsulting.net Content-Type: multipart/alternative; boundary="0000000000006fddb80579f9a8cb" 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" --0000000000006fddb80579f9a8cb Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Nov 6, 2018 at 8:40 AM Grant Taylor via TUHS wrote: > On 11/05/2018 03:34 PM, Dan Cross wrote: > > You can use a modified `login` that will validate you against a KDC. > > ACK > These days the modification generally consists of pam_krb5 added to the system's PAM configuration. > > Modifications have been made to e.g. SSH so that one can authenticate a= n > > SSH session via GSSAPI, which usually wraps Kerberos. If I recall, > > GSSAPI might be one of the lasting legacies of the DCE, though I may be > > misremembering history. > > *nod* > 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. > Kerberos solves the authentication problem, but does not provide a > > directory service nor does it solve the authorization problem (though > > some "kerberized" services could use a library to consult a > > user-provided file of ACLs mapping principals to privileges). On Unix, > > "authorization data" includes things like your UID and the set of group= s > > you belong to (or more precisely, your process's UIDs and GIDs/groups). > > Kerberos provided support for privacy via encryption libraries, and it > > provided support for integrity via hashing/checksumming/signature > > libraries. "Kerberized" versions of network services such as telnet, > > FTP, rsh/rlogin/rcp etc all provided support for authentication via the > > baseline Kerberos protocol as well as privacy and integrity via > > connection-level encryption and checksumming. > > I was not aware that Kerberos could provide privacy (encryption) for > kerberized services. I (naively) thought that Kerberos was > authentication that other things could use to make access control > decisions. > 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). It's not commonly used as far as I know =E2=80=93 most new protocols already hav= e their own security layers such as TLS or SSH. Actually LDAP is the only still-widespread protocol that comes to mind whose implementations frequently make use of Kerberos-based encryption (via GSSAPI). This is especially common in Active Directory environments, where the DCs might not have a valid TLS certificate. (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.) --=20 Mantas Mikul=C4=97nas --0000000000006fddb80579f9a8cb Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Tue, Nov 6,= 2018 at 8:40 AM Grant Taylor via TUHS <tuhs@minnie.tuhs.org> wrote:
On 11/05/2018 03:34 PM, Dan Cross wrote:
> You can use a modified `login` that will validate you against a KDC.
ACK

These days the modification general= ly consists of pam_krb5 added to the system's PAM configuration.
<= div>

> Modifications have been made to e.g. SSH so that one can authenticate = an
> SSH session via GSSAPI, which usually wraps Kerberos. If I recall, > GSSAPI might be one of the lasting legacies of the DCE, though I may b= e
> misremembering history.

*nod*

And similarly =E2=80=93 in other = protocols (IMAP, SMTP, IRC, the same LDAP) one can authenticate a session v= ia SASL, which usually wraps GSSAPI, which usually wraps Kerberos.

> Kerberos solves the authentication problem, but does not provide a > directory service nor does it solve the authorization problem (though =
> some "kerberized" services could use a library to consult a =
> user-provided file of ACLs mapping principals to privileges). On Unix,=
> "authorization data" includes things like your UID and the s= et of groups
> you belong to (or more precisely, your process's UIDs and GIDs/gro= ups).
> Kerberos provided support for privacy via encryption libraries, and it=
> provided support for integrity via hashing/checksumming/signature
> libraries. "Kerberized" versions of network services such as= telnet,
> FTP, rsh/rlogin/rcp etc all provided support for authentication via th= e
> baseline Kerberos protocol as well as privacy and integrity via
> connection-level encryption and checksumming.

I was not aware that Kerberos could provide privacy (encryption) for
kerberized services.=C2=A0 I (naively) thought that Kerberos was
authentication that other things could use to make access control decisions= .

You're right, it's primarily = an authentication protocol. But due to the way it works, it *also* negotiat= es a 'session key' between the user and the service, which then may= be used for transport encryption (sealing). It's not commonly used as = far as I know =E2=80=93 most new protocols already have their own security = layers such as TLS or SSH.

Actually LDAP is the on= ly still-widespread protocol that comes to mind whose implementations frequ= ently make use of Kerberos-based encryption (via GSSAPI). This is especiall= y common in Active Directory environments, where the DCs might not have a v= alid TLS certificate.

(I seem to recall kerberized= Telnet didn't survive because it was limited to DES/3DES for an odd re= ason. Didn't quite understand why that was the case, though.)

--
Mantas Mikul=C4=97nas
--0000000000006fddb80579f9a8cb--