SSH extensions for Asserted Identities and WebSocket transport
Phil Lello <[email protected]>
| Newsgroups | gmane.ietf.secsh |
|---|---|
| Message-ID | <CAPofZaH0bkosr3JxgG6j+b9nZPOSag3UDCibLivgsDghaJFX0Q@mail.gmail.com> |
Hi Jeff et al., Many thanks for the encouragement. I've exchanged a few emails on other IETF lists, and am currently working on test implementations as time permits. Before I dive into the proposed solution(s), I'll describe my motivation. Essentially, I'd like to be able to extend existing application-servers that use SecSH as a transport to support authentication by federated identities such as SAML. My initial point of attack was going to be adding a generic "asserted identity" mechanism to the protocol to allow a client to present time-limited signed assertions that the server would accept or reject according to local policy. I have now shifted focus slightly, and am looking to add support for SASL mechanisms to SSH, and leverage efforts already made at integrating SAML and OpenID with non-web transports. Since the SAML and OpenID RFCs still involve a web loop, it probably makes sense to add an "asserted identity" SASL mechanism too. A related extension is a standard WebSocket binding for SecSH; this is specifically intended for applications that support the SSH protocol and also expose a web interface. I'm specifically thinking of Gerrit here, but I'd be surprised if there aren't others. Making the HTTP portion of an application server widely accessible is generally simpler in a corporate environment than opening up access to other port numbers, so this would enable wider deployment of SSH-as-a-transport. Phil On Mon, Aug 24, 2015 at 10:20 PM, Jeffrey Hutzelman <[email protected]> wrote: > On Tue, 2015-08-11 at 07:27 +0100, Phil Lello wrote: > > Hi all, > > > > Is this list still in use? I am working on an extension to SSH > > authentication, and would like to create an RFC to standardise the > > mechanism. > > > As Tom points out, this list doesn't get much traffic these days. > However, it's probably still the best place to reach SSH implementors > and other protocol experts. So by all means, if you have an extension > to propose, tell us about it. > > -- Jeff > >