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

"Josh Howlett" <Josh.Howlett@ja.net> Thu, 15 November 2007 09:40 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 1IsbD6-0006KU-Ur; Thu, 15 Nov 2007 04:40:32 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsbD4-0006GX-2c for kaml@ietf.org; Thu, 15 Nov 2007 04:40:30 -0500
Received: from umhost1.ukerna.ac.uk ([193.62.83.67]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IsbD1-0004Dm-Fo for kaml@ietf.org; Thu, 15 Nov 2007 04:40:30 -0500
Received: from har003676.ukerna.ac.uk ([194.82.140.75]) by umhost1.ukerna.ac.uk with esmtp (Exim 4.50) id 1IsbCz-0003Tz-EO; Thu, 15 Nov 2007 09:40:25 +0000
Received: from har003676.ukerna.ac.uk (localhost.localdomain [127.0.0.1]) by localhost (Email Security Appliance) with SMTP id 6296F4A6B2C; Thu, 15 Nov 2007 09:36:10 +0000 (GMT)
Received: from uxsrvr20.atlas.ukerna.ac.uk (uxsrvr20.ukerna.ac.uk [193.62.83.209]) by har003676.ukerna.ac.uk (Email Security Appliance) with ESMTP id 48EA04A6B0A; Thu, 15 Nov 2007 09:36:04 +0000 (GMT)
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [KAML] Reminder: BOF proposals to me by October 1
Date: Thu, 15 Nov 2007 09:40:21 -0000
Message-ID: <6ED388AA006C454BA35B0098396B9BFB02E4C7D9@uxsrvr20.atlas.ukerna.ac.uk>
In-Reply-To: <ea2af9bd0709251452y114ee29bs91fcfb6f490e6ffc@mail.gmail.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [KAML] Reminder: BOF proposals to me by October 1
Thread-Index: Acf/vrcgFSnr7CavRn+kS8mAlZge4gnqKH8g
References: <ea2af9bd0709251452y114ee29bs91fcfb6f490e6ffc@mail.gmail.com>
From: Josh Howlett <Josh.Howlett@ja.net>
To: Tom Scavo <trscavo@gmail.com>, Leif Johansson <leifj@it.su.se>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8
Cc: Josh Howlett <Josh.Howlett@ja.net>, 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

Tom Scavo wrote:
> On 9/25/07, Leif Johansson <leifj@it.su.se> wrote:
> > Paul Rabinovich wrote:
> > >
> > >       IMO it's preferable to keep the LoA piece under the 
> Kerberos 
> > > WG rather than under the KAML WG since - in the short-term - 
> > > out-of-the-box SAML 2.0 seems not to be able to help with LoA. 
> > > Whatever we design, however,
> > >
> > I think you are wrong. There are at least two ways to model 
> LoA using 
> > SAML - using an AC class or using an attribute.
> 
> That's correct.  If you decide to use AuthnContext, that 
> means the Kerberos-bound SAML assertion would contain an 
> AuthnStatement.  On the other hand, an Attribute would 
> require an AttributeStatement.
> (Personally, I think AuthnContext is the way to go for LoA, 
> but the jury's still out on that issue.)

I don't think that it's desirable to prescribe either (1) what
constitutes an appropriate token for LoA or (2) that a token needs to be
bound directly to the ticket. The former *should* be a matter for local
policy, and the latter is not necessary.

Just provide a mechanism for the Relying Party to resolve the
Authentication and Attribute Authorities associated with the principal
wielding the ticket and the Relying Party can make a call-back to one or
the other, or both, depending on what its own local authorisation policy
considers an appropriate LoA token, and make the necessary Assertion
Request(s) itself.

An example mechanism that might support this: treat the principal name
as a NameID (which SAML already allows) and the Relying Party can use
SAMLMeta DNS Publication and Resolution (Sec 4.2) with the NID2U
servicefield in a NAPTR record to specify the AuthN and/or Attr
Authorities associated with it (see Sec 4.2.2.2 for an analagous
example).

	Client		TGS		Service		DNS
SAML AA (AuthN and/or Attr)

		----TKT?---->
		<---TKT------
	      -----------TKT--------->
						Validate TKT
							--Look up-->
	
NAPTR record
							<--SAML AA--
							--------SAML
Assrt Req--->
							<-------SAML
Assrt Res----
						AuthZ decision
		<-------Ok--------------
josh.

JANET(UK) is a trading name of The JNT Association, a company limited
by guarantee which is registered in England under No. 2881024 
and whose Registered Office is at Lumen House, Library Avenue,
Harwell Science and Innovation Campus, Didcot, Oxfordshire. OX11 0SG


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