Re: [KAML] Reminder: BOF proposals to me by October 1

"Tom Scavo" <trscavo@gmail.com> Sat, 17 November 2007 00:02 UTC

Return-path: <kaml-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ItB8w-0004mC-FM; Fri, 16 Nov 2007 19:02:38 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ItB8u-0004jb-FP for kaml@ietf.org; Fri, 16 Nov 2007 19:02:36 -0500
Received: from hu-out-0506.google.com ([72.14.214.226]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ItB8q-0007dP-TI for kaml@ietf.org; Fri, 16 Nov 2007 19:02:36 -0500
Received: by hu-out-0506.google.com with SMTP id 31so378982huc for <kaml@ietf.org>; Fri, 16 Nov 2007 16:02:31 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=1Iy9LBVfNmnexaXQw+E7mbbz5UfvJI0A1xONLtnBdmQ=; b=Ja3EmF9buHdem8boVKVVSgB8BaT0msMAlM3CF9ljApOz3KkbYLA2IJFNyPVP1iT2YPmZzlQEI89RZyd/Bm3CnLXK+Lq0DtSFx5xTKqyD7MVztJGUZ7PAB12Px1MGEURQTQC1tK/VQPL8K6C7KlflHs/Xl4ko7ezTnRmAh7aR/TU=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=qEj07yjjd4aJl6UioUWELueOiLj7/NBIeSIvqB6WxM68dTVnlAMq66q8y9GxK47Zhbh47GxbhlxBTlxFyC5Sly9uqkRKXEMd90euaQW/XpLeB19CHa9tDpHdNz7Or6vFiE3Ie1fxzDRBQUTqeeWRuxZPdo9fkmHZGwB3/oAFapQ=
Received: by 10.82.189.6 with SMTP id m6mr6281805buf.1195257751782; Fri, 16 Nov 2007 16:02:31 -0800 (PST)
Received: by 10.82.186.15 with HTTP; Fri, 16 Nov 2007 16:02:31 -0800 (PST)
Message-ID: <ea2af9bd0711161602h395cd3cbsda2dcbc3173b0ab1@mail.gmail.com>
Date: Fri, 16 Nov 2007 19:02:31 -0500
From: Tom Scavo <trscavo@gmail.com>
To: Josh Howlett <Josh.Howlett@ja.net>
Subject: Re: [KAML] Reminder: BOF proposals to me by October 1
In-Reply-To: <6ED388AA006C454BA35B0098396B9BFB02E4CA80@uxsrvr20.atlas.ukerna.ac.uk>
MIME-Version: 1.0
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <ea2af9bd0709251452y114ee29bs91fcfb6f490e6ffc@mail.gmail.com> <6ED388AA006C454BA35B0098396B9BFB02E4C7D9@uxsrvr20.atlas.ukerna.ac.uk> <ea2af9bd0711160910u70ebb515m35de79fdad8ff606@mail.gmail.com> <6ED388AA006C454BA35B0098396B9BFB02E4CA80@uxsrvr20.atlas.ukerna.ac.uk>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 52e1467c2184c31006318542db5614d5
Cc: kaml@ietf.org, Paul Rabinovich <Paul.Rabinovich@exostar.com>
X-BeenThere: kaml@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Discussions about SAML and Kerberos intersections <kaml.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/kaml>, <mailto:kaml-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/kaml>
List-Post: <mailto:kaml@ietf.org>
List-Help: <mailto:kaml-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/kaml>, <mailto:kaml-request@ietf.org?subject=subscribe>
Errors-To: kaml-bounces@ietf.org

On Nov 16, 2007 5:54 PM, Josh Howlett <Josh.Howlett@ja.net> wrote:
> >
> > With regard to (1), I think you're missing the point, Josh.
> > How the LoA is carried in the SAML assertion is a technical
> > detail, not a matter of policy.
>
> My point was that if the <LoA token> can be acquired post hoc then the
> Relying Party can decide itself what is the necessary token(s), rather
> than relying on the TGS to choose what it believes is appropriate. The
> fire-and-forget approach does not provide room for agility.

I don't believe it works that way, Josh.  An RP that resolves a token
reference receives the same token that would otherwise be received by
value.  The act of authentication has already taken place, so there is
very little wiggle room, in fact.  You may as well push the token up
front in that case.

> I believe that what constitutes an appropriate <LoA token> depends on
> what the Relying Party in question feels is necessary to satisfy their
> policy, and so binding these semantics arbitrarily to the transport
> protocol seems unnecessarily restrictive. Let them choose! AuthN
> context, attribute or moon phase....

I think you're mixing two separate issues:

1. How to bind an LoA token to a SAML assertion.
2. How to transmit a SAML assertion to an RP.

I don't really care how (1) plays out, and it isn't really relevant
here anyway, but I have strong opinions about (2).  It's clear to me
(YMMV of course) that pushing the security information by value is
preferred.  I've learned this after almost three years of effort
trying to integrate SAML and X.509.

Tom Scavo
NCSA

_______________________________________________
KAML mailing list
KAML@ietf.org
https://www1.ietf.org/mailman/listinfo/kaml