Subject: [saag] SSH Protocol Extensions

From: Phil Lello <[email-masked]>
Date: Wed, 12 Aug 2015 12:21:57 +0100

Hi,

I'm currently working on extensions to the SSH protocol; as I believe the
SecSH WG is effectively dormant, is this list the best place to discuss the
proposals?

Briefly, I am seeking to add support for federated/asserted identities to
SSH, for scenarios where the protocol is used as an application transport
(e.g. git, svn). This involves the client sending a desired username for
authentication, along with a authentication token from a trusted 3rd party.

In the initial implementation, this would be a SAML assertion, although I
intend to make the implementation generic enough to support other
mechanisms. Trust relationships for valid IdPs would be handled according
to local policy.

A related extension will be a formal websocket binding for SSH, and I
expect the reference implementation of this to be a patch to Gerrit (a
git-based code review tool that contains an embedded Java SSH server).

Phil Lello

---

From: Stefan Winter <[email-masked]>
Date: Wed, 12 Aug 2015 13:25:03 +0200

Hi,

> Briefly, I am seeking to add support for federated/asserted identities
> to SSH, for scenarios where the protocol is used as an application
> transport (e.g. git, svn). This involves the client sending a desired
> username for authentication, along with a authentication token from a
> trusted 3rd party.
> 
> In the initial implementation, this would be a SAML assertion

The above is pretty much exactly what the ABFAB working group has been
working on for the last couple of years. Federated SSH access is their
number one real-life case AFAICT.

Did you review their specs yet?

Greetings,

Stefan Winter

, although
> I intend to make the implementation generic enough to support other
> mechanisms. Trust relationships for valid IdPs would be handled
> according to local policy.
> 
> _______________________________________________
> saag mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/saag
> 

-- 
Stefan WINTER
Ingenieur de Recherche
Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et
de la Recherche
6, rue Richard Coudenhove-Kalergi
L-1359 Luxembourg

Tel: +352 424409 1
Fax: +352 422473

PGP key updated to 4096 Bit RSA - I will encrypt all mails if the
recipient's key is known to me

http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xC0DE6A358A39DC66

---

From: Phil Lello <[email-masked]>
Date: Wed, 12 Aug 2015 12:30:20 +0100

Many thanks Stefan, I wasn't aware of the ABFAB WG, I will review their
specs.

Phil

---

From: Michael Richardson <[email-masked]>
Date: Wed, 12 Aug 2015 10:57:16 -0400

> Many thanks Stefan, I wasn't aware of the ABFAB WG, I will review their

Is ABFAB actually writing SSH extensions?
My (three-minute review) impression they are writing GSSAPI extensions, and
SSH can use GSSAPI.

If they don't suit, where would Phil go?

I think it would have to be an Independant Stream or AD sponsored, but I'm
sure that using saag to review would be great.

It would be very nice to be able to get a list of names of the server
that are "also" names... and it would be nice to be able to get a 302-type
redirect...

-- 
]               Never tell me the odds!                 | ipv6 mesh networks [ 
]   Michael Richardson, Sandelman Software Works        | network architect  [ 
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

---

From: Nico Williams <[email-masked]>
Date: Wed, 12 Aug 2015 10:50:17 -0500

> Is ABFAB actually writing SSH extensions?

No, they aren't.

> My (three-minute review) impression they are writing GSSAPI extensions, and

Yes, that's it.

> If they don't suit, where would Phil go?

In principle the old SECSH WG mailing list is to be used for discussing
SSHv2 extensions.  We might want to create an @ietf.org list though,
though if the volume is low enough SAAG works for me.

As for SSHv2 and federation, I'd like to understand what functionality
is needed that using GSS/ABFAB can't provide.

> sure that using saag to review would be great.

Yes.

> that are "also" names... and it would be nice to be able to get a 302-type

Hmm?  You mean ask an SSHv2 server to list its aliases?  And to give you
temporary redirects?

Nico
--

---

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: Phil Lello <[email-masked]>
Date: Wed, 12 Aug 2015 17:13:02 +0100

> is needed that using GSS/ABFAB can't provide.

I'm still getting up to speed on GSS/ABFAB, so reserve the right to reverse
my position, however it seems to me that GSS/ABFAB is reasonably complex to
implement, compared to defining a new authentication method. Whilst
GSS/ABFAB seems well suited to large enterprise environments, I'm not
convinced it is suitable for allowing federated identities to be used with
light-weight stand-alone ssh servers. Admittedly, I'm currently put off by
what appears to be a steep learning curve once GSS, RADIUS, et al. come
into the mix, but with my 'lazy coder' hat on, it doesn't seem unreasonable
that other potential implementers will feel the same.

> I'm not sure I understand the reason for this, but wouldn't reverse DNS on
the target hostname achieve this?

Phil

---

From: Viktor Dukhovni <[email-masked]>
Date: Wed, 12 Aug 2015 16:22:14 +0000

On Wed, Aug 12, 2015 at 05:13:02PM +0100, Phil Lello wrote:

> Admittedly, I'm currently put off by

Is this confusing implementation with deployment?

Once the platform's GSSAPI library supports ABFAB, it becomes a
question of deployment, not implementation.

-- 
	Viktor.

---

From: Nico Williams <[email-masked]>
Date: Wed, 12 Aug 2015 11:43:43 -0500

> that other potential implementers will feel the same.

If you ignore all of the details of the GSS-API for the moment and focus
just on the protocol, there's nothing complex.  It's a synchronous
exchange of opaque messages ("security context tokens") for some
mechanism.  You get to define these messages (unless ABFAB fits the
bill, then you can use ABFAB's).  You don't have to implement RFC2744
nor do you have to use existing implementations.  There's only one set
of bits-on-the-wire added by GSS, and that's on the first security
context token.

There are details of how to generate the mechanism name, but you don't
have to write code to do that.  You do it once, confirm that others get
the same result, and write down the results in your code.  There's also
a "MIC token" to bind the authentication to the SSHv2 key exchange.

That's it.  No need for GSS functions.  No need for a pluggable GSS
library.

"defining a new authentication method" seems unnecessary when there
already is one that can do what you want.

The complete specs are complex, of course, but that's only because they
deal with things that you don't have to.

Nico
--

---

From: Nico Williams <[email-masked]>
Date: Wed, 12 Aug 2015 11:45:40 -0500

I should add that we have a great example of how the complexity of the
GSS-API is really just about the API, and how it can be sidestepped:
RFC5802.

RFC5802 specifies a mechanism for GSS and SASL that can be implemented
without reference to GSS.

Nico
--

---

From: Nico Williams <[email-masked]>
Date: Wed, 12 Aug 2015 11:50:11 -0500

> Is this confusing implementation with deployment?

I don't see a mention of deployment.  I suspect that Phil wants to
implement from scratch, not use an off-the-shelf implementation.

> question of deployment, not implementation.

I should note that one should be able to implement and deploy an SSH
client and server that use a system GSS library for some GSS mechanisms,
and a non-system GSS mechanism used directly without reference to any
GSS libraries.  Some SASL and SMB implementations do this sort of thing.

Nico
--

---

From: Sam Hartman <[email-masked]>
Date: Wed, 12 Aug 2015 13:36:58 -0400

>>>>> "Viktor" == Viktor Dukhovni <[email-masked]> writes:

    Viktor> On Wed, Aug 12, 2015 at 05:13:02PM +0100, Phil Lello wrote:
    >> Admittedly, I'm currently put off by what appears to be a steep
    >> learning curve once GSS, RADIUS, et al. come into the mix, but
    >> with my 'lazy coder' hat on, it doesn't seem unreasonable that
    >> other potential implementers will feel the same.

    Viktor> Is this confusing implementation with deployment?

    Viktor> Once the platform's GSSAPI library supports ABFAB, it
    Viktor> becomes a question of deployment, not implementation.

    Viktor> -- Viktor.

to be clear, ABFAB is kind of heavy-weight if you really want to use a
SAML assertion to authenticate for ssh.  It does support doing that at a
theoretical level, and we do actually have running code with people
using SAML assertions to carry attribute statements for ssh in ABFAB.

However, the SAML EC folks have running code for using SAML assertions
for ssh authentication and that removes a couple of layers from the
system, so I think it's a better fit for what I understand of this use
case.

---

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
>