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

Luke Howard <lukeh@padl.com> Mon, 05 September 2016 01:31 UTC

Return-Path: <lukeh@padl.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 A794D12B11D for <kitten@ietfa.amsl.com>; Sun, 4 Sep 2016 18:31:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.41
X-Spam-Level:
X-Spam-Status: No, score=-3.41 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 PGPxA09MeTKY for <kitten@ietfa.amsl.com>; Sun, 4 Sep 2016 18:31:11 -0700 (PDT)
Received: from us.padl.com (us.padl.com [216.154.215.154]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BE00A12B08D for <kitten@ietf.org>; Sun, 4 Sep 2016 18:31:11 -0700 (PDT)
Received: by us.padl.com with ESMTP id u851V7Fd018236; Sun, 4 Sep 2016 21:31:09 -0400
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Luke Howard <lukeh@padl.com>
In-Reply-To: <1473028515.26123.44.camel@redhat.com>
Date: Mon, 05 Sep 2016 11:31:06 +1000
Content-Transfer-Encoding: quoted-printable
Message-Id: <900064F9-C173-49DE-9973-F7CE6A3762EE@padl.com>
References: <1473028515.26123.44.camel@redhat.com>
To: William Brown <wibrown@redhat.com>
X-Mailer: Apple Mail (2.3124)
Archived-At: <https://mailarchive.ietf.org/arch/msg/kitten/bGD3IponLzIJ8-yGO_Cs-U76Ux8>
Cc: "kitten@ietf.org" <kitten@ietf.org>
Subject: Re: [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: Mon, 05 Sep 2016 01:31:14 -0000

Hi William,

It would be worth mentioning in a Security Considerations section that this protocol (like all bearer tokens) is vulnerable to replay attacks.

Cheers,
Luke

> On 5 Sep 2016, at 8:35 AM, William Brown <wibrown@redhat.com> wrote:
> 
> 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
> _______________________________________________
> Kitten mailing list
> Kitten@ietf.org
> https://www.ietf.org/mailman/listinfo/kitten

--
www.lukehoward.com
soundcloud.com/lukehoward