From kaml-bounces@ietf.org Wed Nov 07 19:34:58 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IpvMI-0007Oc-LX; Wed, 07 Nov 2007 19:34:58 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IpvMH-0007OP-NB for kaml@ietf.org; Wed, 07 Nov 2007 19:34:57 -0500 Received: from nmta3.jpl.nasa.gov ([137.78.160.108]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IpvMC-0000sZ-W5 for kaml@ietf.org; Wed, 07 Nov 2007 19:34:57 -0500 Received: from xmta3.jpl.nasa.gov (xmta3.jpl.nasa.gov [137.78.160.111]) by nmta3.jpl.nasa.gov (Switch-3.2.6/Switch-3.2.6) with ESMTP id lA80YoWP017945 for ; Wed, 7 Nov 2007 16:34:50 -0800 Received: from [137.78.61.96] (laphotz.jpl.nasa.gov [137.78.61.96]) by xmta3.jpl.nasa.gov (Switch-3.2.6/Switch-3.2.6) with ESMTP id lA80Ykms022985 for ; Wed, 7 Nov 2007 16:34:49 -0800 Mime-Version: 1.0 (Apple Message framework v752.3) Content-Transfer-Encoding: 7bit Message-Id: <839476E5-F50C-4E2C-872C-EB5D4E465495@jpl.nasa.gov> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: kaml@ietf.org From: "Henry B. Hotz" Date: Wed, 7 Nov 2007 16:34:44 -0800 X-Mailer: Apple Mail (2.752.3) X-Source-IP: laphotz.jpl.nasa.gov [137.78.61.96] X-Source-Sender: hotz@jpl.nasa.gov X-AUTH: Authorized X-Spam-Score: -4.0 (----) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Subject: [KAML] WG Agenda Item? X-BeenThere: kaml@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about SAML and Kerberos intersections List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: kaml-bounces@ietf.org Will there be any discussion of this list's topics at the next IETF meeting? ------------------------------------------------------------------------ The opinions expressed in this message are mine, not those of Caltech, JPL, NASA, or the US Government. Henry.B.Hotz@jpl.nasa.gov, or hbhotz@oxy.edu _______________________________________________ KAML mailing list KAML@ietf.org https://www1.ietf.org/mailman/listinfo/kaml From kaml-bounces@ietf.org Thu Nov 08 03:57:11 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iq3CJ-0001HM-5L; Thu, 08 Nov 2007 03:57:11 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iq3CH-0001HB-SY for kaml@ietf.org; Thu, 08 Nov 2007 03:57:09 -0500 Received: from smtp3.su.se ([130.237.93.228]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Iq3CH-0006Wl-IE for kaml@ietf.org; Thu, 08 Nov 2007 03:57:09 -0500 Received: from localhost (localhost [127.0.0.1]) by smtp3.su.se (Postfix) with ESMTP id 0784C3BF66; Thu, 8 Nov 2007 09:57:08 +0100 (CET) Received: from smtp3.su.se ([127.0.0.1]) by localhost (smtp3.su.se [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 06138-01-74; Thu, 8 Nov 2007 09:57:07 +0100 (CET) Received: from klapautius.it.su.se (dhcp-wavelan-vo-30.publik.su.se [193.11.30.30]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp3.su.se (Postfix) with ESMTP id C50E23BE8A; Thu, 8 Nov 2007 09:57:07 +0100 (CET) Message-ID: <4732CF6D.5000409@it.su.se> Date: Thu, 08 Nov 2007 09:57:17 +0100 From: Leif Johansson User-Agent: Thunderbird 2.0.0.6 (X11/20071022) MIME-Version: 1.0 To: "Henry B. Hotz" Subject: Re: [KAML] WG Agenda Item? References: <839476E5-F50C-4E2C-872C-EB5D4E465495@jpl.nasa.gov> In-Reply-To: <839476E5-F50C-4E2C-872C-EB5D4E465495@jpl.nasa.gov> X-Enigmail-Version: 0.95.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at smtp.su.se X-Spam-Status: No, hits=-2.075 tagged_above=-99 required=7 tests=[AWL=0.237, BAYES_00=-2.312] X-Spam-Level: X-Spam-Score: 0.0 (/) X-Scan-Signature: 8ac499381112328dd60aea5b1ff596ea Cc: kaml@ietf.org X-BeenThere: kaml@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about SAML and Kerberos intersections List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: kaml-bounces@ietf.org Henry B. Hotz wrote: > Will there be any discussion of this list's topics at the next IETF > meeting? > I'll ask jhutz if there is space left _______________________________________________ KAML mailing list KAML@ietf.org https://www1.ietf.org/mailman/listinfo/kaml From kaml-bounces@ietf.org Thu Nov 15 04:40:33 2007 Return-path: 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: 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: From: "Josh Howlett" To: "Tom Scavo" , "Leif Johansson" X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Cc: Josh Howlett , kaml@ietf.org, Paul Rabinovich X-BeenThere: kaml@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about SAML and Kerberos intersections List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: kaml-bounces@ietf.org Tom Scavo wrote: > On 9/25/07, Leif Johansson wrote: > > Paul Rabinovich wrote: > > > > > > IMO it's preferable to keep the LoA piece under the=20 > Kerberos=20 > > > WG rather than under the KAML WG since - in the short-term -=20 > > > out-of-the-box SAML 2.0 seems not to be able to help with LoA.=20 > > > Whatever we design, however, > > > > > I think you are wrong. There are at least two ways to model=20 > LoA using=20 > > SAML - using an AC class or using an attribute. >=20 > That's correct. If you decide to use AuthnContext, that=20 > means the Kerberos-bound SAML assertion would contain an=20 > AuthnStatement. On the other hand, an Attribute would=20 > require an AttributeStatement. > (Personally, I think AuthnContext is the way to go for LoA,=20 > 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--> =09 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=20 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 From kaml-bounces@ietf.org Fri Nov 16 12:10:08 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1It4hj-0001QJ-RV; Fri, 16 Nov 2007 12:10:07 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1It4hi-0001K9-01 for kaml@ietf.org; Fri, 16 Nov 2007 12:10:06 -0500 Received: from fk-out-0910.google.com ([209.85.128.184]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1It4he-0005eZ-Il for kaml@ietf.org; Fri, 16 Nov 2007 12:10:05 -0500 Received: by fk-out-0910.google.com with SMTP id z23so947107fkz for ; Fri, 16 Nov 2007 09:10:01 -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=LO+eM1HNcGnND0dWQvZ+CIG4vP40t2Dx0DIf6Z1NVbU=; b=BpIIkcQoli+TOoJPvanwxK9sSX6fUH0MruVHd6Y/TwCJl+xZXnpkZ7ADkHyi4EHhfp32y0ochU6dseqx2z21G617jr/pzObDnuNuz0KlChRqfwHWnU5BYb8cNLwpooSBuG4OYFxXa0PbiWKDgzdJmbUQCO4qslICDlmc9LAyrTs= 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=lHQhEBLaR9a9oUArxv5ea9nwXeFYrRugdYO75dpUh+cP2Ivr6UMAo63ZdA/V//H7OaIFSXai7ligIGZpJBoBMIncV08FIAkrZFiPlpbDqoJsFmajfTwkfqeUyZP8e1UKdIxGKoBX6YmKy19B0dEX/8KvWzsotEj5jG1Fa22Mvtk= Received: by 10.82.177.3 with SMTP id z3mr5714549bue.1195233000963; Fri, 16 Nov 2007 09:10:00 -0800 (PST) Received: by 10.82.186.15 with HTTP; Fri, 16 Nov 2007 09:10:00 -0800 (PST) Message-ID: Date: Fri, 16 Nov 2007 12:10:00 -0500 From: "Tom Scavo" To: "Josh Howlett" Subject: Re: [KAML] Reminder: BOF proposals to me by October 1 In-Reply-To: <6ED388AA006C454BA35B0098396B9BFB02E4C7D9@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: <6ED388AA006C454BA35B0098396B9BFB02E4C7D9@uxsrvr20.atlas.ukerna.ac.uk> X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: kaml@ietf.org, Paul Rabinovich X-BeenThere: kaml@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about SAML and Kerberos intersections List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: kaml-bounces@ietf.org On Nov 15, 2007 4:40 AM, Josh Howlett wrote: > > Tom Scavo wrote: > > On 9/25/07, Leif Johansson wrote: > > > > > > 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. 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. An attribute is more general (because it works in both SAML V1.1 and V2.0) but SAML V2.0 AuthnContext is preferred (IMO) since it binds LoA to an AuthnStatement, which is conceptually correct. As far as (2) is concerned, you're right, passing additional security information by value is not strictly necessary. However, our own experience integrating SAML into X.509 has clearly shown that pushing SAML tokens by value is far easier to implement and deploy. Moreover, no new wire protocols are required to push X.509-bound SAML tokens. I suspect that the Kerberos use case will exhibit similar advantages. Tom Scavo NCSA _______________________________________________ KAML mailing list KAML@ietf.org https://www1.ietf.org/mailman/listinfo/kaml From kaml-bounces@ietf.org Fri Nov 16 17:55:01 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ItA5V-0004Hw-JA; Fri, 16 Nov 2007 17:55:01 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ItA5U-0004Hn-8z for kaml@ietf.org; Fri, 16 Nov 2007 17:55:00 -0500 Received: from umhost1.ukerna.ac.uk ([193.62.83.67]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ItA5T-0005et-Rv for kaml@ietf.org; Fri, 16 Nov 2007 17:55:00 -0500 Received: from har003676.ukerna.ac.uk ([194.82.140.75]) by umhost1.ukerna.ac.uk with esmtp (Exim 4.50) id 1ItA5M-0004iA-78; Fri, 16 Nov 2007 22:54:52 +0000 Received: from har003676.ukerna.ac.uk (localhost.localdomain [127.0.0.1]) by localhost (Email Security Appliance) with SMTP id 242A04A6B26; Fri, 16 Nov 2007 22:50:34 +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 097944A6B21; Fri, 16 Nov 2007 22:50:28 +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: Fri, 16 Nov 2007 22:54:46 -0000 Message-ID: <6ED388AA006C454BA35B0098396B9BFB02E4CA80@uxsrvr20.atlas.ukerna.ac.uk> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [KAML] Reminder: BOF proposals to me by October 1 Thread-Index: Acgoc8dNc9PoE61ARwW+CghvLi4mvgAK1O9Q References: <6ED388AA006C454BA35B0098396B9BFB02E4C7D9@uxsrvr20.atlas.ukerna.ac.uk> From: "Josh Howlett" To: "Tom Scavo" X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: Josh Howlett , kaml@ietf.org, Paul Rabinovich X-BeenThere: kaml@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about SAML and Kerberos intersections List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: kaml-bounces@ietf.org > > > That's correct. If you decide to use AuthnContext, that=20 > means the=20 > > > Kerberos-bound SAML assertion would contain an=20 > AuthnStatement. On=20 > > > the other hand, an Attribute would require an AttributeStatement. > > > (Personally, I think AuthnContext is the way to go for=20 > LoA, but the=20 > > > jury's still out on that issue.) > > > > I don't think that it's desirable to prescribe either (1) what=20 > > constitutes an appropriate token for LoA or (2) that a=20 > token needs to=20 > > be bound directly to the ticket. The former *should* be a=20 > matter for=20 > > local policy, and the latter is not necessary. >=20 > With regard to (1), I think you're missing the point, Josh.=20=20 > How the LoA is carried in the SAML assertion is a technical=20 > detail, not a matter of policy. My point was that if the 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 believe that what constitutes an appropriate 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.... josh. JANET(UK) is a trading name of The JNT Association, a company limited by guarantee which is registered in England under No. 2881024=20 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 From kaml-bounces@ietf.org Fri Nov 16 19:02:38 2007 Return-path: 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 ; 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: Date: Fri, 16 Nov 2007 19:02:31 -0500 From: "Tom Scavo" To: "Josh Howlett" 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: <6ED388AA006C454BA35B0098396B9BFB02E4C7D9@uxsrvr20.atlas.ukerna.ac.uk> <6ED388AA006C454BA35B0098396B9BFB02E4CA80@uxsrvr20.atlas.ukerna.ac.uk> X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: kaml@ietf.org, Paul Rabinovich X-BeenThere: kaml@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about SAML and Kerberos intersections List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: kaml-bounces@ietf.org On Nov 16, 2007 5:54 PM, Josh Howlett 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 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 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 From kaml-bounces@ietf.org Mon Nov 19 06:23:23 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iu4in-0008AX-FK; Mon, 19 Nov 2007 06:23:21 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iu4il-000890-5c for kaml@ietf.org; Mon, 19 Nov 2007 06:23:19 -0500 Received: from umhost1.ukerna.ac.uk ([193.62.83.67]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iu4ih-0002eW-U9 for kaml@ietf.org; Mon, 19 Nov 2007 06:23:19 -0500 Received: from har003676.ukerna.ac.uk ([194.82.140.75]) by umhost1.ukerna.ac.uk with esmtp (Exim 4.50) id 1Iu4ic-0005NC-61; Mon, 19 Nov 2007 11:23:10 +0000 Received: from har003676.ukerna.ac.uk (localhost.localdomain [127.0.0.1]) by localhost (Email Security Appliance) with SMTP id 58DCC4A6B1A; Mon, 19 Nov 2007 11:18:47 +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 41EA84A6B14; Mon, 19 Nov 2007 11:18:43 +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: Mon, 19 Nov 2007 11:23:11 -0000 Message-ID: <6ED388AA006C454BA35B0098396B9BFB02E4CB6F@uxsrvr20.atlas.ukerna.ac.uk> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [KAML] Reminder: BOF proposals to me by October 1 Thread-Index: AcgorW6JYnCaGO17StmlsGtDXLqEIQB6O8bA References: <6ED388AA006C454BA35B0098396B9BFB02E4C7D9@uxsrvr20.atlas.ukerna.ac.uk><6ED388AA006C454BA35B0098396B9BFB02E4CA80@uxsrvr20.atlas.ukerna.ac.uk> From: "Josh Howlett" To: "Tom Scavo" X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Cc: Josh Howlett , kaml@ietf.org, Paul Rabinovich X-BeenThere: kaml@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about SAML and Kerberos intersections List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: kaml-bounces@ietf.org > On Nov 16, 2007 5:54 PM, Josh Howlett wrote: > > > > > > With regard to (1), I think you're missing the point, Josh. > > > How the LoA is carried in the SAML assertion is a=20 > technical detail,=20 > > > not a matter of policy. > > > > My point was that if the can be acquired post=20 > hoc then the=20 > > Relying Party can decide itself what is the necessary=20 > token(s), rather=20 > > than relying on the TGS to choose what it believes is=20 > appropriate. The=20 > > fire-and-forget approach does not provide room for agility. >=20 > I don't believe it works that way, Josh. An RP that resolves=20 > a token reference receives the same token that would=20 > otherwise be received by value. The act of authentication=20 > has already taken place, so there is very little wiggle room,=20 > in fact. You may as well push the token up front in that case. Aaaah, I now understand how we're getting our wires crossed. I wasn't suggesting binding an artifact to the ticket; instead, I was assuming that the RP is wielding a NameID (bound to the ticket) that can be used, for example, as the of an ; the AuthN context may then be returned within an Authentication Statement. (I think that dereferencing an artifact in this context is possibly difficult for other reasons, but that's another discussion...) FWIW, another reason that 'push' might be problematic is that the Ticket Granting Service may not be aware of the authentication context owing to the fact that the Authentication Service (in the Kerberos context!) that the principal authenticates against may be a separate entity from the TGS; how, therefore, does the TGS learn of the AuthN context from the AS? You could signal this in the TGT perhaps, but this is adding complexity. Further, if we assume that the Authentication Service is issuing the Authentication Assertion (with the LoA) then some other possible issues resolve themselves; for example, we know that we can set the value of the NotOnOrAfter attribute to the expiry of the principal's Kerberos TGT. josh. JANET(UK) is a trading name of The JNT Association, a company limited by guarantee which is registered in England under No. 2881024=20 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 From kaml-bounces@ietf.org Thu Nov 22 11:29:08 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IvEvK-0004q2-6x; Thu, 22 Nov 2007 11:29:06 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IvEvI-0004pK-UD for kaml@ietf.org; Thu, 22 Nov 2007 11:29:04 -0500 Received: from nf-out-0910.google.com ([64.233.182.184]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IvEvF-00066L-Ku for kaml@ietf.org; Thu, 22 Nov 2007 11:29:04 -0500 Received: by nf-out-0910.google.com with SMTP id d21so2282225nfb for ; Thu, 22 Nov 2007 08:29:00 -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=ml/dmAiyEiftpxiQOIN2bhTj0YH/ErbY73Xb+JwHx5I=; b=HkYEy40n9Kxg1NR35DWRMHyqoizcPesDRvdIIZxBolcqXhZNSF+YpYD+nC90qJuZar/huLQE7X31mtcYd5R6j5NL4c00o/xJ4DqISGLyugy3/GVQPEfyPP4x8jF4K8yfGkpyVZA9kS3CyH+rGBXZgjsjwjMKg0aiReLKtpilEvM= 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=Rz6LYG60fCCq4TwzvI+MOrqUkT3KJMb9uUfGkSdorTNcMhXVfmUnG2YEVZ0CrklMc+vbH9pwlnS+d8KUVh9AJtdI+lgeUBR4bp62IIg2xQsMyx9TGgrF8VkaNPVmvqtAwMr1btsPD8k8kNJ4MchZCeuEnodfzkRIDibdZwrYGZI= Received: by 10.82.149.8 with SMTP id w8mr1832669bud.1195748939968; Thu, 22 Nov 2007 08:28:59 -0800 (PST) Received: by 10.82.186.1 with HTTP; Thu, 22 Nov 2007 08:28:59 -0800 (PST) Message-ID: Date: Thu, 22 Nov 2007 11:28:59 -0500 From: "Tom Scavo" To: "Josh Howlett" Subject: Re: [KAML] Reminder: BOF proposals to me by October 1 In-Reply-To: <6ED388AA006C454BA35B0098396B9BFB02E4CB6F@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: <6ED388AA006C454BA35B0098396B9BFB02E4C7D9@uxsrvr20.atlas.ukerna.ac.uk> <6ED388AA006C454BA35B0098396B9BFB02E4CA80@uxsrvr20.atlas.ukerna.ac.uk> <6ED388AA006C454BA35B0098396B9BFB02E4CB6F@uxsrvr20.atlas.ukerna.ac.uk> X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Cc: kaml@ietf.org, Paul Rabinovich X-BeenThere: kaml@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about SAML and Kerberos intersections List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: kaml-bounces@ietf.org On 11/19/07, Josh Howlett wrote: > > I was > assuming that the RP is wielding a NameID (bound to the ticket) that can > be used, for example, as the of an ; the AuthN > context may then be returned within an Authentication Statement. This introduces significant new infrastructure and protocol requirements. The most widely deployed SAML implementation (Shibboleth) does not implement the AuthnQuery protocol, so there isn't a single IdP today that could satisfy such a request. More importantly, an AuthnQuery is a query for an assertion describing a previous act of authentication, so now the IdP has to maintain state where none existed before. For production, stateless IdPs, this is most likely a showstopper. You say there is a NameID bound to the ticket. How does the TGS obtain or produce a NameID that the IdP can map to the correct local principal? (Note that the IdP needs a plugin that can perform this mapping, yet another infrastructure requirement.) What is the Format of the NameID? Is it a SAML V2.0 kerberos identifier? If so, this rules out SAML V1.1, which constitutes the bulk of today's SAML deployments. > FWIW, another reason that 'push' might be problematic is that the Ticket > Granting Service may not be aware of the authentication context owing to > the fact that the Authentication Service (in the Kerberos context!) that > the principal authenticates against may be a separate entity from the > TGS; how, therefore, does the TGS learn of the AuthN context from the > AS? In fact, this is exactly how a Shibboleth IdP works today. An external service authenticates the user and passes the principal name to the IdP. From this, the IdP formulates the SAML authn context on its own. In general, the LoA associated with an identity token is a function of the strength of the identity credential used to obtain the token, the token type, the authentication method, and the protocol used to transmit the token to the relying party. Only the authentication method depends on the authentication service, and even this can be inferred by the IdP. > Further, if we assume that the Authentication Service is issuing the > Authentication Assertion (with the LoA) then some other possible issues > resolve themselves; for example, we know that we can set the value of > the NotOnOrAfter attribute to the expiry of the principal's Kerberos > TGT. Actually, if you embed the SAML directly in the ticket, you don't even need to include a NotOnOrAfter attribute since it can be inferred from the containing ticket. There are other similar such benefits of a kerberos-bound SAML token. The SAML assertion need not have all the nitpicking features required by a SAML protocol since the SAML is subordinate to the kerberos, in a sense. No new protocols or extensive infrastructure are required. Tom _______________________________________________ KAML mailing list KAML@ietf.org https://www1.ietf.org/mailman/listinfo/kaml From kaml-bounces@ietf.org Fri Nov 23 09:49:16 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IvZqG-0007qN-9c; Fri, 23 Nov 2007 09:49:16 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IvZqE-0007kA-Qr for kaml@ietf.org; Fri, 23 Nov 2007 09:49:14 -0500 Received: from umhost1.ukerna.ac.uk ([193.62.83.67]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IvZqA-0002QW-SD for kaml@ietf.org; Fri, 23 Nov 2007 09:49:14 -0500 Received: from har003676.ukerna.ac.uk ([194.82.140.75]) by umhost1.ukerna.ac.uk with esmtp (Exim 4.50) id 1IvZq4-0002bT-Kj; Fri, 23 Nov 2007 14:49:04 +0000 Received: from har003676.ukerna.ac.uk (localhost.localdomain [127.0.0.1]) by localhost (Email Security Appliance) with SMTP id 39A984A6B2D; Fri, 23 Nov 2007 14:44:46 +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 0373A4A6B0A; Fri, 23 Nov 2007 14:44:42 +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: Fri, 23 Nov 2007 14:48:45 -0000 Message-ID: <6ED388AA006C454BA35B0098396B9BFB02ED7B7B@uxsrvr20.atlas.ukerna.ac.uk> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [KAML] Reminder: BOF proposals to me by October 1 Thread-Index: AcgtJYaR+5LwCV4zS/SUcd+xvpu7XwAK4tvg References: <6ED388AA006C454BA35B0098396B9BFB02E4C7D9@uxsrvr20.atlas.ukerna.ac.uk> <6ED388AA006C454BA35B0098396B9BFB02E4CA80@uxsrvr20.atlas.ukerna.ac.uk> <6ED388AA006C454BA35B0098396B9BFB02E4CB6F@uxsrvr20.atlas.ukerna.ac.uk> From: "Josh Howlett" To: "Tom Scavo" X-Spam-Score: 0.0 (/) X-Scan-Signature: 22bbb45ef41b733eb2d03ee71ece8243 Cc: Josh Howlett , kaml@ietf.org, Paul Rabinovich X-BeenThere: kaml@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about SAML and Kerberos intersections List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: kaml-bounces@ietf.org Tom Scavo wrote: > On 11/19/07, Josh Howlett wrote: > > > > I was > > assuming that the RP is wielding a NameID (bound to the=20 > ticket) that=20 > > can be used, for example, as the of an ; the=20 > > AuthN context may then be returned within an Authentication=20 > Statement. >=20 > This introduces significant new infrastructure and protocol=20 > requirements. The most widely deployed SAML implementation > (Shibboleth) does not implement the AuthnQuery protocol, so=20 > there isn't a single IdP today that could satisfy such a=20 > request. More importantly, an AuthnQuery is a query for an=20 > assertion describing a previous act of authentication, so now=20 > the IdP has to maintain state where none existed before. For=20 > production, stateless IdPs, this is most likely a showstopper. If we have to work under the constraint that we can't implement an existing protocol specification or any new infrastructure then I don't think we're going to get a solution! Something, somewere, has to change. I'll attempt to summarise the preceeding discussion: * LoA could be expressed either in terms of an AuthN or an Attribute assertion; * the assertion value could be pushed or pulled, but that there isn't any value in dereferencing an artifact; * PUSH=20 + the advantages of pushing include: - no state maintenance + the disadvantages of pushing include: - significant wire protocol alterations to Kerberos - constrains Relying Parties to use that assertion for the lifetime of the TGT or until renewal, effectively requiring that all Relying Parties have a common understanding and requirement of the LoA, reducing policy agility. - trust management: you probably need a proof-of-binding to avoid substitution attacks + implementation considerations: - KDC must be able to generate SAML AuthN assertion and bind to TGT, and TGS must be able to bind to service tickets. * PULL=20 + the advantages of pulling include: - provides Relying Parties with a greater choice of tokens to use for LoA, allowing richer local policy - less significant wire protocol alterations to Kerberos - trust management is probably unchanged from conventional SAML considerations + the disadvantages of pulling include: - maintenance of state + implementation considerations - the KDC needs to maintain state, and this must be exposed to the Authentication Authority. In response to your other points: > You say there is a NameID bound to the ticket. How does the=20 > TGS obtain or produce a NameID that the IdP can map to the=20 > correct local principal? It's already in the TGT minted by the KDC. > (Note that the IdP needs a plugin=20 > that can perform this mapping, yet another infrastructure=20 > requirement.) What is the Format of the NameID? Is it a=20 > SAML V2.0 kerberos identifier? If so, this rules out SAML=20 > V1.1, which constitutes the bulk of today's SAML deployments. The format just needs to be something that both the KDC and IdP both understand. Do we need to be prescriptive about this? > > FWIW, another reason that 'push' might be problematic is that the=20 > > Ticket Granting Service may not be aware of the=20 > authentication context=20 > > owing to the fact that the Authentication Service (in the Kerberos=20 > > context!) that the principal authenticates against may be a=20 > separate=20 > > entity from the TGS; how, therefore, does the TGS learn of=20 > the AuthN=20 > > context from the AS? >=20 > In fact, this is exactly how a Shibboleth IdP works today.=20=20 No, there's a big difference: an Attribute Authority or Authentication Authority can *only* make assertions about principals affiliated with the same IdP (and so the authN context is implicit); a TGS can issue tickets to principals affiliated with another KDC and about whom it knows nothing (including how they were authenticated). This is why if you're going to push the assertion (1) it needs to be bound to the TGT, (2) the TGS needs to understand this new protocol and (3) live with the restrictions that I summarised above. > > Further, if we assume that the Authentication Service is=20 > issuing the=20 > > Authentication Assertion (with the LoA) then some other possible=20 > > issues resolve themselves; for example, we know that we can set the=20 > > value of the NotOnOrAfter attribute to the expiry of the=20 > principal's=20 > > Kerberos TGT. >=20 > Actually, if you embed the SAML directly in the ticket, you=20 > don't even need to include a NotOnOrAfter attribute since it=20 > can be inferred from the containing ticket. There are other=20 > similar such benefits of a kerberos-bound SAML token. The=20 > SAML assertion need not have all the nitpicking features=20 > required by a SAML protocol since the SAML is subordinate to=20 > the kerberos, in a sense. I guess that depends how much you trust the Kerberos infrastructure. > No new protocols or extensive=20 > infrastructure are required. ...to the IdP, but the KDC & TGS needs to learn a few new tricks :-) Given your experience with SAML/X509, it would be interesting to know the reasons why 'push' turned out to be better than 'pull' in that context. josh. JANET(UK) is a trading name of The JNT Association, a company limited by guarantee which is registered in England under No. 2881024=20 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