[kitten] Request for feedback: draft-wibrown-ldapssotoken

William Brown <wibrown@redhat.com> Sun, 04 September 2016 22:42 UTC

Return-Path: <wibrown@redhat.com>
X-Original-To: kitten@ietfa.amsl.com
Delivered-To: kitten@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCDFC12B0E1 for <kitten@ietfa.amsl.com>; Sun, 4 Sep 2016 15:42:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.41
X-Spam-Level:
X-Spam-Status: No, score=-8.41 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.508, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 Fn4tFJcIfS_m for <kitten@ietfa.amsl.com>; Sun, 4 Sep 2016 15:42:14 -0700 (PDT)
Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 90C5E12B0E0 for <kitten@ietf.org>; Sun, 4 Sep 2016 15:42:14 -0700 (PDT)
Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id B5C8683F3A for <kitten@ietf.org>; Sun, 4 Sep 2016 22:35:18 +0000 (UTC)
Received: from rei.prd.blackhats.net.au (ovpn-116-25.phx2.redhat.com [10.3.116.25]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u84MZG7o017336 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for <kitten@ietf.org>; Sun, 4 Sep 2016 18:35:18 -0400
Message-ID: <1473028515.26123.44.camel@redhat.com>
From: William Brown <wibrown@redhat.com>
To: kitten@ietf.org
Date: Mon, 05 Sep 2016 08:35:15 +1000
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-KyX8ILQzbn3++N1IxQfb"
Mime-Version: 1.0
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.24
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.27]); Sun, 04 Sep 2016 22:35:18 +0000 (UTC)
Archived-At: <https://mailarchive.ietf.org/arch/msg/kitten/CZX07GXf4HyEi1NFmjnjYB5DiAA>
Subject: [kitten] Request for feedback: draft-wibrown-ldapssotoken
X-BeenThere: kitten@ietf.org
X-Mailman-Version: 2.1.17
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: Sun, 04 Sep 2016 22:42:16 -0000

Hi,

I would like to ask for feedback on the submission
draft-wibrown-ldapssotoken [0]. Section 4 deals with the SASL component
of the submission. I have been advised by Alexey Melnikov that this
seems similar to rfc7628 [1] and rfc6595 [2]. The main difference that I
see is that these rfcs rely on the external OAuth and SAML provider for
tokens. As well, they have GSSAPI integrations. The implementation I am
suggesting here is for a much simpler cryptographically based token,
that is for "small deployments" IE where no other SSO such as KRB5, SAML
or others are available. It's much more targeted around the
communication and authentication to a Directory Server: but there is no
reason it couldn't be use for simple crypto token sign on in other
applications. 

Thanks for your time and advice,

[0] https://datatracker.ietf.org/doc/draft-wibrown-ldapssotoken/
[1] https://tools.ietf.org/html/rfc7628
[2] https://tools.ietf.org/html/rfc6595

-- 
Sincerely,

William Brown
Software Engineer
Red Hat, Brisbane