Re: [kitten] [saag] SSH Protocol Extensions

Simon Josefsson <> Wed, 12 August 2015 17:54 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id A22A71ABD3A; Wed, 12 Aug 2015 10:54:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.551
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id apimQqncOrX6; Wed, 12 Aug 2015 10:54:54 -0700 (PDT)
Received: from ( [IPv6:2001:9b0:1:1702::100]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 426A91ABD38; Wed, 12 Aug 2015 10:54:54 -0700 (PDT)
Received: from ([]) (authenticated bits=0) by (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 <>
To: Sam Hartman <>
Message-ID: <>
In-Reply-To: <>
References: <> <>
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
X-Virus-Status: Clean
Archived-At: <>
Cc:, Phil Lello <>,,
Subject: Re: [kitten] [saag] SSH Protocol Extensions
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Common Authentication Technologies - Next Generation <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-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

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.


> 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 <> 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
>     Phil>