IETF Logo Mail Archive

Re: [kitten] [saag] 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: kitten@ietfa.amsl.com
Delivered-To: kitten@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B6211ACDAA for <kitten@ietfa.amsl.com>; Sat, 15 Aug 2015 00:52:54 -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=unavailable
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 8f7glL-ImP4n for <kitten@ietfa.amsl.com>; Sat, 15 Aug 2015 00:52:51 -0700 (PDT)
Received: from mail-lb0-f179.google.com (mail-lb0-f179.google.com [209.85.217.179]) (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 DBAC61ACDA5 for <kitten@ietf.org>; Sat, 15 Aug 2015 00:52:50 -0700 (PDT)
Received: by lbbsx3 with SMTP id sx3so56857738lbb.0 for <kitten@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=KPK56CpKInsKzBQiC0us5jSZC79jUedoM+I80DuuvopQcuFrQi7fUayaqB93X6ys7F CfhmzbR7OtsYrKU9JNuc4T4uo/IsKOEcanrOwXPVuTYEAKum4Y/tG61BnD0Mzz2dBCK8 Fl+E8sccyDc6ANMsudkjoyuRqo8XNksZBVDjmgCLUe5t/C7kDZDVD9HbTNEydQ4Lpba2 86KaQ2vBImj+0T23ZCLjjhFFEXzuN8+wHnaFlRr4rQv5JjoNju+UG4uxZCCETujC8luZ hEy5ki+FPsS7SjtORTv1hWottH0YrIVwMDxYBtPUfqUfWtR/NRF1SUgfYbTFbxY9vC+S gKfg==
X-Gm-Message-State: ALoCoQlu1eP0b3MD4degwjFUS3SeJB6tFtmhuqN6Gommu241q49Zr561iyYnuiTuDmirTyidGu+D
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/kitten/6AaptKdQ_IHgLXiNgbRGIewUxEI>
X-Mailman-Approved-At: Sat, 15 Aug 2015 13:29:35 -0700
Cc: "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: [kitten] [saag] SSH Protocol Extensions
X-BeenThere: kitten@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Common Authentication Technologies - Next Generation <kitten.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/kitten>, <mailto:kitten-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/kitten/>
List-Post: <mailto:kitten@ietf.org>
List-Help: <mailto:kitten-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/kitten>, <mailto:kitten-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
>

v2.23.0 | Report a Bug | By Email