IETF Logo Mail Archive

Re: [kitten] GSS-API / SAML as authentication mechanism

Simon Josefsson <simon@josefsson.org> Fri, 21 April 2023 07:18 UTC

Return-Path: <simon@josefsson.org>
X-Original-To: kitten@ietfa.amsl.com
Delivered-To: kitten@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4D43C152DBA for <kitten@ietfa.amsl.com>; Fri, 21 Apr 2023 00:18:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.398
X-Spam-Level:
X-Spam-Status: No, score=-4.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=josefsson.org header.b="d3tQ6yuL"; dkim=pass (2736-bit key) header.d=josefsson.org header.b="CF6nHa+/"
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YfQs8zhHPCTZ for <kitten@ietfa.amsl.com>; Fri, 21 Apr 2023 00:18:31 -0700 (PDT)
Received: from uggla.sjd.se (uggla.sjd.se [IPv6:2001:9b1:8633::107]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EC4C0C151B1F for <kitten@ietf.org>; Fri, 21 Apr 2023 00:18:31 -0700 (PDT)
DKIM-Signature: v=1; a=ed25519-sha256; q=dns/txt; c=relaxed/relaxed; d=josefsson.org; s=ed2303; h=Content-Type:MIME-Version:Message-ID:In-Reply-To :Date:References:Subject:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding :Content-ID:Content-Description; bh=3Dz0sXaYTt6AJIsYSt2wkIgJ3Vq+2SM8OhjR+kZgDr4=; t=1682061506; x=1683271106; b=d3tQ6yuLyhNtCax3yAw974FKOPvXBW34fgH0wVfDPhEm42jFr11yMng7ZkbQh8mTkwLwNMGNPmg Tny9N15ecBA==;
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=josefsson.org; s=rsa2303; h=Content-Type:MIME-Version:Message-ID: In-Reply-To:Date:References:Subject:Cc:To:From:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=3Dz0sXaYTt6AJIsYSt2wkIgJ3Vq+2SM8OhjR+kZgDr4=; t=1682061506; x=1683271106; b=CF6nHa+/opINqO6j+NXWlNaHUOpaNBLZvrKxPY1BOqaLZkrSyjtfLVbzWHTPwUeMBJDSav2aZj0 DNBnfJHTZabNEZL95yYG+x9yTHJav5YaRfyrMdyIE58qIU6tGb/VIxaaV7mMtq+HyVG/MWJ3KtCvj S1LbPEL12sTNx3E3RX+fJ7h8rf11CIYoH5eqKe+5L0BaAGsNQFuEgCrDo+24cpIy+VoXA4nlFnAMU tbGX8KbNcJkPVnEBirw2equvVP7BQmkuI03jy5omspH9GwFO6l6W9KSpzK+nJpLj1miSHrpw6iR6K p+++neiKnfdcgisoDdq5xAQTY1dSBAn8AJ7cV+bPgSj4q5MgVnrYgeRUZykXe04m9MUMuPAvOFHT3 IZf4EAwLmJkfEtKxmK1FH5DtQ+36IYF4Anngc5X0TMhcQ/kLqEb1fB6aI061Gn2ebJvkTI5bp;
Received: from [2001:9b1:41ac:ff00:823f:5dff:fe09:16ac] (port=48948 helo=kaka) by uggla.sjd.se with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.95) (envelope-from <simon@josefsson.org>) id 1ppl2F-00AR6e-Et; Fri, 21 Apr 2023 07:18:23 +0000
From: Simon Josefsson <simon@josefsson.org>
To: Srinivas Cheruku <srinivas.cheruku@gmail.com>
Cc: "kitten@ietf.org" <kitten@ietf.org>
References: <PN2P287MB0381F58334C75A8ABED02D65F69B9@PN2P287MB0381.INDP287.PROD.OUTLOOK.COM> <87a5zdw8lk.fsf@kaka.sjd.se> <PN2P287MB0381A72190868E5AD8F60035F69B9@PN2P287MB0381.INDP287.PROD.OUTLOOK.COM>
OpenPGP: id=B1D2BD1375BECB784CF4F8C4D73CF638C53C06BE; url=https://josefsson.org/key-20190320.txt
X-Hashcash: 1:22:230421:kitten@ietf.org::tm/Cn5makMQ6S+HY:HC9g
X-Hashcash: 1:22:230421:srinivas.cheruku@gmail.com::gkcv+oItyR1gp3M6:BHEg
Date: Fri, 21 Apr 2023 09:18:33 +0200
In-Reply-To: <PN2P287MB0381A72190868E5AD8F60035F69B9@PN2P287MB0381.INDP287.PROD.OUTLOOK.COM> (Srinivas Cheruku's message of "Wed, 12 Apr 2023 16:01:34 +0000")
Message-ID: <877cu53dpy.fsf@kaka.sjd.se>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.1 (gnu/linux)
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha256"; protocol="application/pgp-signature"
Archived-At: <https://mailarchive.ietf.org/arch/msg/kitten/s_rstXf1m5GNuqsBtzY_pHhHrkg>
Subject: Re: [kitten] GSS-API / SAML as authentication mechanism
X-BeenThere: kitten@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Common Authentication Technologies - Next Generation <kitten.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/kitten>, <mailto:kitten-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/kitten/>
List-Post: <mailto:kitten@ietf.org>
List-Help: <mailto:kitten-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/kitten>, <mailto:kitten-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 21 Apr 2023 07:18:38 -0000

Srinivas Cheruku <srinivas.cheruku@gmail.com> writes:

> Simon,
>
> Thank you very much for your inputs.
>
> Does this mean it should be ok to use SAML20EC where application
> design assumes per-connection SASL authentication?

Yes, SAML20EC should handle this problem, although it requires tighter
and deeper SAML-knowledge at both ends.

/Simon

> Thanks,
> Srini
>
>
> On 12/04/23, 18:39, "Simon Josefsson" <simon@josefsson.org> wrote:
> Srinivas Cheruku
> <srinivas.cheruku@gmail.com<mailto:srinivas.cheruku@gmail.com>>
> writes:
>
>> Hello All,
>>
>> As you know, companies slowly starting thinking on moving away from
>> Kerberos Infrastructure (e.g. MS AD) and relying on MS Azure AD or any
>> other IdP for their authentication needs. We came across some new
>> companies where they do not have any Kerberos infrastructure like MS
>> AD at all. And, there are still thick client applications using
>> GSS-API/Kerberos for the authentication and so was thinking on support
>> for GSS-API/SAML for these client applications.
>>
>> I found two references as below:
>>
>>   1.  SAML Enhanced Client SASL and GSS-API Mechanisms -
>> https://datatracker.ietf.org/doc/draft-ietf-kitten-sasl-saml-ec/
>>   2.  RFC 6595 – A Simple Authentication and Security Layer (SASL) and
>> GSS-API Mechanism for the Security Assertion Markup Language (SAML) -
>> https://www.rfc-editor.org/rfc/rfc6595
>>
>> Are there any known implementations of these?
>
> Yes, GNU SASL supports RFC6595 SAML20:
>
> https://www.gnu.org/software/gsasl/manual/html_node/SAML20.html
>
> However the deployment experience with IMAP/SMTP/XMPP and some other
> SASL-using protocols has not worked out well for SAML20: the practice of
> opening multiple connections and performing SASL authentication on each
> of them pretty much destroyed the functionality here, where most
> application design assumes per-connection SASL authentication is
> non-interactive after an initial user prompt for passwords etc.
>
> We never brought it up to the GSS-API layer to test with SSH etc, since
> it is lacking some security features that makes it a bit too fragile.
> SAML20EC improved on those, but the application design issue is still a
> concern.
>
> /Simon
>
> _______________________________________________
> Kitten mailing list
> Kitten@ietf.org
> https://www.ietf.org/mailman/listinfo/kitten
>

v2.23.0 | Report a Bug | By Email