Re: [saag] SSH Protocol Extensions
Simon Josefsson <simon@josefsson.org> Wed, 12 August 2015 17:54 UTC
Return-Path: <simon@josefsson.org>
X-Original-To: saag@ietfa.amsl.com
Delivered-To: saag@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A22A71ABD3A; Wed, 12 Aug 2015 10:54:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.551
X-Spam-Level:
X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id apimQqncOrX6; Wed, 12 Aug 2015 10:54:54 -0700 (PDT)
Received: from duva.sjd.se (duva.sjd.se [IPv6:2001:9b0:1:1702::100]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 426A91ABD38; Wed, 12 Aug 2015 10:54:54 -0700 (PDT)
Received: from latte.josefsson.org ([155.4.17.3]) (authenticated bits=0) by duva.sjd.se (8.14.4/8.14.4/Debian-4) with ESMTP id t7CHsdt4030467 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT); Wed, 12 Aug 2015 19:54:40 +0200
Date: Wed, 12 Aug 2015 19:54:37 +0200
From: Simon Josefsson <simon@josefsson.org>
To: Sam Hartman <hartmans-ietf@mit.edu>
Message-ID: <20150812195437.2e03c0c8@latte.josefsson.org>
In-Reply-To: <tsltws4ze6d.fsf@mit.edu>
References: <CAPofZaFwCdNKzM42HJMJzLsx+VSVt07Jp+FHA7rV1g7+X7RNNQ@mail.gmail.com> <tsltws4ze6d.fsf@mit.edu>
X-Mailer: Claws Mail 3.11.1 (GTK+ 2.24.25; x86_64-pc-linux-gnu)
MIME-Version: 1.0
Content-Type: multipart/signed; micalg="pgp-sha256"; boundary="Sig_/1XeZTu2_X=gY31QPyqKsrNv"; protocol="application/pgp-signature"
X-Virus-Scanned: clamav-milter 0.98.7 at duva.sjd.se
X-Virus-Status: Clean
Archived-At: <http://mailarchive.ietf.org/arch/msg/saag/CWwouk1Gd3np-2BVU5R8bypCSws>
Cc: kitten@ietf.org, saag@ietf.org, draft-ietf-kitten-sasl-saml-ec@tools.ietf.org
Subject: Re: [saag] SSH Protocol Extensions
X-BeenThere: saag@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Security Area Advisory Group <saag.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/saag>, <mailto:saag-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/saag/>
List-Post: <mailto:saag@ietf.org>
List-Help: <mailto:saag-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/saag>, <mailto:saag-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 12 Aug 2015 17:54:57 -0000
Or look into already published RFC 6616 for OpenID in SASL or RFC 6595 on SAML in SASL. SAML-EC avoids the web loop, and may indeed be more relevant depending on use-case. I believe the problem with these mechanisms has been: 1) They are stateless -- if you need to open many connections, or open them often, you need one OpenID/SAML authentication per connection which results in poor user experience. 2) They are tied to a particular federation system. Sometimes this is not a problem, but I imagine sometimes the client/server does not know what system is the most appriate to use until a web loop has been invoked. The OAuth SASL mechanism (long delayed, still being worked on) may also be relevant to look into, but it does not support GSS-API so SSH support is not a given. I believe there is room for improvement in this area, so Phil, please let us know about your progress. If you send me an email I may assist offlist with some advice too. /Simon > I think that RFC 4462 plus the SAML ECP mechanism > (draft-ietf-kitten-sasl-saml-ec) can do what you're talking about and > is probably a fairly good secure way of using a SAML assertion to > authenticate to SSH. > >>>>> "Phil" == Phil Lello <phil@dunlop-lello.uk> writes: > > Phil> Hi, I'm currently working on extensions to the SSH > Phil> protocol; as I believe the SecSH WG is effectively dormant, > Phil> is this list the best place to discuss the proposals? > Phil> Briefly, I am seeking to add support for federated/asserted > Phil> identities to SSH, for scenarios where the protocol is used > Phil> as an application transport (e.g. git, svn). This involves > Phil> the client sending a desired username for authentication, > Phil> along with a authentication token from a trusted 3rd > Phil> party. In the initial implementation, this would be a SAML > Phil> assertion, although I intend to make the implementation > Phil> generic enough to support other mechanisms. Trust > Phil> relationships for valid IdPs would be handled according to > Phil> local policy. A related extension will be a formal > Phil> websocket binding for SSH, and I expect the reference > Phil> implementation of this to be a patch to Gerrit (a git-based > Phil> code review tool that contains an embedded Java SSH > Phil> server). Phil Lello > Phil> _______________________________________________ saag > Phil> mailing list saag@ietf.org > Phil> https://www.ietf.org/mailman/listinfo/saag
- [saag] SSH Protocol Extensions Phil Lello
- Re: [saag] SSH Protocol Extensions Stefan Winter
- Re: [saag] SSH Protocol Extensions Phil Lello
- Re: [saag] SSH Protocol Extensions Michael Richardson
- Re: [saag] SSH Protocol Extensions Nico Williams
- Re: [saag] SSH Protocol Extensions Sam Hartman
- Re: [saag] SSH Protocol Extensions Phil Lello
- Re: [saag] SSH Protocol Extensions Viktor Dukhovni
- Re: [saag] SSH Protocol Extensions Nico Williams
- Re: [saag] SSH Protocol Extensions Nico Williams
- Re: [saag] SSH Protocol Extensions Nico Williams
- Re: [saag] SSH Protocol Extensions Sam Hartman
- Re: [saag] SSH Protocol Extensions Simon Josefsson
- Re: [saag] SSH Protocol Extensions Nico Williams
- Re: [saag] SSH Protocol Extensions Benjamin Kaduk
- Re: [saag] [kitten] SSH Protocol Extensions Cantor, Scott
- Re: [saag] [kitten] SSH Protocol Extensions Phil Lello