Re: [saag] [kitten] SSH Protocol Extensions

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 <cantor.2@osu.edu> wrote:

> On 8/12/15, 2:37 PM, "Kitten on behalf of Nico Williams" <
> kitten-bounces@ietf.org on behalf of nico@cryptonector.com> wrote:
>
> >On Wed, Aug 12, 2015 at 07:54:37PM +0200, Simon Josefsson wrote:
> >> 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.
> >
> >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.
>
> 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
> saag@ietf.org
> https://www.ietf.org/mailman/listinfo/saag
>