Re: [saag] [kitten] SSH Protocol Extensions

Phil Lello <phil@dunlop-lello.uk> Sat, 15 August 2015 07:52 UTC

Return-Path: <phil@dunlop-lello.uk>
X-Original-To: saag@ietfa.amsl.com
Delivered-To: saag@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F39D51ACDA9 for <saag@ietfa.amsl.com>; Sat, 15 Aug 2015 00:52:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.977
X-Spam-Level:
X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mN0ECWJHDPXR for <saag@ietfa.amsl.com>; Sat, 15 Aug 2015 00:52:51 -0700 (PDT)
Received: from mail-lb0-f180.google.com (mail-lb0-f180.google.com [209.85.217.180]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E157A1ACDA8 for <saag@ietf.org>; Sat, 15 Aug 2015 00:52:50 -0700 (PDT)
Received: by lbbsx3 with SMTP id sx3so56857731lbb.0 for <saag@ietf.org>; Sat, 15 Aug 2015 00:52:49 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=/NZajXdNxebbiv7+EGaxDrfsm3CALP842d7A1jY6EL0=; b=froz9toRfjdqZDBNPvuv4I8jpOfy+g3Jx+G1E0r03k7pkNAqVAgD/tKnLKb6tIUwx1 50/7gZPAMssM9xd5VKaaGH1gzHnkWMP9VRGzIoJKr2aaTe4ik6dAGGfZRY9bjuEWrLtL fWirzGj9X9nNz0g9CldytcTj/c9ClI7nJcVGXG3IQBJSa0Lh3+yg+dxVmRzPY+WiJ9nO fQkLD4ywwHwcNJQOWyevjdJQ/A567dLVQiV3f8MNm+pb4vYP9FmvH0fgdTespyQHCw6M CRuD6PC/cFUKUJI94vywn4j+YMxK11Jqv5goXD/+Mg0dHEJaSQiQ7CI9VAmBhI/g02H7 U07A==
X-Gm-Message-State: ALoCoQkHIPm0UigQh2xLS3QdwJeZq+VaFrRxvMZ6yPnzZ9lqmVyEqxXXA/OKrtLMU3ZR4WlAYtME
MIME-Version: 1.0
X-Received: by 10.112.105.104 with SMTP id gl8mr47269852lbb.81.1439625169250; Sat, 15 Aug 2015 00:52:49 -0700 (PDT)
Received: by 10.25.144.193 with HTTP; Sat, 15 Aug 2015 00:52:49 -0700 (PDT)
In-Reply-To: <6B7C7317-467A-4809-ABA3-FF599332F18D@osu.edu>
References: <CAPofZaFwCdNKzM42HJMJzLsx+VSVt07Jp+FHA7rV1g7+X7RNNQ@mail.gmail.com> <tsltws4ze6d.fsf@mit.edu> <20150812195437.2e03c0c8@latte.josefsson.org> <20150812183657.GG3654@localhost> <6B7C7317-467A-4809-ABA3-FF599332F18D@osu.edu>
Date: Sat, 15 Aug 2015 08:52:49 +0100
Message-ID: <CAPofZaF80pBKM6_9rtLvnOBzHJZ4boPFjpSPCHv0OLV5QMGjNg@mail.gmail.com>
From: Phil Lello <phil@dunlop-lello.uk>
To: "Cantor, Scott" <cantor.2@osu.edu>
Content-Type: multipart/alternative; boundary=001a11347b18d2cd98051d54da5f
Archived-At: <http://mailarchive.ietf.org/arch/msg/saag/XgpL0qa-tATxjZHFkj1tpZk2QHc>
Cc: Simon Josefsson <simon@josefsson.org>, "kitten@ietf.org" <kitten@ietf.org>, "saag@ietf.org" <saag@ietf.org>, "draft-ietf-kitten-sasl-saml-ec@tools.ietf.org" <draft-ietf-kitten-sasl-saml-ec@tools.ietf.org>, Sam Hartman <hartmans-ietf@mit.edu>
Subject: Re: [saag] [kitten] SSH Protocol Extensions
X-BeenThere: saag@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Security Area Advisory Group <saag.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/saag>, <mailto:saag-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/saag/>
List-Post: <mailto:saag@ietf.org>
List-Help: <mailto:saag-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/saag>, <mailto:saag-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 15 Aug 2015 07:52:54 -0000

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
>