Subject: Re: [kitten] [saag] SSH Protocol Extensions

From: Sam Hartman <[email-masked]>
Date: Wed, 12 Aug 2015 12:04:10 -0400

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 <[email-masked]> writes:

    Phil>    Hi, I'm currently working on extensions to the SSH
    Phil> protocol; as I believe the SecSH WG is effectively dormant, is
    Phil> this list the best place to discuss the proposals?  Briefly, I
    Phil> am seeking to add support for federated/asserted identities to
    Phil> SSH, for scenarios where the protocol is used as an
    Phil> application transport (e.g. git, svn). This involves the
    Phil> client sending a desired username for authentication, along
    Phil> with a authentication token from a trusted 3rd party.  In the
    Phil> initial implementation, this would be a SAML assertion,
    Phil> although I intend to make the implementation generic enough to
    Phil> support other mechanisms. Trust relationships for valid IdPs
    Phil> would be handled according to local policy.  A related
    Phil> extension will be a formal websocket binding for SSH, and I
    Phil> expect the reference implementation of this to be a patch to
    Phil> Gerrit (a git-based code review tool that contains an embedded
    Phil> Java SSH server).  Phil Lello
    Phil> _______________________________________________ saag mailing
    Phil> list [email-masked] https://www.ietf.org/mailman/listinfo/saag

---

From: Simon Josefsson <[email-masked]>
Date: Wed, 12 Aug 2015 19:54:37 +0200

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

> (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> 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 [email-masked]
>     Phil> https://www.ietf.org/mailman/listinfo/saag

---

From: Nico Williams <[email-masked]>
Date: Wed, 12 Aug 2015 13:37:01 -0500

> relevant depending on use-case.

If Phil needs a SAML, one-message authentiation method with no proof of
possession, then a new SSHv2 userauth method is probably best (since the
GSS userauth method uses MIC tokens for channel binding).  Would the
SAML token be possible to bind to an SSHv2 session?  I would hope so.

> results in poor user experience.

Probably not an issue for SSHv2.

> be relevant to look into, but it does not support GSS-API so SSH support

See above comment about MIC tokens and channel binding.  Also, without a
server-side proof of possession the channel binding can only protect
against token reuse, and the user will still depend on the use of server
host public keys for server authentication (which may not be a problem).

Nico
--

---

From: Benjamin Kaduk <[email-masked]>
Date: Wed, 12 Aug 2015 21:43:53 -0400 (EDT)

> be relevant to look into, but it does not support GSS-API so SSH support

The spec just hit AUTH48 today; I am given to understand there are a
couple of implementations floating around.

-Ben

---

From: "Cantor, Scott" <[email-masked]>
Date: Thu, 13 Aug 2015 13:48:45 +0000

>SAML token be possible to bind to an SSHv2 session?  I would hope so.

Except it's not defined how one would acquire the token, and that's not trivial to do properly. If SAML IdPs don't support the profile, then you're nowhere. That's the problem the saml-ec mechanism was attacking fundamentally, reuse of an appropriate SAML profile to do the job.

-- Scott

---

From: Phil Lello <[email-masked]>
Date: Sat, 15 Aug 2015 08:52:49 +0100

Thanks to everyone for their input. I think my efforts would be better
directed at extending the SSH protocol to support SASL; although SASL/GSS
binding (RFC5801) is possible in some cases, it isn't always.

Is there an industry standard for SASL in C? I'm aware of
https://tools.ietf.org/html/draft-newman-sasl-c-api-03 from April 2004 and
the GSASL http://www.gnu.org/software/gsasl/ library, but am looking for a
standard mechanism where adding new SASL mechanisms is a case of adding a
run-time plugin (.so / .dll).

Phil Lello

On Thu, Aug 13, 2015 at 2:48 PM, Cantor, Scott <[email-masked]> wrote:

> On 8/12/15, 2:37 PM, "Kitten on behalf of Nico Williams" <
> [email-masked] on behalf of [email-masked]> wrote:
>
> Except it's not defined how one would acquire the token, and that's not
> trivial to do properly. If SAML IdPs don't support the profile, then you're
> nowhere. That's the problem the saml-ec mechanism was attacking
> fundamentally, reuse of an appropriate SAML profile to do the job.
>
> -- Scott
>
> _______________________________________________
> saag mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/saag
>

---

From: Quanah Gibson-Mount <[email-masked]>
Date: Mon, 17 Aug 2015 09:57:12 -0700

--On Saturday, August 15, 2015 9:52 AM +0100 Phil Lello 
<[email-masked]> wrote:

> https://tools.ietf.org/html/draft-newman-sasl-c-api-03 from April 2004
> and the GSASL http://www.gnu.org/software/gsasl/ library, but am looking
> for a standard mechanism where adding new SASL mechanisms is a case of
> adding a run-time plugin (.so / .dll).

<http://www.cyrusimap.org/mediawiki/index.php/Downloads#SASL_Library>

--Quanah

--

Quanah Gibson-Mount
Platform Architect
Zimbra, Inc.
--------------------
Zimbra ::  the leader in open source messaging and collaboration