Re: review of draft-wierenga-ietf-sasl-saml-00

Simon Josefsson <simon@josefsson.org> Wed, 26 May 2010 19:59 UTC

Return-Path: <simon@josefsson.org>
X-Original-To: kitten@core3.amsl.com
Delivered-To: kitten@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A72DF3A693D for <kitten@core3.amsl.com>; Wed, 26 May 2010 12:59:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.001
X-Spam-Level:
X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QxqK+WZ3rF5u for <kitten@core3.amsl.com>; Wed, 26 May 2010 12:59:10 -0700 (PDT)
Received: from yxa-v.extundo.com (yxa-v.extundo.com [83.241.177.39]) by core3.amsl.com (Postfix) with ESMTP id 679E63A66B4 for <kitten@ietf.org>; Wed, 26 May 2010 12:59:08 -0700 (PDT)
Received: from mocca (c80-216-25-148.bredband.comhem.se [80.216.25.148]) (authenticated bits=0) by yxa-v.extundo.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id o4QJwoBM011259 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 26 May 2010 21:58:52 +0200
From: Simon Josefsson <simon@josefsson.org>
To: Scott Cantor <cantor.2@osu.edu>
Subject: Re: review of draft-wierenga-ietf-sasl-saml-00
References: <tslzkzn67n5.fsf@mit.edu> <077001cafc4b$603f0510$20bd0f30$@osu.edu> <4BFD2ECE.5020600@cisco.com> <07e801cafce5$4cf7f7b0$e6e7e710$@osu.edu> <tslvdaa4izt.fsf@mit.edu> <082501cafd03$0fe0f250$2fa2d6f0$@osu.edu>
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
X-Hashcash: 1:22:100526:cantor.2@osu.edu::4mUl+BzOxCUosyrh:0Wov
X-Hashcash: 1:22:100526:hartmans-ietf@mit.edu::OmIuQrExQxZoj74s:4f07
X-Hashcash: 1:22:100526:draft-wierenga-ietf-sasl-saml@tools.ietf.org::ewt5bE+/ouv1u4Qd:8D8m
X-Hashcash: 1:22:100526:kitten@ietf.org::N7SHP1pEIYT/OKiZ:UOsD
X-Hashcash: 1:22:100526:moonshot-community@jiscmail.ac.uk::91rBAwA1NaEJ4Nw1:j8N3
Date: Wed, 26 May 2010 21:58:50 +0200
In-Reply-To: <082501cafd03$0fe0f250$2fa2d6f0$@osu.edu> (Scott Cantor's message of "Wed, 26 May 2010 14:41:32 -0400")
Message-ID: <87fx1eo2o5.fsf@mocca.josefsson.org>
User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.1 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Virus-Scanned: clamav-milter 0.96 at yxa-v
X-Virus-Status: Clean
Cc: kitten@ietf.org, moonshot-community@jiscmail.ac.uk, 'Sam Hartman' <hartmans-ietf@mit.edu>, draft-wierenga-ietf-sasl-saml@tools.ietf.org
X-BeenThere: kitten@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Common Authentication Technologies - Next Generation <kitten.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/kitten>, <mailto:kitten-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/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: Wed, 26 May 2010 19:59:11 -0000

"Scott Cantor" <cantor.2@osu.edu> writes:

>> Scott, I'm happy to work with you to figure out if channel binding
>> support is possible in your approach.
>
> I plan to take you up on it. To ease the process of comparing the
> approaches, I think it's easiest to produce a simple draft initially, which
> highlights some of the issues you mentioned, but leaves things as is for the
> same compatibility reasons that Klaas had. The result may be a merging of
> the proposals, or not.
>
> Related to this, for example, I'm in favor of supporting a way to tie the
> SAML assertion in the response to a key at the TLS layer (holder of key via
> client TLS, in other words). That's an addition to the SAML profile I'm
> basing this work on, which is why I'm not starting there, to simplify the
> compatibility story. I probably will go back to OASIS to get a HoK version
> of the ECP profile created, and then I can just reference it.

I would prefer if channel bindings is done in a GS2 compatible way, to
allow a SAML SASL mechanism to be usable as a GSS-API mechanism as well.
By using the GS2 prefix, you also get support for authorization
identities.

If authors are interested here, I could help with the GS2 prefix part so
that it causes minimal confusion for non-GSS-API people and still allows
that variant.  I made this suggestion for the OpenID SASL mechanism as
well.

/Simon