From leifj@mnt.se Mon Sep 5 00:59:27 2011 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA64821F8B11 for ; Mon, 5 Sep 2011 00:59:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bObTKeY5tpVD for ; Mon, 5 Sep 2011 00:59:26 -0700 (PDT) Received: from backup-server.nordu.net (backup-server.nordu.net [IPv6:2001:948:4:1::66]) by ietfa.amsl.com (Postfix) with ESMTP id 931C121F8B06 for ; Mon, 5 Sep 2011 00:59:26 -0700 (PDT) Received: from [109.105.104.187] (dhcp53.se-tug.nordu.net [109.105.104.187] (may be forged)) (authenticated bits=0) by backup-server.nordu.net (8.14.3/8.14.3) with ESMTP id p85812RM024566 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 5 Sep 2011 10:01:07 +0200 (CEST) Message-ID: <4E6481BE.3060706@mnt.se> Date: Mon, 05 Sep 2011 10:01:02 +0200 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.21) Gecko/20110831 Lightning/1.0b2 Thunderbird/3.1.13 MIME-Version: 1.0 To: "abfab@ietf.org" X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [abfab] progress X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Sep 2011 07:59:27 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Klaas and me are holding off on requesting a session in Taipei until the very last minute. Progress on this list since Quebec has been too slow even for an IETF wg. We urgently need reviewers. Some of you who volunteered in Quebec will get pinged in the next few hours but others should pitch in aswell. Cheers Leif & Klaas -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk5kgb4ACgkQ8Jx8FtbMZnd+iACeJ+Hkx20CKTskEFj/h8XDnfw6 BrcAoJDvFgzlqa2qtswA5qEAA7NOWQGk =pP6u -----END PGP SIGNATURE----- From Josh.Howlett@ja.net Mon Sep 5 02:21:26 2011 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1150821F84CC for ; Mon, 5 Sep 2011 02:21:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.639 X-Spam-Level: X-Spam-Status: No, score=-102.639 tagged_above=-999 required=5 tests=[AWL=-0.340, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VfGeIX5SGSJ4 for ; Mon, 5 Sep 2011 02:21:25 -0700 (PDT) Received: from egw001.ukerna.ac.uk (egw001.ukerna.ac.uk [194.82.140.74]) by ietfa.amsl.com (Postfix) with ESMTP id C28C321F8A7B for ; Mon, 5 Sep 2011 02:21:24 -0700 (PDT) Received: from egw001.ukerna.ac.uk (localhost.localdomain [127.0.0.1]) by localhost (Email Security Appliance) with SMTP id 2EBC61A9C071_E6494F8B; Mon, 5 Sep 2011 09:23:04 +0000 (GMT) Received: from EXC001.atlas.ukerna.ac.uk (exc001.atlas.ukerna.ac.uk [193.62.83.37]) by egw001.ukerna.ac.uk (Sophos Email Appliance) with ESMTP id F19B81A9C065_E6494F7F; Mon, 5 Sep 2011 09:23:03 +0000 (GMT) Received: from EXC001.atlas.ukerna.ac.uk ([193.62.83.37]) by EXC001 ([193.62.83.37]) with mapi id 14.01.0289.001; Mon, 5 Sep 2011 10:23:03 +0100 From: Josh Howlett To: Sam Hartman , =?iso-8859-1?Q?Gabriel_L=F3pez?= Thread-Topic: [abfab] EAP naming attribute document Thread-Index: AQHMZy4rIwJZaalSSb2aLjriD3LynZU+jHSA Date: Mon, 5 Sep 2011 09:23:02 +0000 Message-ID: In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.12.0.110505 x-originating-ip: [194.82.140.76] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <785C2FF3FCAAC74F8B5861A3013F3841@ukerna.ac.uk> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "abfab@ietf.org" Subject: Re: [abfab] EAP naming attribute document X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Sep 2011 09:21:26 -0000 > Gabriel> Hi, > > Gabriel> What I think is missing in the documents is the SAML > Gabriel> profile for abfab. The architecture document says that > Gabriel> SAML requests may or not may appear as RADIUS attributes in > Gabriel> the request, but it is quite ambiguos. The home AAA server > Gabriel> has to know if a SAML attribute, authentication or > Gabriel> authorization statement should be returned, and it has to > Gabriel> be specified in the RADIUS request. I mean, there should > Gabriel> be in some place, a description of the SAML queries to be > Gabriel> used, statement to be returned and, for example, if they > Gabriel> has to be signed or encrypted. It could also imply a > Gabriel> problem if the assertion is too big to be transported over > Gabriel> the radius message (even if fragmentation occurs). > >I agree some of this needs to be specified. In particular, enough needs >to be specified that the RP knows what it can rely on. +1 >I think that draft-ietf-abfab-aaa-saml is probably the right place for >that. I'll update the draft. 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 Oxford, Didcot, Oxfordshire. OX11 0SG From hartmans@painless-security.com Tue Sep 6 06:51:06 2011 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E37A021F84AD for ; Tue, 6 Sep 2011 06:51:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.647 X-Spam-Level: X-Spam-Status: No, score=-0.647 tagged_above=-999 required=5 tests=[AWL=-1.582, BAYES_50=0.001, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_42=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W75ff-1UCXPq for ; Tue, 6 Sep 2011 06:51:06 -0700 (PDT) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id 7855221F84AC for ; Tue, 6 Sep 2011 06:51:05 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id 5098F20384 for ; Tue, 6 Sep 2011 09:54:51 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 58E4D42B7; Tue, 6 Sep 2011 09:52:41 -0400 (EDT) From: Sam Hartman To: abfab@ietf.org Date: Tue, 06 Sep 2011 09:52:41 -0400 Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [abfab] GSS-Preauth and decoupling for GSS-EAP X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Sep 2011 13:51:07 -0000 Hi. At the mic in Quebec I raised the following issue about GSS preauth and ABFAB. I want to be able to use GSS preauth between the RP and the KDC even if the initiator knows nothing about it. That is: gss-eap initiator <-> RP FAST(rp armor key, gss-preauth(gss-eap)) RP <->KDC When that happens: * The initiator should obtain a TGT which it probably can't use because well it doesn't know about gss preauth * The RP should obtain a service ticket. This is critical and is the motivation for allowing gss preauth even when the initiator dosen't know about it. This allows the KDC to be a central policy point all the time gss-eap is used. * The initiator and KDC know the TGT key * The initiator, RP and KDC know the context key for the gss-eap context between the initiator and RP. It's not critical the KDC knows this key, but it will is there any interest in figuring out how to do this. If we cannot then Moonshot may end up introducing a separate eap-preauth proposal to meet this use case. It would be highly desirable to avoid both eap-preauth and gss-preauth. I think everyone agrees that gss-preauth is cleaner if we can make it work. From rafa@um.es Tue Sep 6 08:26:46 2011 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7198921F8B88 for ; Tue, 6 Sep 2011 08:26:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_42=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id poH+E6cBtWiL for ; Tue, 6 Sep 2011 08:26:46 -0700 (PDT) Received: from xenon12.um.es (xenon12.um.es [155.54.212.166]) by ietfa.amsl.com (Postfix) with ESMTP id C99D721F8B87 for ; Tue, 6 Sep 2011 08:26:45 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by xenon12.um.es (Postfix) with ESMTP id 331594B8ED; Tue, 6 Sep 2011 17:28:30 +0200 (CEST) X-Virus-Scanned: by antispam in UMU at xenon12.um.es Received: from xenon12.um.es ([127.0.0.1]) by localhost (xenon12.um.es [127.0.0.1]) (amavisd-new, port 10024) with LMTP id mo0Vf0U6OP3r; Tue, 6 Sep 2011 17:28:29 +0200 (CEST) Received: from inf-205-200.inf.um.es (inf-205-200.inf.um.es [155.54.205.200]) (Authenticated sender: rafa) by xenon12.um.es (Postfix) with ESMTPA id AABF04BCCF; Tue, 6 Sep 2011 17:28:25 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: Rafa Marin Lopez In-Reply-To: Date: Tue, 6 Sep 2011 17:28:24 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <10307ADF-9193-4E3F-B145-C5FBD8AC0E08@um.es> References: To: Sam Hartman X-Mailer: Apple Mail (2.1084) Cc: abfab@ietf.org Subject: Re: [abfab] GSS-Preauth and decoupling for GSS-EAP X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Sep 2011 15:26:46 -0000 Hi Sam: Please see my comments/questions inline. El 06/09/2011, a las 15:52, Sam Hartman escribi=F3: >=20 > Hi. > At the mic in Quebec I raised the following issue about GSS preauth = and > ABFAB. >=20 > I want to be able to use GSS preauth between the RP and the KDC even = if > the initiator knows nothing about it. Could you elaborate a little bit about the motivation related to this = and what is the associated issue? >=20 > That is: gss-eap initiator <-> RP FAST(rp armor key, > gss-preauth(gss-eap)) RP <->KDC When that happens: Before going into detail I would like to understand this flow (at first = sight, it vaguely reminded me the use of IAKERB where the RP is IAKERB = proxy. But it seems you are pursuing a different thing). It seems that = the RP is acting as Kerberos client that uses a GSS-API based = pre-authentication mechanism and the content of the gss-api token = contains the gss-eap token provided by the user. Is that right?=20 Best regards and thanks in advance. >=20 > * The initiator should obtain a TGT which it probably can't use = because > well it doesn't know about gss preauth >=20 > * The RP should obtain a service ticket. This is critical and is the > motivation for allowing gss preauth even when the initiator dosen't > know about it. This allows the KDC to be a central policy point all > the time gss-eap is used. >=20 > * The initiator and KDC know the TGT key >=20 > * The initiator, RP and KDC know the context key for the gss-eap = context > between the initiator and RP. It's not critical the KDC knows this > key, but it will >=20 > is there any interest in figuring out how to do this. If we cannot = then > Moonshot may end up introducing a separate eap-preauth proposal to = meet > this use case. It would be highly desirable to avoid both eap-preauth > and gss-preauth. I think everyone agrees that gss-preauth is cleaner = if > we can make it work. > _______________________________________________ > abfab mailing list > abfab@ietf.org > https://www.ietf.org/mailman/listinfo/abfab ------------------------------------------------------- Rafael Marin Lopez, PhD Dept. Information and Communications Engineering (DIIC) Faculty of Computer Science-University of Murcia 30100 Murcia - Spain Telf: +34868888501 Fax: +34868884151 e-mail: rafa@um.es ------------------------------------------------------- From hartmans@painless-security.com Tue Sep 6 08:37:20 2011 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F90D21F8BFE for ; Tue, 6 Sep 2011 08:37:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.859 X-Spam-Level: X-Spam-Status: No, score=-1.859 tagged_above=-999 required=5 tests=[AWL=-0.194, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_42=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7azqo9-0uUbz for ; Tue, 6 Sep 2011 08:37:20 -0700 (PDT) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id 1127421F8B74 for ; Tue, 6 Sep 2011 08:37:19 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id 6628120184; Tue, 6 Sep 2011 11:41:07 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 4FF7A42B7; Tue, 6 Sep 2011 11:38:57 -0400 (EDT) From: Sam Hartman To: Rafa Marin Lopez References: <10307ADF-9193-4E3F-B145-C5FBD8AC0E08@um.es> Date: Tue, 06 Sep 2011 11:38:57 -0400 In-Reply-To: <10307ADF-9193-4E3F-B145-C5FBD8AC0E08@um.es> (Rafa Marin Lopez's message of "Tue, 6 Sep 2011 17:28:24 +0200") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Cc: abfab@ietf.org Subject: Re: [abfab] GSS-Preauth and decoupling for GSS-EAP X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Sep 2011 15:37:20 -0000 >>>>> "Rafa" == Rafa Marin Lopez writes: Rafa> Hi Sam: Please see my comments/questions inline. Rafa> El 06/09/2011, a las 15:52, Sam Hartman escribió: >> >> Hi. At the mic in Quebec I raised the following issue about GSS >> preauth and ABFAB. >> >> I want to be able to use GSS preauth between the RP and the KDC >> even if the initiator knows nothing about it. Rafa> Could you elaborate a little bit about the motivation related Rafa> to this and what is the associated issue? Sure. The idea is that you have some resource domain of servers. You'd like to use GSS-EAP (ABFAB) to access them. However you want a central place to define policy, perform authorizations, etc. You've decided that Kerberos works well for that. All authentications into the domain must go through the KDC. Only the KDC can create authorizations. You want the initiator to be able to take advantage of a TGT for fast reauthentication within a domain if the initiator understands how. However, you want to work with any initiator. So, depending on gss-preauth-specific changes to the ininitiator isn't acceptable. In particular you don't want to have to bypass the KDC for old initiators. Services are not trusted to make authorization decisions. >> >> That is: gss-eap initiator <-> RP FAST(rp armor key, >> gss-preauth(gss-eap)) RP <->KDC When that happens: Rafa> Before going into detail I would like to understand this flow Rafa> (at first sight, it vaguely reminded me the use of IAKERB Rafa> where the RP is IAKERB proxy. But it seems you are pursuing a Rafa> different thing). It seems that the RP is acting as Kerberos Rafa> client that uses a GSS-API based pre-authentication mechanism Rafa> and the content of the gss-api token contains the gss-eap Rafa> token provided by the user. Is that right? Your understanding is correct. --Sam From nico@cryptonector.com Tue Sep 6 15:34:54 2011 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C01FD21F8F89 for ; Tue, 6 Sep 2011 15:34:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.839 X-Spam-Level: X-Spam-Status: No, score=-2.839 tagged_above=-999 required=5 tests=[AWL=-0.862, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sUFzv2OsNtOu for ; Tue, 6 Sep 2011 15:34:54 -0700 (PDT) Received: from homiemail-a67.g.dreamhost.com (caiajhbdcaid.dreamhost.com [208.97.132.83]) by ietfa.amsl.com (Postfix) with ESMTP id 3C0E121F8F81 for ; Tue, 6 Sep 2011 15:34:54 -0700 (PDT) Received: from homiemail-a67.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a67.g.dreamhost.com (Postfix) with ESMTP id C89DD88069 for ; Tue, 6 Sep 2011 15:36:41 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc: content-type; q=dns; s=cryptonector.com; b=qafi5UYEhbbN+DRG+vtsD uQXo9fXoykXY6X3DWyfms3hVg9dfks4KBjoRWEn+tvLSIm4KO0RmkPnPn9aobV2K MHnWvx/l/O1oXFmRN7WKNAjnp3lo1D7vLqnNOXa3oil4JmXJWSLm1e++Hu9oepWC iiqo7F2oyT8RHRBA7KJAvk= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=W8BFwZqmAGgSFUoeGx+x XxEeuOs=; b=YEitSTv2NlBlwlbllBDYv1p46QmtcA4nJbCvEFtNLVoUYU9BJqTm Yh/ilCu9QSzwsNBRe+hkADwDNPFGQ190iXWAbYFhDRnhz1/0xjk9zYuPY8T2tf2p GJaNGRoz/54So/zCr1qMU8sFDmJKe3GXIImuqqt46hCa7qdkC5BfeV8= Received: from mail-pz0-f45.google.com (mail-pz0-f45.google.com [209.85.210.45]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a67.g.dreamhost.com (Postfix) with ESMTPSA id AD9C888064 for ; Tue, 6 Sep 2011 15:36:41 -0700 (PDT) Received: by pzk33 with SMTP id 33so17189921pzk.18 for ; Tue, 06 Sep 2011 15:36:41 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.33.164 with SMTP id s4mr2039645pbi.265.1315348601391; Tue, 06 Sep 2011 15:36:41 -0700 (PDT) Received: by 10.68.66.163 with HTTP; Tue, 6 Sep 2011 15:36:41 -0700 (PDT) In-Reply-To: References: Date: Tue, 6 Sep 2011 17:36:41 -0500 Message-ID: From: Nico Williams To: Sam Hartman Content-Type: text/plain; charset=UTF-8 Cc: abfab@ietf.org Subject: Re: [abfab] GSS-Preauth and decoupling for GSS-EAP X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Sep 2011 22:34:54 -0000 Options to make this happen: a) Make the GSS-EAP client aware of the AS exchange and give it the bits it needs to recover the reply key and extract the credentials. Now how to get a service ticket for the RP in a round-trip efficient way? Well, have the RP mint one and be done, say. Or define a new way to use a TGT as an additional ticket with which to get the desired service ticket (sortof like reverse user-to-user). b) Define a new AS-like exchange where the final reply in a successful case contains a KRB-CRED, so that multiple tickets may be issued at once, then apply the solution above this one. c) Add some AS-REQ flags so that the AS-REP will contain an pre-auth element that contains a KRB-CRED in it with the desired tickets. In this case the enc-part of the AS-REP will be useless and will be thrown out. d) Add some AS-REQ flags so that the AS-REP's pre-auth method data will contain an embedded KRB-CRED (in the case of GSS pre-auth probably using the Null enctype and embedded in a wrap token). It all sounds rather messy to me. Desirable, yes, but also messy. (d) implies that the pre-auth plugin on the KDC must have access to all details of the AS-REQ. Probably not a big deal. It also implies that the pre-auth plugiin must have some way to get the desired tickets minted, which sounds like a fairly major abstraction violation, but one I could make peace with. (a), (b), and (c) would make GSS-EAP as a protocol have too much Kerberos knowledge for my comfort. I think (d) is the best option, then. The best part of this though is that it gives you a reason to want GSS pre-auth ;) Nico -- From hartmans@painless-security.com Tue Sep 6 16:17:40 2011 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78EDE21F8F39 for ; Tue, 6 Sep 2011 16:17:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.149 X-Spam-Level: X-Spam-Status: No, score=-2.149 tagged_above=-999 required=5 tests=[AWL=0.116, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w8lY8-aDtIWv for ; Tue, 6 Sep 2011 16:17:40 -0700 (PDT) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id 014E021F8F34 for ; Tue, 6 Sep 2011 16:17:39 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id C50C820384; Tue, 6 Sep 2011 19:21:27 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 62D4342B7; Tue, 6 Sep 2011 19:19:17 -0400 (EDT) From: Sam Hartman To: Nico Williams References: Date: Tue, 06 Sep 2011 19:19:17 -0400 In-Reply-To: (Nico Williams's message of "Tue, 6 Sep 2011 17:36:41 -0500") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: abfab@ietf.org Subject: Re: [abfab] GSS-Preauth and decoupling for GSS-EAP X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Sep 2011 23:17:40 -0000 >>>>> "Nico" == Nico Williams writes: Nico> Options to make this happen: a) Make the GSS-EAP client aware Nico> of the AS exchange and give it the bits it needs to recover Nico> the reply key and extract the credentials. Now how to get a Nico> service ticket for the RP in a round-trip efficient way? Nico> Well, have the RP mint one and be done, say. Or define a new Nico> way to use a TGT as an additional ticket with which to get the Nico> desired service ticket (sortof like reverse user-to-user). I would prefer any Kerberos knowledge to be optional in gss-eap so I Nico> don't like this. Nico> b) Define a new AS-like exchange where the final reply in a Nico> successful case contains a KRB-CRED, so that multiple tickets Nico> may be issued at once, then apply the solution above this one. dito Nico> c) Add some AS-REQ flags so that the AS-REP will contain an Nico> pre-auth element that contains a KRB-CRED in it with the Nico> desired tickets. In this case the enc-part of the AS-REP will Nico> be useless and will be thrown out. Nico> d) Add some AS-REQ flags so that the AS-REP's pre-auth method Nico> data will contain an embedded KRB-CRED (in the case of GSS Nico> pre-auth probably using the Null enctype and embedded in a Nico> wrap token). I don't see the difference between C and D. Also, this all seems like it focuses on the part of the problem where I see lots of options rather than the part of the problem I don't know how to deal with. Namely, I don't understand how to make the key hierarchy work out right across the gss-preauth boundary without either 1) building Kerberos knowledge into the initiator 2) having the acceptor gain the TGT key. Obviously, since I'm willing to go to EAP preauth instead of gss preauth, I'm OK building what amounts to EAP knowledge into the acceptor and preauth method and playing with the reply key. I'd like to find something cleaner. From rafa@um.es Wed Sep 7 08:29:14 2011 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06F8521F8AFB for ; Wed, 7 Sep 2011 08:29:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.999 X-Spam-Level: X-Spam-Status: No, score=-3.999 tagged_above=-999 required=5 tests=[AWL=2.000, BAYES_00=-2.599, J_CHICKENPOX_42=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dI4AWnSC36mU for ; Wed, 7 Sep 2011 08:29:09 -0700 (PDT) Received: from xenon11.um.es (xenon11.um.es [155.54.212.165]) by ietfa.amsl.com (Postfix) with ESMTP id F31DB21F8AF9 for ; Wed, 7 Sep 2011 08:29:08 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by xenon11.um.es (Postfix) with ESMTP id 3AA275396D; Wed, 7 Sep 2011 17:30:53 +0200 (CEST) X-Virus-Scanned: by antispam in UMU at xenon11.um.es Received: from xenon11.um.es ([127.0.0.1]) by localhost (xenon11.um.es [127.0.0.1]) (amavisd-new, port 10024) with LMTP id rz0NRXTKdE+x; Wed, 7 Sep 2011 17:30:53 +0200 (CEST) Received: from vpn_um-194-117.inf.um.es (vpn_um-194-117.inf.um.es [155.54.194.117]) (Authenticated sender: rafa) by xenon11.um.es (Postfix) with ESMTPA id 48B415395E; Wed, 7 Sep 2011 17:30:49 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: Rafa Marin Lopez In-Reply-To: Date: Wed, 7 Sep 2011 17:30:45 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <5DAD8828-CF12-4A1D-8699-1ED02EDF0377@um.es> References: <10307ADF-9193-4E3F-B145-C5FBD8AC0E08@um.es> To: Sam Hartman X-Mailer: Apple Mail (2.1084) Cc: abfab@ietf.org Subject: Re: [abfab] GSS-Preauth and decoupling for GSS-EAP X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Sep 2011 15:29:14 -0000 Hi Sam: Thanks for these clarifications. My comments inline again. El 06/09/2011, a las 17:38, Sam Hartman escribi=F3: >>>>>> "Rafa" =3D=3D Rafa Marin Lopez writes: >=20 > Rafa> Hi Sam: Please see my comments/questions inline. >=20 > Rafa> El 06/09/2011, a las 15:52, Sam Hartman escribi=F3: >=20 >>>=20 >>> Hi. At the mic in Quebec I raised the following issue about GSS >>> preauth and ABFAB. >>>=20 >>> I want to be able to use GSS preauth between the RP and the KDC >>> even if the initiator knows nothing about it. >=20 > Rafa> Could you elaborate a little bit about the motivation related > Rafa> to this and what is the associated issue? >=20 > Sure. > The idea is that you have some resource domain of servers. > You'd like to use GSS-EAP (ABFAB) to access them. > However you want a central place to define policy, perform > authorizations, etc. > You've decided that Kerberos works well for that. > All authentications into the domain must go through the KDC. Only the > KDC can create authorizations. >=20 > You want the initiator to be able to take advantage of a TGT for fast > reauthentication within a domain if the initiator understands how. May we assume that TGT will be involved in a Kerberos exchange later = on?. I mean I think that TGT will have to be provided to the initiator = somehow ( within GSS-EAP exchange? ) I assume that initiator will have some Kerberos source code implemented = to handle the TGT and to request service tickets. Otherwise, having a = TGT is useless as you mention. Thus I would assume that initiator has Kerberos source code implemented. = is it so unreal that initiator would have a kerberos client?. =20 Another question would be how the TGT will be used by the initiator and = how everything will operate... where the keys will be distributed and = how etc...=20 > However, you want to work with any initiator. So, depending on > gss-preauth-specific changes to the ininitiator isn't acceptable. Mmmmm this seems to contradict your sentence "You'd like to use GSS-EAP = (ABFAB) to access them." no?. At least it is assumed that the initiator = has to implement GSS-EAP. So "any" initiator would not work.=20 Also, it would be interesting to know why it may not be acceptable. = After all, we are doing changes to include new technology :). > In > particular you don't want to have to bypass the KDC for old = initiators. > Services are not trusted to make authorization decisions. Well, if they are old initiators most probably they will implement = legacy mechanisms for authenticating services (not even GSS-EAP except, = perhaps, Kerberos GSS-API mechanism, for example). On the other hand, = services will need to be updated to support this (so no support for old = services). Apart from this interesting scenario you mention, I would also like to = suggest to analyze another possible case for fast re-authentication, = when the initiator has to go through the RP. The idea is simple if we = can assume GSS-API pre-authentication mechanism in the initiator and = IAKERB. As evident, GSS-EAP would be a potential mechanism to perform = the GSS-API pre-authentication as it has been already discussed. Then = the initiator will have a TGT and can request service tickets. Initiator (GSS-API pre-authentication mech + IAKERB) --- RP (IAKERB = proxy) --- KDC (Acceptor) Here, KDC is also the central point of authentication and authorization. = Certainly the assumptions/requirements differ a little bit in both cases = but they seem interesting. In any case, I believe it would be good to have a clearer picture of the = general goal (e.g. to achieve fast re-authentication in GSS-EAP or = so...). Then define requirements for a potential solution and needs. Best regards. >=20 >=20 >=20 >>>=20 >>> That is: gss-eap initiator <-> RP FAST(rp armor key, >>> gss-preauth(gss-eap)) RP <->KDC When that happens: >=20 > Rafa> Before going into detail I would like to understand this flow > Rafa> (at first sight, it vaguely reminded me the use of IAKERB > Rafa> where the RP is IAKERB proxy. But it seems you are pursuing a > Rafa> different thing). It seems that the RP is acting as Kerberos > Rafa> client that uses a GSS-API based pre-authentication mechanism > Rafa> and the content of the gss-api token contains the gss-eap > Rafa> token provided by the user. Is that right? >=20 > Your understanding is correct. >=20 > --Sam ------------------------------------------------------- Rafael Marin Lopez, PhD Dept. Information and Communications Engineering (DIIC) Faculty of Computer Science-University of Murcia 30100 Murcia - Spain Telf: +34868888501 Fax: +34868884151 e-mail: rafa@um.es ------------------------------------------------------- From rafa@um.es Wed Sep 7 08:31:15 2011 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C61BE21F8B22 for ; Wed, 7 Sep 2011 08:31:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.299 X-Spam-Level: X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[AWL=-0.700, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1WeP50FI+8nT for ; Wed, 7 Sep 2011 08:31:15 -0700 (PDT) Received: from xenon12.um.es (xenon12.um.es [155.54.212.166]) by ietfa.amsl.com (Postfix) with ESMTP id 0C9DE21F8B20 for ; Wed, 7 Sep 2011 08:31:15 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by xenon12.um.es (Postfix) with ESMTP id 019A94BCDC; Wed, 7 Sep 2011 17:33:03 +0200 (CEST) X-Virus-Scanned: by antispam in UMU at xenon12.um.es Received: from xenon12.um.es ([127.0.0.1]) by localhost (xenon12.um.es [127.0.0.1]) (amavisd-new, port 10024) with LMTP id f88TpcXipR9y; Wed, 7 Sep 2011 17:32:58 +0200 (CEST) Received: from vpn_um-194-117.inf.um.es (vpn_um-194-117.inf.um.es [155.54.194.117]) (Authenticated sender: rafa) by xenon12.um.es (Postfix) with ESMTPA id 3751F4BCBF; Wed, 7 Sep 2011 17:32:54 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: Rafa Marin Lopez In-Reply-To: Date: Wed, 7 Sep 2011 17:32:54 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Nico Williams X-Mailer: Apple Mail (2.1084) Cc: abfab@ietf.org Subject: Re: [abfab] GSS-Preauth and decoupling for GSS-EAP X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Sep 2011 15:31:15 -0000 Hi Nico: Are you suggesting the initiator sends the TGT and obtains several STs = in return from the KDC in a single exchange? Best regards. El 07/09/2011, a las 00:36, Nico Williams escribi=F3: > Options to make this happen: >=20 > a) Make the GSS-EAP client aware of the AS exchange and give it the > bits it needs to recover the reply key and extract the credentials. > Now how to get a service ticket for the RP in a round-trip efficient > way? Well, have the RP mint one and be done, say. Or define a new > way to use a TGT as an additional ticket with which to get the desired > service ticket (sortof like reverse user-to-user). >=20 > b) Define a new AS-like exchange where the final reply in a successful > case contains a KRB-CRED, so that multiple tickets may be issued at > once, then apply the solution above this one. >=20 > c) Add some AS-REQ flags so that the AS-REP will contain an pre-auth > element that contains a KRB-CRED in it with the desired tickets. In > this case the enc-part of the AS-REP will be useless and will be > thrown out. >=20 > d) Add some AS-REQ flags so that the AS-REP's pre-auth method data > will contain an embedded KRB-CRED (in the case of GSS pre-auth > probably using the Null enctype and embedded in a wrap token). >=20 > It all sounds rather messy to me. Desirable, yes, but also messy. >=20 > (d) implies that the pre-auth plugin on the KDC must have access to > all details of the AS-REQ. Probably not a big deal. It also implies > that the pre-auth plugiin must have some way to get the desired > tickets minted, which sounds like a fairly major abstraction > violation, but one I could make peace with. >=20 > (a), (b), and (c) would make GSS-EAP as a protocol have too much > Kerberos knowledge for my comfort. >=20 > I think (d) is the best option, then. >=20 > The best part of this though is that it gives you a reason to want GSS > pre-auth ;) >=20 > Nico > -- > _______________________________________________ > abfab mailing list > abfab@ietf.org > https://www.ietf.org/mailman/listinfo/abfab ------------------------------------------------------- Rafael Marin Lopez, PhD Dept. Information and Communications Engineering (DIIC) Faculty of Computer Science-University of Murcia 30100 Murcia - Spain Telf: +34868888501 Fax: +34868884151 e-mail: rafa@um.es ------------------------------------------------------- From nico@cryptonector.com Wed Sep 7 08:43:44 2011 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12ACE21F8CA5 for ; Wed, 7 Sep 2011 08:43:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.822 X-Spam-Level: X-Spam-Status: No, score=-2.822 tagged_above=-999 required=5 tests=[AWL=-0.845, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6HYpNpQHvlne for ; Wed, 7 Sep 2011 08:43:41 -0700 (PDT) Received: from homiemail-a71.g.dreamhost.com (caiajhbdcaid.dreamhost.com [208.97.132.83]) by ietfa.amsl.com (Postfix) with ESMTP id BC14521F8CA7 for ; Wed, 7 Sep 2011 08:43:41 -0700 (PDT) Received: from homiemail-a71.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a71.g.dreamhost.com (Postfix) with ESMTP id 23B35428078 for ; Wed, 7 Sep 2011 08:45:27 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc :content-type:content-transfer-encoding; q=dns; s= cryptonector.com; b=FbLdCF1+LCF4xIDd1iRcyK1X8C1+Y/kPyvOF5ONq1zRx 2Nyb1pcdzfcAocGgOZqlftGRo/QKWmmf9Vok3V/EtwutA9HZk68nnRW9VTuPFp3J JWTfS3s2fZq4RMZS46Tza23fnxF8AJe1PEOlfNFcPwRVgHC/a+O7tHou2Tjl3GI= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type:content-transfer-encoding; s= cryptonector.com; bh=yM70Z6KL87e+pLCjE8MvR0qV7zk=; b=N0tFTGsODhA OWpOgiyW8Dr2YdT6tbIdiJY6ngvzdUddA+nm8XjGJFb2Gd+yjeKJQozFkcAY1ZBZ CukDRJ9zSB32fAcdjbXl6uRyS/PemMRhPMVvtG/dS1alBCYr81zzCiuXSNAC/zLv /Nx0pV1/MRUfXxUSOwNmqRKjBFdZp1g4= Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a71.g.dreamhost.com (Postfix) with ESMTPSA id BEB71428080 for ; Wed, 7 Sep 2011 08:45:12 -0700 (PDT) Received: by ywe9 with SMTP id 9so333693ywe.31 for ; Wed, 07 Sep 2011 08:45:12 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.0.34 with SMTP id 2mr12135930pbb.399.1315410311609; Wed, 07 Sep 2011 08:45:11 -0700 (PDT) Received: by 10.68.66.163 with HTTP; Wed, 7 Sep 2011 08:45:11 -0700 (PDT) In-Reply-To: References: Date: Wed, 7 Sep 2011 10:45:11 -0500 Message-ID: From: Nico Williams To: Sam Hartman Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: abfab@ietf.org Subject: Re: [abfab] GSS-Preauth and decoupling for GSS-EAP X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Sep 2011 15:43:44 -0000 On Tue, Sep 6, 2011 at 6:19 PM, Sam Hartman wrote: > =C2=A0 =C2=A0Nico> c) Add some AS-REQ flags so that the AS-REP will conta= in an > =C2=A0 =C2=A0Nico> pre-auth element that contains a KRB-CRED in it with t= he > =C2=A0 =C2=A0Nico> desired tickets. =C2=A0In this case the enc-part of th= e AS-REP will > =C2=A0 =C2=A0Nico> be useless and will be thrown out. > > =C2=A0 =C2=A0Nico> d) Add some AS-REQ flags so that the AS-REP's pre-auth= method > =C2=A0 =C2=A0Nico> data will contain an embedded KRB-CRED (in the case of= GSS > =C2=A0 =C2=A0Nico> pre-auth probably using the Null enctype and embedded = in a > =C2=A0 =C2=A0Nico> wrap token). > > I don't see the difference between C and D. I do. In (c) the RP has to collect the additional PA and bundle it in. In (d) the PA method at the KDC end-point takes care of that. Less abstraction violation in the RP -> better. > Also, this all seems like it focuses on the part of the problem where I > see lots of options rather than the part of the problem I don't know how > to deal with. > Namely, I don't understand how to make the key hierarchy work out right > across the gss-preauth boundary without either > > 1) building Kerberos knowledge into the initiator > > 2) having the acceptor gain the TGT key. The initiator MUST have a Kerberos client, else it MUST use a trusted proxy wherever Kerberos is required. I've no interest in building a trusted proxy here. So the question really is: what kind of violence to the initiator might we accept? Now, imagine for a second a variation on GSS_Init_sec_context() specifically for IAKERB-like mechanisms that outputs... a credential handle, just like GSS_Accept_sec_context does... The KRB-CRED included in a wrap token embedded a GSS-EAP token from the acceptor (really, the KDC), would be suitable for constructing such an output credential handle. The initator app would then GSS_Store_cred(), if it cares to. Or, when the app uses the original GSS_Init_sec_context(), the mechanism or the mechglue could just do it for the app according to local policy. Nico -- From nico@cryptonector.com Wed Sep 7 08:47:07 2011 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF52221F8CB5 for ; Wed, 7 Sep 2011 08:47:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.806 X-Spam-Level: X-Spam-Status: No, score=-2.806 tagged_above=-999 required=5 tests=[AWL=-0.829, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U8QQbY5o5Kzp for ; Wed, 7 Sep 2011 08:47:06 -0700 (PDT) Received: from homiemail-a24.g.dreamhost.com (caiajhbdcaid.dreamhost.com [208.97.132.83]) by ietfa.amsl.com (Postfix) with ESMTP id 91A0A21F8CAF for ; Wed, 7 Sep 2011 08:47:06 -0700 (PDT) Received: from homiemail-a24.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a24.g.dreamhost.com (Postfix) with ESMTP id 50EAC2C806D for ; Wed, 7 Sep 2011 08:48:56 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc: content-type; q=dns; s=cryptonector.com; b=KUBdNvSik8AyMYwYsCKNr kpoGRDaepxoy8l2KUHH32w/8Av0B65vjC5bYP5N0c5NqGKVh1+Z9/OUzuaQxL4QL Vu698a5LdqRWkBtPkTkMcX3SBFINvy/kFg1Bq1Vq2FnWtWNFi1lShUzQxkV6iRlf vJwsTiwW58bVSvwVo/4QiU= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=xAZMgfExZxD6G4LhxTtS lCKauYc=; b=XA6OizGY+VXqSeu5Y0sVnZ66/9HbmoKFKMhjECZTSSUwUACh//Fj IdI5rkb/dRLxSE1FTfor2JzErvHMT2ZuXxVi3xCQWcz2aVl7tUoUep1w3qxm+NPK IuIGnK0/uVLKdpeygFVRDTfaPiL63xE3zGTbAXW1AnRToeZ9YnaAadM= Received: from mail-pz0-f45.google.com (mail-pz0-f45.google.com [209.85.210.45]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a24.g.dreamhost.com (Postfix) with ESMTPSA id 3EE6E2C806B for ; Wed, 7 Sep 2011 08:48:56 -0700 (PDT) Received: by pzk33 with SMTP id 33so18907789pzk.18 for ; Wed, 07 Sep 2011 08:48:55 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.33.164 with SMTP id s4mr3311254pbi.265.1315410535710; Wed, 07 Sep 2011 08:48:55 -0700 (PDT) Received: by 10.68.66.163 with HTTP; Wed, 7 Sep 2011 08:48:55 -0700 (PDT) In-Reply-To: References: Date: Wed, 7 Sep 2011 10:48:55 -0500 Message-ID: From: Nico Williams To: Rafa Marin Lopez Content-Type: text/plain; charset=UTF-8 Cc: abfab@ietf.org Subject: Re: [abfab] GSS-Preauth and decoupling for GSS-EAP X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Sep 2011 15:47:07 -0000 On Wed, Sep 7, 2011 at 10:32 AM, Rafa Marin Lopez wrote: > Are you suggesting the initiator sends the TGT and obtains several STs in return from the KDC in a single exchange? Yes. It'd be a nice round-trip optimization, no? A combination of AS and TGS exchange. Note that this does not prevent the AS and TGS from being logically separated since the AS could act as a proxy for the client in talking to the TGS. Nico -- From hartmans@painless-security.com Thu Sep 8 06:08:43 2011 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3249421F8B49 for ; Thu, 8 Sep 2011 06:08:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.155 X-Spam-Level: X-Spam-Status: No, score=-2.155 tagged_above=-999 required=5 tests=[AWL=0.110, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5ADi172GnEQS for ; Thu, 8 Sep 2011 06:08:42 -0700 (PDT) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id A496121F8B0B for ; Thu, 8 Sep 2011 06:08:42 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id 883A720384; Thu, 8 Sep 2011 09:12:30 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id E4E2742B7; Thu, 8 Sep 2011 09:10:27 -0400 (EDT) From: Sam Hartman To: Rafa Marin Lopez References: <10307ADF-9193-4E3F-B145-C5FBD8AC0E08@um.es> <5DAD8828-CF12-4A1D-8699-1ED02EDF0377@um.es> Date: Thu, 08 Sep 2011 09:10:27 -0400 In-Reply-To: <5DAD8828-CF12-4A1D-8699-1ED02EDF0377@um.es> (Rafa Marin Lopez's message of "Wed, 7 Sep 2011 17:30:45 +0200") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Cc: abfab@ietf.org Subject: Re: [abfab] GSS-Preauth and decoupling for GSS-EAP X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Sep 2011 13:08:43 -0000 Rafa> Hi Sam: Thanks for these clarifications. My comments inline Rafa> again. Rafa> El 06/09/2011, a las 17:38, Sam Hartman escribió: >>>>>>> "Rafa" == Rafa Marin Lopez writes: >> Rafa> Hi Sam: Please see my comments/questions inline. >> Rafa> El 06/09/2011, a las 15:52, Sam Hartman escribió: >> >>>> >>> Hi. At the mic in Quebec I raised the following issue about GSS >>> preauth and ABFAB. >>> >>> I want to be able to use GSS preauth between the RP and the KDC >>> even if the initiator knows nothing about it. > > Rafa> Could you elaborate a little bit about the motivation related > Rafa> to this and what is the associated issue? > > Sure. > The idea is that you have some resource domain of servers. > You'd like to use GSS-EAP (ABFAB) to access them. > However you want a central place to define policy, perform > authorizations, etc. > You've decided that Kerberos works well for that. > All authentications into the domain must go through the KDC. Only the > KDC can create authorizations. > > You want the initiator to be able to take advantage of a TGT for fast > reauthentication within a domain if the initiator understands how. May we assume that TGT will be involved in a Kerberos exchange later on?. I mean I think that TGT will have to be provided to the initiator somehow ( within GSS-EAP exchange? ) I assume that initiator will have some Kerberos source code implemented to handle the TGT and to request service tickets. Otherwise, having a TGT is useless as you mention. I don't think these are reasonable assumptions. I think we can assume that if a TGT is used, it is provided to the initiator. I'm fine if a TGT is only provided when it is going to be used. However, I want a service ticket provided (with authorization data) to the RP even if the initiator has never heard of Kerberos and has no Kerberos code at all other than the RFC 3961 implementation inherent in gss-eap. In response to Nico's question about trusted proxies. I don't think there is much trust involved in allowing the RP to interact with a service ticket. In effect what I think we're building is a form of protocol transition where rather than trusting the RP to assert that the client is authenticating, we're providing a GSS-EAP exchange targeted at the RP to a KDC. To me, that level of trust (much less than protocol transition) is highly desirable. --Sam From nico@cryptonector.com Thu Sep 8 08:44:07 2011 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D35AE21F8B1A for ; Thu, 8 Sep 2011 08:44:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.72 X-Spam-Level: X-Spam-Status: No, score=-2.72 tagged_above=-999 required=5 tests=[AWL=-0.743, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VwfJcOQ994Cj for ; Thu, 8 Sep 2011 08:44:07 -0700 (PDT) Received: from homiemail-a66.g.dreamhost.com (caiajhbdccah.dreamhost.com [208.97.132.207]) by ietfa.amsl.com (Postfix) with ESMTP id 56ECB21F8ADE for ; Thu, 8 Sep 2011 08:44:07 -0700 (PDT) Received: from homiemail-a66.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a66.g.dreamhost.com (Postfix) with ESMTP id 712B735005B for ; Thu, 8 Sep 2011 08:45:59 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc: content-type; q=dns; s=cryptonector.com; b=dMPzVR4pFltSM1petlsL8 j5doRHc4EA/7oiaNvw6eN0dtstyV1OMOF/rz/0ywDxwkpG3Gpf8JKb3W5dRLorHh /xhZc3OFYzWqu2wFneqDjJqd3hLwqy3FXum8ORjZongSoQiNGrlqA/Qt9V/+OgNr wbmvqzkEp6sNizEWCRoT9g= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=7P09Jk4AjGLaduY6Enno qzMTcLY=; b=YhHIZKlK4yvoWUUAT2PFYfjA3UkKci8NO13W5IPPo2iT49AROs9x gXMvkznRjR7bvMUJMP2zkkw5dGdGKRg6ZWeTFzPf1B3fxmAP3yKytR51lav+2/iq z4LKoaOFHhx6VVQgNT4D29cQIGwfD1mjTif91poU52WWTwlEaS/j9rk= Received: from mail-pz0-f45.google.com (mail-pz0-f45.google.com [209.85.210.45]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a66.g.dreamhost.com (Postfix) with ESMTPSA id A967D350084 for ; Thu, 8 Sep 2011 08:45:58 -0700 (PDT) Received: by pzk33 with SMTP id 33so4711014pzk.18 for ; Thu, 08 Sep 2011 08:45:58 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.199.202 with SMTP id jm10mr1376010pbc.198.1315496758190; Thu, 08 Sep 2011 08:45:58 -0700 (PDT) Received: by 10.68.66.163 with HTTP; Thu, 8 Sep 2011 08:45:58 -0700 (PDT) In-Reply-To: References: <10307ADF-9193-4E3F-B145-C5FBD8AC0E08@um.es> <5DAD8828-CF12-4A1D-8699-1ED02EDF0377@um.es> Date: Thu, 8 Sep 2011 10:45:58 -0500 Message-ID: From: Nico Williams To: Sam Hartman Content-Type: text/plain; charset=UTF-8 Cc: abfab@ietf.org Subject: Re: [abfab] GSS-Preauth and decoupling for GSS-EAP X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Sep 2011 15:44:07 -0000 Oh, your main concern is not protocol transition for the initiator (though that'd be nice, no?) but protocol transition for the acceptor. But the acceptor doesn't need a TGT for this. Just an INITIAL service ticket will do (initial because, without a TGT for the user, what else can the service do but use a pre-auth that somehow produces an AP-REP with a reply key it can handle, with the KDC disallowing access to anything other than a service ticket with the acceptor as the target?). Nico -- From hartmans@painless-security.com Thu Sep 8 11:07:20 2011 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F067821F8B05 for ; Thu, 8 Sep 2011 11:07:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CDidq08J2C4u for ; Thu, 8 Sep 2011 11:07:19 -0700 (PDT) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id 7EBCA21F8B00 for ; Thu, 8 Sep 2011 11:07:19 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (unknown [18.111.119.84]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id 5B31420439; Thu, 8 Sep 2011 14:11:10 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id ACA0742B7; Thu, 8 Sep 2011 14:09:09 -0400 (EDT) From: Sam Hartman To: Nico Williams References: <10307ADF-9193-4E3F-B145-C5FBD8AC0E08@um.es> <5DAD8828-CF12-4A1D-8699-1ED02EDF0377@um.es> Date: Thu, 08 Sep 2011 14:09:09 -0400 In-Reply-To: (Nico Williams's message of "Thu, 8 Sep 2011 10:45:58 -0500") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: abfab@ietf.org Subject: Re: [abfab] GSS-Preauth and decoupling for GSS-EAP X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Sep 2011 18:07:20 -0000 >>>>> "Nico" == Nico Williams writes: Nico> Oh, your main concern is not protocol transition for the Nico> initiator (though that'd be nice, no?) but protocol transition Nico> for the acceptor. But the acceptor doesn't need a TGT for Nico> this. Just an INITIAL service ticket will do (initial Nico> because, without a TGT for the user, what else can the service Nico> do but use a pre-auth that somehow produces an AP-REP with a Nico> reply key it can handle, with the KDC disallowing access to Nico> anything other than a service ticket with the acceptor as the Nico> target?). Right. The service doesn't need a TGT. I was hoping for a mechanism such that * a TGT is generated if the initiator can take it * A service ticket is generated all the time * The service never knows the TGT key * The service always knows the context key * The initiator need not know about the service ticket side of the business. --Sam From Josh.Howlett@ja.net Fri Sep 9 01:35:07 2011 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41E9B21F88B6 for ; Fri, 9 Sep 2011 01:35:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.774 X-Spam-Level: X-Spam-Status: No, score=-102.774 tagged_above=-999 required=5 tests=[AWL=-0.175, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5Ubwz6JYIlFO for ; Fri, 9 Sep 2011 01:35:06 -0700 (PDT) Received: from har003676.ukerna.ac.uk (har003676.ukerna.ac.uk [194.82.140.75]) by ietfa.amsl.com (Postfix) with ESMTP id A6FD321F86EC for ; Fri, 9 Sep 2011 01:35:05 -0700 (PDT) Received: from har003676.ukerna.ac.uk (localhost.localdomain [127.0.0.1]) by localhost (Email Security Appliance) with SMTP id 0AC484A6B65_E69D02BB; Fri, 9 Sep 2011 08:36:59 +0000 (GMT) Received: from EXC001.atlas.ukerna.ac.uk (exc001.atlas.ukerna.ac.uk [193.62.83.37]) by har003676.ukerna.ac.uk (Sophos Email Appliance) with ESMTP id C0E334A6B63_E69D02AF; Fri, 9 Sep 2011 08:36:58 +0000 (GMT) Received: from EXC001.atlas.ukerna.ac.uk ([193.62.83.37]) by EXC001 ([193.62.83.37]) with mapi id 14.01.0289.001; Fri, 9 Sep 2011 09:36:58 +0100 From: Josh Howlett To: Sam Hartman , Nico Williams Thread-Topic: [abfab] GSS-Preauth and decoupling for GSS-EAP Thread-Index: AQHMblJnBPZcYLava0CsARt0y4r+95VEup2A Date: Fri, 9 Sep 2011 08:36:57 +0000 Message-ID: In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.12.0.110505 x-originating-ip: [194.82.140.76] Content-Type: text/plain; charset="us-ascii" Content-ID: <48756DB24A5C134A81A07943B0B90FCC@ukerna.ac.uk> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "abfab@ietf.org" Subject: Re: [abfab] GSS-Preauth and decoupling for GSS-EAP X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Sep 2011 08:35:07 -0000 > >I was hoping for a mechanism such that > >* a TGT is generated if the initiator can take it > >* A service ticket is generated all the time > >* The service never knows the TGT key > >* The service always knows the context key > >* The initiator need not know about the service ticket side of the > business. Sam, For the general case, what if: 1. The KDC supplies the context key to the RP within the protected pre-auth exchange. 2. GSS mechanism specific methods are defined for returning a TGT from the KDC to the initiator. 3. GSS mechanism specific methods are defined for deriving the TGT session key. In the particular case of GSS EAP: 1: the context key is derived from the EAP MSK per the spec today. The RP doesn't get to see the MSK. 2: the GSS EAP mechanism already provides for subtokens; and we have already implemented the case where a subtoken is a service ticket. Perhaps the same model could be extended to other mechanisms? 3: the KDC and initiator independently derive the TGT session key from the EAP MSK. The RP doesn't get to see the MSK. 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 Oxford, Didcot, Oxfordshire. OX11 0SG From rafa@um.es Fri Sep 9 03:52:53 2011 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C1A921F8A95 for ; Fri, 9 Sep 2011 03:52:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.066 X-Spam-Level: X-Spam-Status: No, score=-5.066 tagged_above=-999 required=5 tests=[AWL=1.533, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zRyHpyHy-Fxy for ; Fri, 9 Sep 2011 03:52:52 -0700 (PDT) Received: from xenon14.um.es (xenon14.um.es [155.54.212.168]) by ietfa.amsl.com (Postfix) with ESMTP id 7C42B21F8713 for ; Fri, 9 Sep 2011 03:52:52 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by xenon14.um.es (Postfix) with ESMTP id 13DD15D617; Fri, 9 Sep 2011 12:54:45 +0200 (CEST) X-Virus-Scanned: by antispam in UMU at xenon14.um.es Received: from xenon14.um.es ([127.0.0.1]) by localhost (xenon14.um.es [127.0.0.1]) (amavisd-new, port 10024) with LMTP id tgdhjgMUMFuY; Fri, 9 Sep 2011 12:54:44 +0200 (CEST) Received: from inf-205-200.inf.um.es (inf-205-200.inf.um.es [155.54.205.200]) (Authenticated sender: rafa) by xenon14.um.es (Postfix) with ESMTPA id ED33F5D568; Fri, 9 Sep 2011 12:54:40 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Rafa Marin Lopez In-Reply-To: Date: Fri, 9 Sep 2011 12:54:40 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <71B4B2D0-F81E-4935-921D-81961E047AC6@um.es> References: <10307ADF-9193-4E3F-B145-C5FBD8AC0E08@um.es> <5DAD8828-CF12-4A1D-8699-1ED02EDF0377@um.es> To: Sam Hartman X-Mailer: Apple Mail (2.1084) Cc: abfab@ietf.org Subject: Re: [abfab] GSS-Preauth and decoupling for GSS-EAP X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Sep 2011 10:52:53 -0000 Hi Sam:=20 >=20 > May we assume that TGT will be involved in a Kerberos exchange later = on?. I mean I think that TGT will have to be provided to the initiator = somehow ( within GSS-EAP exchange? ) >=20 > I assume that initiator will have some Kerberos source code = implemented to handle the TGT and to request service tickets. Otherwise, = having a TGT is useless as you mention. >=20 > I don't think these are reasonable assumptions. Well, if we send a TGT or ST to the initiator, it would seem reasonable = to me that initiator knows how to handle it. But maybe it is not = reasonable.=20 In any case, it seems you consider that TGT or ST are provided to the = initiator as a opaque blob so that initiator will have to send later on = (as an opaque blob) to the RP. is that right?. > I think we can assume > that if a TGT is used, it is provided to the initiator. I was wondering how is that TGT provided to the initiator (within a = GSS-API token after a successful authentication?) and how the initiator = sends it to the RP.=20 > I'm fine if a > TGT is only provided when it is going to be used. However, I want a > service ticket provided (with authorization data) to the RP even if = the > initiator has never heard of Kerberos and has no Kerberos code at all > other than the RFC 3961 implementation inherent in gss-eap. Yes, I understand that it is what you want. What I am trying to see how = it could operate and the motivation. Best regards. >=20 > In response to Nico's question about trusted proxies. I don't think > there is much trust involved in allowing the RP to interact with a > service ticket. In effect what I think we're building is a form of > protocol transition where rather than trusting the RP to assert that = the > client is authenticating, we're providing a GSS-EAP exchange targeted = at > the RP to a KDC. > To me, that level of trust (much less than protocol transition) is > highly desirable. >=20 > --Sam ------------------------------------------------------- Rafael Marin Lopez, PhD Dept. Information and Communications Engineering (DIIC) Faculty of Computer Science-University of Murcia 30100 Murcia - Spain Telf: +34868888501 Fax: +34868884151 e-mail: rafa@um.es ------------------------------------------------------- From rafa@um.es Fri Sep 9 04:23:53 2011 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D6C921F8B08 for ; Fri, 9 Sep 2011 04:23:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.449 X-Spam-Level: X-Spam-Status: No, score=-3.449 tagged_above=-999 required=5 tests=[AWL=-0.850, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xrTvpmJskN2X for ; Fri, 9 Sep 2011 04:23:53 -0700 (PDT) Received: from xenon12.um.es (xenon12.um.es [155.54.212.166]) by ietfa.amsl.com (Postfix) with ESMTP id 09E1121F8AD2 for ; Fri, 9 Sep 2011 04:23:53 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by xenon12.um.es (Postfix) with ESMTP id 355174BCB8; Fri, 9 Sep 2011 13:25:45 +0200 (CEST) X-Virus-Scanned: by antispam in UMU at xenon12.um.es Received: from xenon12.um.es ([127.0.0.1]) by localhost (xenon12.um.es [127.0.0.1]) (amavisd-new, port 10024) with LMTP id JKlNeeIgjrT8; Fri, 9 Sep 2011 13:25:45 +0200 (CEST) Received: from inf-205-200.inf.um.es (inf-205-200.inf.um.es [155.54.205.200]) (Authenticated sender: rafa) by xenon12.um.es (Postfix) with ESMTPA id 892D14BCCC; Fri, 9 Sep 2011 13:25:41 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: Rafa Marin Lopez In-Reply-To: Date: Fri, 9 Sep 2011 13:25:41 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Nico Williams X-Mailer: Apple Mail (2.1084) Cc: abfab@ietf.org Subject: Re: [abfab] GSS-Preauth and decoupling for GSS-EAP X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Sep 2011 11:23:53 -0000 Hi Nico: El 07/09/2011, a las 17:48, Nico Williams escribi=F3: > On Wed, Sep 7, 2011 at 10:32 AM, Rafa Marin Lopez wrote: >> Are you suggesting the initiator sends the TGT and obtains several = STs in return from the KDC in a single exchange? >=20 > Yes. It'd be a nice round-trip optimization, no? A combination of AS > and TGS exchange. This is interesting since we already finished a work done by a student = here that pursued a similar goal: obtain several service tickets in one = round trip ;). Best regards. >=20 > Note that this does not prevent the AS and TGS from being logically > separated since the AS could act as a proxy for the client in talking > to the TGS. >=20 > Nico > -- ------------------------------------------------------- Rafael Marin Lopez, PhD Dept. Information and Communications Engineering (DIIC) Faculty of Computer Science-University of Murcia 30100 Murcia - Spain Telf: +34868888501 Fax: +34868884151 e-mail: rafa@um.es ------------------------------------------------------- From hartmans@painless-security.com Fri Sep 9 05:56:42 2011 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EEFC021F862F for ; Fri, 9 Sep 2011 05:56:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.86 X-Spam-Level: X-Spam-Status: No, score=-1.86 tagged_above=-999 required=5 tests=[AWL=-0.195, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_29=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V0Zc2cDOaNK1 for ; Fri, 9 Sep 2011 05:56:42 -0700 (PDT) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id 7FAE121F85F6 for ; Fri, 9 Sep 2011 05:56:42 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id 66C4B202FB; Fri, 9 Sep 2011 09:00:34 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 6AA4442B7; Fri, 9 Sep 2011 08:58:34 -0400 (EDT) From: Sam Hartman To: Rafa Marin Lopez References: <10307ADF-9193-4E3F-B145-C5FBD8AC0E08@um.es> <5DAD8828-CF12-4A1D-8699-1ED02EDF0377@um.es> <71B4B2D0-F81E-4935-921D-81961E047AC6@um.es> Date: Fri, 09 Sep 2011 08:58:34 -0400 In-Reply-To: <71B4B2D0-F81E-4935-921D-81961E047AC6@um.es> (Rafa Marin Lopez's message of "Fri, 9 Sep 2011 12:54:40 +0200") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: abfab@ietf.org Subject: Re: [abfab] GSS-Preauth and decoupling for GSS-EAP X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Sep 2011 12:56:43 -0000 >>>>> "Rafa" == Rafa Marin Lopez writes: Rafa> Hi Sam: >> >> May we assume that TGT will be involved in a Kerberos exchange >> later on?. I mean I think that TGT will have to be provided to >> the initiator somehow ( within GSS-EAP exchange? ) >> >> I assume that initiator will have some Kerberos source code >> implemented to handle the TGT and to request service >> tickets. Otherwise, having a TGT is useless as you mention. >> >> I don't think these are reasonable assumptions. Rafa> Well, if we send a TGT or ST to the initiator, it would seem Rafa> reasonable to me that initiator knows how to handle it. But Rafa> maybe it is not reasonable. I agree that if the initiator is going to use a TGT or ST then it's fine to assume it has code to deal with one. I think we may send a TGT or ST to the initiator without being aware it can handle them; we could also perform capability negotiation and confirm that the initiator can deal with a TGT or ST before sending it. The capability option is desirable if we want a different protocol. In the case of the TGT there is no particular reason to generate a TGT unless the initiator has Kerberos and can consume it. In the case of the ST, it is often very useful to generate the ST and hand the ST to the RP even if the initiator will never see the ST and wouldn't know what to do with an ST if it had one. Talking through this with Josh ye.yesterday I've realized I am making lots of assumptions about model and use that I have documented no-where. If you can wait a couple of days I'll write up my model and what I've learned of the constraint space. --Sam From Josh.Howlett@ja.net Sat Sep 10 07:01:34 2011 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 21BC621F84DB for ; Sat, 10 Sep 2011 07:01:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.766 X-Spam-Level: X-Spam-Status: No, score=-102.766 tagged_above=-999 required=5 tests=[AWL=-0.167, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O48KiubCPXqT for ; Sat, 10 Sep 2011 07:01:33 -0700 (PDT) Received: from har003676.ukerna.ac.uk (har003676.ukerna.ac.uk [194.82.140.75]) by ietfa.amsl.com (Postfix) with ESMTP id 6B70121F84D9 for ; Sat, 10 Sep 2011 07:01:33 -0700 (PDT) Received: from har003676.ukerna.ac.uk (localhost.localdomain [127.0.0.1]) by localhost (Email Security Appliance) with SMTP id 25B644A6B6B_E6B6E32B for ; Sat, 10 Sep 2011 14:03:30 +0000 (GMT) Received: from EXC001.atlas.ukerna.ac.uk (exc001.atlas.ukerna.ac.uk [193.62.83.37]) by har003676.ukerna.ac.uk (Sophos Email Appliance) with ESMTP id E3B674A6B63_E6B6E31F for ; Sat, 10 Sep 2011 14:03:29 +0000 (GMT) Received: from EXC001.atlas.ukerna.ac.uk ([193.62.83.37]) by EXC001 ([193.62.83.37]) with mapi id 14.01.0289.001; Sat, 10 Sep 2011 15:03:12 +0100 From: Josh Howlett To: "abfab@ietf.org" Thread-Topic: I-D Action: draft-dekok-radext-nai-01.txt Thread-Index: AQHMb8AbIajGvi2BiUiiz6Kf0WX8W5VGpT4A Date: Sat, 10 Sep 2011 14:03:11 +0000 Message-ID: In-Reply-To: <20110910134336.22356.13484.idtracker@ietfa.amsl.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.12.0.110505 x-originating-ip: [194.82.140.76] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [abfab] FW: I-D Action: draft-dekok-radext-nai-01.txt X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Sep 2011 14:01:34 -0000 FYI - proposed revision to RFC 4282. On 10/09/2011 14:43, "internet-drafts@ietf.org" wrote: >A New Internet-Draft is available from the on-line Internet-Drafts >directories. > > Title : The Network Access Identifier > Author(s) : Alan DeKok > Filename : draft-dekok-radext-nai-01.txt > Pages : 19 > Date : 2011-09-10 > > In order to provide roaming services, it is necessary to have a > standardized method for identifying users. This document defines the > syntax for the Network Access Identifier (NAI), the user identity > submitted by the client during network authentication. >"Roaming" may > be loosely defined as the ability to use any one of multiple Internet > Service Providers (ISPs), while maintaining a formal, customer-vendor > relationship with only one. Examples of where roaming capabilities > might be required include ISP "confederations" and >ISP-provided > corporate network access support. This document is a revised version > of RFC 4282 [RFC4282], which addresses issues with international > character sets, as well as a number of other corrections to the > previous document. > > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-dekok-radext-nai-01.txt > >Internet-Drafts are also available by anonymous FTP at: >ftp://ftp.ietf.org/internet-drafts/ > >This Internet-Draft can be retrieved at: >ftp://ftp.ietf.org/internet-drafts/draft-dekok-radext-nai-01.txt >_______________________________________________ >I-D-Announce mailing list >I-D-Announce@ietf.org >https://www.ietf.org/mailman/listinfo/i-d-announce >Internet-Draft directories: http://www.ietf.org/shadow.html >or ftp://ftp.ietf.org/ietf/1shadow-sites.txt 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 Oxford, Didcot, Oxfordshire. OX11 0SG From rafa@um.es Mon Sep 12 01:04:53 2011 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D1E621F87F0 for ; Mon, 12 Sep 2011 01:04:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.979 X-Spam-Level: X-Spam-Status: No, score=-2.979 tagged_above=-999 required=5 tests=[AWL=-0.980, BAYES_00=-2.599, J_CHICKENPOX_29=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vHpT2e-lNeV3 for ; Mon, 12 Sep 2011 01:04:53 -0700 (PDT) Received: from xenon12.um.es (xenon12.um.es [155.54.212.166]) by ietfa.amsl.com (Postfix) with ESMTP id 9891521F86EE for ; Mon, 12 Sep 2011 01:04:51 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by xenon12.um.es (Postfix) with ESMTP id 1150E4BCDC; Mon, 12 Sep 2011 10:06:52 +0200 (CEST) X-Virus-Scanned: by antispam in UMU at xenon12.um.es Received: from xenon12.um.es ([127.0.0.1]) by localhost (xenon12.um.es [127.0.0.1]) (amavisd-new, port 10024) with LMTP id JBTqwLzJ5J05; Mon, 12 Sep 2011 10:06:51 +0200 (CEST) Received: from inf-205-200.inf.um.es (inf-205-200.inf.um.es [155.54.205.200]) (Authenticated sender: rafa) by xenon12.um.es (Postfix) with ESMTPA id 72A9D4BCB9; Mon, 12 Sep 2011 10:06:47 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: Rafa Marin Lopez In-Reply-To: Date: Mon, 12 Sep 2011 10:06:47 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <10307ADF-9193-4E3F-B145-C5FBD8AC0E08@um.es> <5DAD8828-CF12-4A1D-8699-1ED02EDF0377@um.es> <71B4B2D0-F81E-4935-921D-81961E047AC6@um.es> To: Sam Hartman X-Mailer: Apple Mail (2.1084) Cc: abfab@ietf.org Subject: Re: [abfab] GSS-Preauth and decoupling for GSS-EAP X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Sep 2011 08:04:53 -0000 Hi Sam: El 09/09/2011, a las 14:58, Sam Hartman escribi=F3: >>>>>> "Rafa" =3D=3D Rafa Marin Lopez writes: >=20 > Rafa> Hi Sam: >>>=20 >>> May we assume that TGT will be involved in a Kerberos exchange >>> later on?. I mean I think that TGT will have to be provided to >>> the initiator somehow ( within GSS-EAP exchange? ) >>>=20 >>> I assume that initiator will have some Kerberos source code >>> implemented to handle the TGT and to request service >>> tickets. Otherwise, having a TGT is useless as you mention. >>>=20 >>> I don't think these are reasonable assumptions. >=20 > Rafa> Well, if we send a TGT or ST to the initiator, it would seem > Rafa> reasonable to me that initiator knows how to handle it. But > Rafa> maybe it is not reasonable. >=20 > I agree that if the initiator is going to use a TGT or ST then it's = fine > to assume it has code to deal with one. I think we may send a TGT or = ST > to the initiator without being aware it can handle them; we could also > perform capability negotiation and confirm that the initiator can deal > with a TGT or ST before sending it. The capability option is desirable > if we want a different protocol. That makes sense to me. >=20 > In the case of the TGT there is no particular reason to generate a TGT > unless the initiator has Kerberos and can consume it. Right.=20 >=20 > In the case of the ST, it is often very useful to generate the ST and > hand the ST to the RP even if the initiator will never see the ST and > wouldn't know what to do with an ST if it had one. >=20 > Talking through this with Josh ye.yesterday I've realized I am making > lots of assumptions about model and use that I have documented = no-where. > If you can wait a couple of days I'll write up my model and what I've > learned of the constraint space. Yes, that would be really appreciated. Thanks. Best regards. >=20 > --Sam ------------------------------------------------------- Rafael Marin Lopez, PhD Dept. Information and Communications Engineering (DIIC) Faculty of Computer Science-University of Murcia 30100 Murcia - Spain Telf: +34868888501 Fax: +34868884151 e-mail: rafa@um.es ------------------------------------------------------- From nico@cryptonector.com Mon Sep 12 07:48:29 2011 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6025821F8B58 for ; Mon, 12 Sep 2011 07:48:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.661 X-Spam-Level: X-Spam-Status: No, score=-2.661 tagged_above=-999 required=5 tests=[AWL=-0.684, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3WhDJszHZp8D for ; Mon, 12 Sep 2011 07:48:28 -0700 (PDT) Received: from homiemail-a29.g.dreamhost.com (caiajhbdcaid.dreamhost.com [208.97.132.83]) by ietfa.amsl.com (Postfix) with ESMTP id C768221F8B50 for ; Mon, 12 Sep 2011 07:48:28 -0700 (PDT) Received: from homiemail-a29.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a29.g.dreamhost.com (Postfix) with ESMTP id 2E8DC5C8003 for ; Mon, 12 Sep 2011 07:50:32 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc :content-type:content-transfer-encoding; q=dns; s= cryptonector.com; b=DgDgyDiGDYTRIcaseIw063bvvEB6YRNsD8jv0AxaU9wz KECxzalZjyQkLIIqaei3qtUWzYu7eHVIe/Z7Cx7JHtmPdHOOblRqkFay/Bt53URi /D6sbNNNS2gBtN2BmbrFW/r2ixuBaI9kHMACSELw9BQsxzRirCfl+46fHnfHEf8= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type:content-transfer-encoding; s= cryptonector.com; bh=ZFFUmEyXz1RJmgOnXkBjU3liX0Y=; b=s/wv3GNiwBj 9/Kw6s/u8TfxJiq8ihYbg1XRY22l662e+D2hpM4iazopsJvNu1VOEEmVW9b4HyAR HCYzvbwKkGoav4sVyk5Vk66SdCQp3tKMzywj+bTT7AZTIebjx9wVzEivN4ZrfuYp tly4G1sv4dRZsvM8JMeHKQSK3GNwqnJg= Received: from mail-pz0-f45.google.com (mail-pz0-f45.google.com [209.85.210.45]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a29.g.dreamhost.com (Postfix) with ESMTPSA id DBD015C800B for ; Mon, 12 Sep 2011 07:50:19 -0700 (PDT) Received: by pzk33 with SMTP id 33so23967295pzk.18 for ; Mon, 12 Sep 2011 07:50:19 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.33.164 with SMTP id s4mr4332274pbi.265.1315839019221; Mon, 12 Sep 2011 07:50:19 -0700 (PDT) Received: by 10.68.66.163 with HTTP; Mon, 12 Sep 2011 07:50:19 -0700 (PDT) In-Reply-To: References: <10307ADF-9193-4E3F-B145-C5FBD8AC0E08@um.es> <5DAD8828-CF12-4A1D-8699-1ED02EDF0377@um.es> <71B4B2D0-F81E-4935-921D-81961E047AC6@um.es> Date: Mon, 12 Sep 2011 09:50:19 -0500 Message-ID: From: Nico Williams To: Sam Hartman Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: abfab@ietf.org Subject: Re: [abfab] GSS-Preauth and decoupling for GSS-EAP X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Sep 2011 14:48:29 -0000 On Fri, Sep 9, 2011 at 7:58 AM, Sam Hartman wrote: > =C2=A0 =C2=A0Rafa> Well, if we send a TGT or ST to the initiator, it woul= d seem > =C2=A0 =C2=A0Rafa> reasonable to me that initiator knows how to handle it= . But > =C2=A0 =C2=A0Rafa> maybe it is not reasonable. > > I agree that if the initiator is going to use a TGT or ST then it's fine > to assume it has code to deal with one. =C2=A0I think we may send a TGT o= r ST > to the initiator without being aware it can handle them; we could also > perform capability negotiation and confirm that the initiator can deal > with a TGT or ST before sending it. The capability option is desirable > if we want a different protocol. You could just send it, in a wrap token embedded in a GSS-EAP context token. If the client can't use it, it won't, and that's that. Of course, this is wasteful of resources, particularly if the client does lots of GSS-EAP exchanges and doesn't grok Kerberos. So, yeah, this should be negotiated. (Awful, ugly thought: one might also allow for credential delegation whereby the acceptor gets a TGT and session key from the KDC through which to impersonate the initiator. How would the KDC learn that the initiator is willing to delegate credentials thus?) > In the case of the ST, it is often very useful to generate the ST and > hand the ST to the RP even if the initiator will never see the ST and > wouldn't know what to do with an ST if it had one. Why is this useful? A service ticket delivers a few features: a) the initiator principal's Kerberos principal name, b) any authz-data the KDC might want to put in the ST (though presumably GSS-EAP could deliver the same data as SAML, no?), c) the KDC signature on the ST, which enables S4U*. I think this is useful enough, but we should be careful to not make a KDC infrastructure a requirement for using GSS-EAP. Nico -- From klaas@cisco.com Tue Sep 13 07:23:08 2011 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A8EF621F8AB9 for ; Tue, 13 Sep 2011 07:23:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cQnvPipJKLqp for ; Tue, 13 Sep 2011 07:22:55 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id B8EB921F8AB0 for ; Tue, 13 Sep 2011 07:22:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=klaas@cisco.com; l=473; q=dns/txt; s=iport; t=1315923900; x=1317133500; h=from:content-transfer-encoding:subject:date:message-id: to:mime-version; bh=m/DTrgT20/mcFg+0Mc0SDU/SriLVfw7Ckret6Eq7EeU=; b=I0/HYTnhg+pIDOtsLGlATJPvVpxmHg66F4J3t+vkX+g5QfDVT0pAxp6o QJLhG/O7CKfG5F+V9zPz6nngdxProGDz5tapLFGy9i/1fF+bagE1BN21F L7UFZ9XjXAsipn5dDg3YXRj43gZnXGdvtMkmwL1qmk6zcS7o9z9cBIUTh Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AosHAPNmb06tJV2Z/2dsb2JhbABDmR2OS3iBbAFbgX6fPoEmAZ48hg5gBJM9kSQ X-IronPort-AV: E=Sophos;i="4.68,374,1312156800"; d="scan'208";a="21117637" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-9.cisco.com with ESMTP; 13 Sep 2011 14:24:59 +0000 Received: from rtp-kwiereng-8714.cisco.com (rtp-kwiereng-8714.cisco.com [10.116.7.37]) by rcdn-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p8DEOwd7032497 for ; Tue, 13 Sep 2011 14:24:59 GMT From: Klaas Wierenga Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Date: Tue, 13 Sep 2011 16:24:58 +0200 Message-Id: <2FEE7028-03C9-4058-A947-6BF410AC3FC5@cisco.com> To: abfab@ietf.org Mime-Version: 1.0 (Apple Message framework v1244.3) X-Mailer: Apple Mail (2.1244.3) Subject: [abfab] abfab@IETF82? X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Sep 2011 14:23:08 -0000 Hi all, As Leif pointed out before, it is awfully quiet on the abfab mailing = list. Of course, that may be because you are all extremely busy = reviewing and updating abfab drafts=85. But before we request a time = slot it would be good to get a feel for who plans to be in Taipei and/or = who wants to present something. Therefore, please respond before the end = of the next week if you think you want a presentation slot in Taipei! Cheers, Klaas & Leif= From alexey.melnikov@isode.com Sun Sep 18 01:31:13 2011 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85D7321F8512 for ; Sun, 18 Sep 2011 01:31:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.228 X-Spam-Level: X-Spam-Status: No, score=-102.228 tagged_above=-999 required=5 tests=[AWL=-0.229, BAYES_00=-2.599, J_CHICKENPOX_81=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 44UzWYJlYf8U for ; Sun, 18 Sep 2011 01:31:12 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by ietfa.amsl.com (Postfix) with ESMTP id 57D6E21F850B for ; Sun, 18 Sep 2011 01:31:12 -0700 (PDT) Received: from [188.28.131.98] (188.28.131.98.threembb.co.uk [188.28.131.98]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Sun, 18 Sep 2011 09:33:30 +0100 Message-ID: <4E75ACD5.5000104@isode.com> Date: Sun, 18 Sep 2011 09:33:25 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: abfab@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [abfab] Comments on draft-ietf-abfab-gss-eap-02.txt X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Sep 2011 08:31:13 -0000 My general feeling is that the document is close to being done, modulo some XXX-style comments in several places. Some specific comments (mostly nits) below. General comment: the document is using terminology for multiple technologies (EAP, GSS-API and even SASL). While I think the document is correct and it explains most of the terms used, some additional references on first use would be very helpful in order to improve readability. In particular I am thinking about Section 1 and its subsections, e.g. Section 1.2. In Section 1, 5th paragraph: The goal of this specification is to combine GSS-API's support for application protocols with EAP/AAA's support for common credential types and for authenticating to a server without requiring that server to specifically support the authentication method in use. In addition, this specification supports thearchitecture goal of Missing space, should be "the architecture". transporting attributes about subjects to relying parties. Together this combination will provide federated authentication and authorisation for GSS-API applications. 3. EAP Channel Binding and Naming EAP authenticates a realm. The whole realm? I thought a realm is a collection of user and service accounts. The peer knows that it has exchanged authentication with an EAP server in a given realm. 3.1. Mechanism Name Format The string representation of the GSS-EAP mechanism name has the following ABNF [RFC5234] representation: ; Define name-string to handle escaping and prevent / and @ I was about to ask where is it defined. empty = This is going to fail ABNF validation. Use something like 0"blah". user-or-service = name-string host = empty/name-string Can host really be empty? If yes, this can result in the following name: user-or-service "/" "@" realm Is it going to be valid? If not, you might be missing an extra pair of [] in the definition of below: realm = name-string service-specific = name-string service-specifics = service-specific 0*('/' service-specifics) name = user-or-service '/' host [ '/' service-specifics] [ '@' realm ] Also change a single quote to double quote, otherwise this is not a correct ABNF. The user-or-service component is the portion of a network access identifier (NAI) before the '@' symbol for initiator names NAI syntax needs a reference. and the service name from the registry of GSS-API host-based services in the case of acceptor names [GSS-IANA]. If the null name type or the GSS_EAP_NT_EAP_NAME (oid XXX) is Yes, this needs to be defined :-). imported, then the string representation above should be directly imported. Mechanisms MAY support the GSS_KRB5_NT_KRB5_PRINCIPAL_NAME name form with the OID {iso(1) member-body(2) United States(840) mit(113554) infosys(1) gssapi(2) krb5(2) krb5_name(1)}. 3.4. Proxy Verification of Acceptor Name This section is empty. 5.1. Mechanisms and Encryption Types This mechanism family uses the security services of the Kerberos cryptographic framework [RFC3961]. As such, a particular encryption type needs to be chosen. By convention, there is a single object identifier arc for the EAP family of GSS-API mechanisms. A specific mechanism is chosen by adding the numeric Kerberos encryption type number to the root of this arc. However, in order to register the SASL name, the specific usage with a given encryption type needs to be registered. This document defines the eap-aes128-cts-hmac-sha1-96 GSS-API mechanism. XXX define an OID for that and use the right language to get that into the appropriate SASL registry. Yes :-). 5.2. Processing received tokens Implementations of this mechanism maintain a state machine for the context establishment process. Both the initiator and acceptor start out in the initial state; see Section 5.4 for a description of this state. Associated with each state are a set of subtoken types that are processed in that state and rules for processing these subtoken types. The reciever examines the subtokens in order, processing any that are appropriate for the current state. What happens to the subtokens which are not appropriate for the current state? 5.4.2. Acceptor Name Request The acceptor name request token is sent from the initiator to the acceptor indicating that the initiator wishes a particular acceptor name. This is similar to TLS Server Name Indication. This needs an Informative Reference. In Section 5.5: o If the acceptor receives an EAP failure, then the acceptor sends this in the Eap Request subtoken type. If the initiator receives an EAP Failure, it returns GSS failure. Can you expand on what you mean here. "receive" doesn't mean receive over the wire here, right? Also, what does it mean to return a "GSS failure"? 5.6.2. Channel Bindings Subtoken Again, only the application data is sent in the channel binding. The initiator and acceptor addresses are ignored. I am not entirely clear on what you mean here by "addresses are ignored". In 5.6.3: The input to GSS_GetMIC is as follows: 1. The DER-encoded object identifier of the mechanism in use; this value starts with 0x06 (the tag for object identifier). When encoded in an RFC 2743 context token, the object identifier is preceeded by the tag and length for [Application 0] SEQUENCE. This tag and the length of the overall token is not inclded; only the tag, length and value of the object identifier itself. 2. A 16-bit token type in network byte order of the RFC 4121 token identifier (0x0601 for initiator, 0x0602 for acceptor). 3. For each subtoken other than the MIC subtoken itself: What is the order of subtokens? Does this cover all subtokens sent during the extension phase? Does this cover only subtokens sent by the initiator/acceptor respectively? 1. A four octet subtoken type in network byte order 2. A four byte length in network byte order 3. Length octets of value from that subtoken 6. Acceptor Services The CRK is derived from the GMSK using the following procedur Typo: procedure Tn = pseudo-random(KMSK, n || "rfc4121-gss-eap") How is "n" respresented, in particular how many bytes are used to represent it? CRK = truncate(L, T1 || T2 || .. || Tn) L = output RFC 3961 key size In Section 6.1: In this mechanism an extension option of type 0 with the critical bit I am a bit confused here: what is "an extension option". set is sent from the initiator to the acceptor. This option contains a GSS_Wrap token of the channel binding data passed into GSS_Init_sec_context. 8.1. RFC 4121 Token Identifiers A new top level registry titled "Kerberos GSS-API Mechanism Parameters," should be created. This registry should be separate from the existing "Kerberos Parameters" registry. In this registry is a subregistry called "Kerberos GSS-API Token Identifiers"; the overall reference for this subregistry is section 4.1 of RFC 4121. What is the IANA registration procedure here? 8.4. GSS EAP Errors A new subregistry is created in the GSS EAP parameters registry titled "Error Codes". XXX fill in minor statuses. What is the IANA registration procedure here? From hartmans@painless-security.com Fri Sep 23 06:55:54 2011 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E29521F8C32 for ; Fri, 23 Sep 2011 06:55:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.944 X-Spam-Level: X-Spam-Status: No, score=-0.944 tagged_above=-999 required=5 tests=[AWL=-1.093, BAYES_40=-0.185, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yzGkC04BVpwV for ; Fri, 23 Sep 2011 06:55:54 -0700 (PDT) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id 23F9621F8C72 for ; Fri, 23 Sep 2011 06:55:53 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id 8581A20424; Fri, 23 Sep 2011 10:00:11 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 9E2224234; Fri, 23 Sep 2011 09:58:05 -0400 (EDT) From: Sam Hartman To: Leif Johansson References: <4E6481BE.3060706@mnt.se> Date: Fri, 23 Sep 2011 09:58:05 -0400 In-Reply-To: <4E6481BE.3060706@mnt.se> (Leif Johansson's message of "Mon, 05 Sep 2011 10:01:02 +0200") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: "abfab@ietf.org" Subject: Re: [abfab] progress X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Sep 2011 13:55:54 -0000 I think it would be helpful to have an on-list discussion about what's needed for various documents. I'll be happy to start something for aaa-saml, architecture, gss-eap and gss-eap-naming. Any chance the chairs could comment or recruit comments on applicability? From hartmans@painless-security.com Fri Sep 23 07:03:43 2011 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5986121F8C8E for ; Fri, 23 Sep 2011 07:03:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.104 X-Spam-Level: X-Spam-Status: No, score=-2.104 tagged_above=-999 required=5 tests=[AWL=0.161, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vFd6v62DLGjB for ; Fri, 23 Sep 2011 07:03:42 -0700 (PDT) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id CAE4121F8C8C for ; Fri, 23 Sep 2011 07:03:42 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id A428820576 for ; Fri, 23 Sep 2011 10:08:00 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id ABC514234; Fri, 23 Sep 2011 10:05:54 -0400 (EDT) From: Sam Hartman To: abfab@ietf.org Date: Fri, 23 Sep 2011 10:05:54 -0400 Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [abfab] Core documents: where we are X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Sep 2011 14:03:43 -0000 Hi. I'd like to give my take on the core documents and where I think we are in the hopes of soliciting feedback. Architecture: We have an initial version out. We've received a lot of feedback from Jim and some from Alexey that we need to integrate. We need to write a security considerations section and we need to write sections on proxy behavior. In my opinion, it's more important to focus on the technical specs at this point than the architecture document. We definitely should have some update by IETF 82 to make forward prograss, but I don't think it is critical that it be complete. In effect I'm arguing that the initial order of our milestones is wrong and that we want to conclude core specs before architecture. * gss-eap: I think this is complete enough that we can get significant review. There are some open ends: * Actually including an OID from the OID registry * Including the error codes that you might want to return * Including a sample token * Some figures might be nice. If people write figures I'll include them:-) But I believe the protocol is well specified enough to have an informed discussion. * aaa-saml. we've had several discussions of this. We need to specify more semantics to address issues Jim and I have raised.. We have a description of the attribute. We need to turn that into descriptions of the semantics of the attribute. In effect it needs to be more of a SAML binding. The fact that this is not written down is hurting us and this doc should be a real priority. * gss-eap-naming: This document needs and will get a major update. It needs to reflect changes in naming extensions. When this document was written it was as much an argument that naming extensions was broken as it was a description of how to do things in GSS-EAP. Never the less we've gotten significant feedback from Jim and I think we'll be in very good shape for review once this feedback is integrated into the document. --Sam From leifj@mnt.se Fri Sep 23 07:04:24 2011 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 27C3321F8C90 for ; Fri, 23 Sep 2011 07:04:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.313 X-Spam-Level: X-Spam-Status: No, score=-3.313 tagged_above=-999 required=5 tests=[AWL=-0.714, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id giKEzB4-b-XP for ; Fri, 23 Sep 2011 07:04:23 -0700 (PDT) Received: from backup-server.nordu.net (backup-server.nordu.net [IPv6:2001:948:4:1::66]) by ietfa.amsl.com (Postfix) with ESMTP id 2AEAA21F8C8C for ; Fri, 23 Sep 2011 07:04:22 -0700 (PDT) Received: from [192.36.125.212] (dhcp.pilsnet.sunet.se [192.36.125.212]) (authenticated bits=0) by backup-server.nordu.net (8.14.3/8.14.3) with ESMTP id p8NE6qoF004522 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 23 Sep 2011 16:06:55 +0200 (CEST) Message-ID: <4E7C927C.2060002@mnt.se> Date: Fri, 23 Sep 2011 16:06:52 +0200 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.21) Gecko/20110831 Lightning/1.0b2 Thunderbird/3.1.13 MIME-Version: 1.0 To: Sam Hartman References: <4E6481BE.3060706@mnt.se> In-Reply-To: X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "abfab@ietf.org" Subject: Re: [abfab] progress X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Sep 2011 14:04:24 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 09/23/2011 03:58 PM, Sam Hartman wrote: > I think it would be helpful to have an on-list discussion about what's > needed for various documents. > I'll be happy to start something for aaa-saml, architecture, gss-eap and > gss-eap-naming. > Any chance the chairs could comment or recruit comments on > applicability? Why not just have the editors update the various documents and solicit review and comment like we normally do in the IETF? The chairs are busy pinging people in the background to fulfill their commitments from the last IETF to review and comment but I suspect an update of aaa-saml, gss-eap and gss-eap-naming might speed things along assuming there are resolved issues that can be reflected in a new version. Cheers Leif -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk58knsACgkQ8Jx8FtbMZndqegCggqJwaEXDMT58ttbW65uOD4bI AVIAoIfU5wnEvlowA40qbI9mnImsKKaY =UmBG -----END PGP SIGNATURE----- From hartmans@mit.edu Fri Sep 23 07:09:32 2011 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8AE7621F8CA6 for ; Fri, 23 Sep 2011 07:09:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.43 X-Spam-Level: X-Spam-Status: No, score=-103.43 tagged_above=-999 required=5 tests=[AWL=-1.165, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qQxztOVo5rMo for ; Fri, 23 Sep 2011 07:09:31 -0700 (PDT) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id 9563E21F8BF7 for ; Fri, 23 Sep 2011 07:09:31 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id 6817E20576 for ; Fri, 23 Sep 2011 10:13:49 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 7D6CB4234; Fri, 23 Sep 2011 10:11:43 -0400 (EDT) From: Sam Hartman To: abfab@ietf.org Date: Fri, 23 Sep 2011 10:11:43 -0400 Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" Subject: [abfab] [Sam Hartman] [Ietf-krb-wg] Comments on adopting draft-perez-krb-wg-gss-preauth-00.txt X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Sep 2011 14:09:32 -0000 --=-=-= Folks, the following call for adoption currently open in the Kerberos working group may interest people here. Please send comments to the Kerberos working group. --Sam --=-=-= Content-Type: message/rfc822 Content-Disposition: inline Return-Path: Received: from localhost ([unix socket]) by mail.suchdamage.org (Cyrus v2.2.13-Debian-2.2.13-10) with LMTPA; Wed, 14 Sep 2011 11:03:04 -0400 X-Sieve: CMU Sieve 2.2 Received: from dmz-mailsec-scanner-4.mit.edu (DMZ-MAILSEC-SCANNER-4.MIT.EDU [18.9.25.15]) by mail.suchdamage.org (Postfix) with ESMTP id 3CA94202FB for ; Wed, 14 Sep 2011 11:03:02 -0400 (EDT) Received: from mailhub-dmz-1.mit.edu ( [18.9.21.41]) by dmz-mailsec-scanner-4.mit.edu (Symantec Messaging Gateway) with SMTP id 83.E4.02596.811C07E4; Wed, 14 Sep 2011 10:58:32 -0400 (EDT) Received: from dmz-mailsec-scanner-7.mit.edu (DMZ-MAILSEC-SCANNER-7.MIT.EDU [18.7.68.36]) by mailhub-dmz-1.mit.edu (8.13.8/8.9.2) with ESMTP id p8EF18W8009696; Wed, 14 Sep 2011 11:01:08 -0400 X-AuditID: 1209190f-b7b44ae000000a24-a0-4e70c118f57e Authentication-Results: symauth.service.identifier Received: from mailhost.anl.gov (mailhost.anl.gov [130.202.113.50]) by dmz-mailsec-scanner-7.mit.edu (Symantec Messaging Gateway) with SMTP id F6.4B.02565.1F1C07E4; Wed, 14 Sep 2011 11:02:10 -0400 (EDT) Received: from mailhost.anl.gov (mailhost.anl.gov [130.202.113.50]) by localhost.anl.gov (Postfix) with ESMTP id 585184A; Wed, 14 Sep 2011 10:01:07 -0500 (CDT) Received: from lists.anl.gov (katydid.it.anl.gov [146.137.96.32]) by mailhost.anl.gov (Postfix) with ESMTP id 10BD12B; Wed, 14 Sep 2011 10:01:07 -0500 (CDT) Received: from katydid.it.anl.gov (localhost [127.0.0.1]) by lists.anl.gov (Postfix) with ESMTP id E94A280ECA; Wed, 14 Sep 2011 10:01:06 -0500 (CDT) X-Original-To: ietf-krb-wg@lists.anl.gov Delivered-To: ietf-krb-wg@lists.anl.gov Received: from mailhost.anl.gov (mailhost.anl.gov [130.202.113.50]) by lists.anl.gov (Postfix) with ESMTP id CF2DF80ECA for ; Wed, 14 Sep 2011 10:01:05 -0500 (CDT) Received: by mailhost.anl.gov (Postfix) id C730634; Wed, 14 Sep 2011 10:01:05 -0500 (CDT) Delivered-To: ietf-krb-wg@anl.gov Received: from mailhost.anl.gov (mailhost.anl.gov [130.202.113.50]) by localhost.anl.gov (Postfix) with ESMTP id C24C82B for ; Wed, 14 Sep 2011 10:01:05 -0500 (CDT) Received: from mailrelay.anl.gov (mailrelay.anl.gov [130.202.101.22]) by mailhost.anl.gov (Postfix) with ESMTP id BBC5834 for ; Wed, 14 Sep 2011 10:01:05 -0500 (CDT) Received: from localhost (localhost [127.0.0.1]) by localhost.it.anl.gov (Postfix) with ESMTP id 9AA057CC067; Wed, 14 Sep 2011 10:01:05 -0500 (CDT) Received: from mailrelay.anl.gov ([127.0.0.1]) by localhost (mailrelay.anl.gov [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 30300-01-10; Wed, 14 Sep 2011 10:01:05 -0500 (CDT) Received: from mailgateway.anl.gov (mailgateway.anl.gov [130.202.101.28]) by mailrelay.anl.gov (Postfix) with ESMTP id 6AF997CC076 for ; Wed, 14 Sep 2011 10:01:05 -0500 (CDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiwFAEfBcE5FGcQcgWdsb2JhbABBmS+OTAEBFiYmgUxIezQBBBiePZZjiH+GbgSlAA X-IronPort-AV: E=Sophos;i="4.68,380,1312174800"; d="scan'208";a="66718902" Received: from permutation-city.suchdamage.org (HELO mail.suchdamage.org) ([69.25.196.28]) by mailgateway.anl.gov with ESMTP; 14 Sep 2011 10:00:54 -0500 Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id AEF66202FB for ; Wed, 14 Sep 2011 11:02:47 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 3959442B7; Wed, 14 Sep 2011 11:00:51 -0400 (EDT) From: Sam Hartman To: ietf-krb-wg@anl.gov Date: Wed, 14 Sep 2011 11:00:51 -0400 Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) X-Virus-Scanned: Debian amavisd-new at frigga.it.anl.gov Subject: [Ietf-krb-wg] Comments on adopting draft-perez-krb-wg-gss-preauth-00.txt X-BeenThere: ietf-krb-wg@lists.anl.gov X-Mailman-Version: 2.1.14 Precedence: list List-Id: "This is a list for the IETF Kerberos Working Group. {WORLDPUB, EXTERNAL}" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ietf-krb-wg-bounces@lists.anl.gov Sender: ietf-krb-wg-bounces@lists.anl.gov X-Brightmail-Tracker: H4sIAAAAAAAAA01TbUhTURjm7N5td8Nr16X5NqxwFqmlaQmJffmjwILUflRQkV3drQ22abtq aWVCGVgu+l7pkmUf4kzFynKalqsIUyM0C/qiD0kdlWUtrGh17860/j3PeZ73Oe97eA9FqGpl akpvyuXMJtagkSlJlSIkKgY6clLj3tZFJdb+6Zcm1hxrlid6DryWJRMpzvKX8pRqz2sypeZk lzyd2KBcrOUM+nzOPG/pFqWuyV4jzXGSO63HO4li9Jw4iBQUMAnwrbRMhvEUePSqQcBKSsW0 IbhfdRlhcgeBxVEtG684VT7oq0bMfGh96JZiUzeCusejBCbnEfQeGSAxsSN40n7Vn3Uawb0B rwRnRULXiVEkYpKZDT2Op6SIVYwLgc2yCeONcLHtixR7wsE5/IGc6PDO2H4Cm9oRDO3LxIIV wV273e9qQfC7fr9/qPsIGi3n/XNEQH2jV45xBjS86CMxXgU9Xod/DBuCwcNjEkyeSuD20C+E LyyCiq+fhGqKkjFR0PI+UjwOZkKh7KdHjpudBeeenPL1RwvY8WPQZw9hlkFJnRIfB0HnmQHy CIor/4+KmGDmgr11VIbxDLjx0UbYEeFA07TGwhgjqzfwXFYMn8WaTJw5JiHWqM+N5bR5V5Bv TaZOakbfOzQuxFBIE0DX7MpOVUnZfL7A6EJTKYkmhI4WtkgVmJmtLdCxvC7DnGfgeOHRKUIT TE/fLWi0li0o5MzZ49JsimKsY8Pr1KQp28RpgK5tElxBZm4bt3Or3iAs6bhTQinEpAAh6dpt MYnPYY28fhvWH6BwdSjtEQVGFHR5pona8R13o1Ch78m0uOqqAOEHTFS7hWCJEBxR4QvOZf9J 6mIUdnbIUtKXtrfxVtFyhyUzK3zJWn1H6fLI4Kqm5GbFyKxFRfmD6Ue9c6xrAiNL4g+kxr86 FMQzpqRfbjpv5p6VR29Oq3y2vptwh/VKXZud+h/R1WkXkpa+eNe9YMn2Bpvyc1LXG7vxi7yy n/u54uLCkeTSpIjrto87nJcs1tWf970Z0ZC8jo2PJsw8+xewU6LHvgMAAA== X-DSPAM-Result: Whitelisted X-DSPAM-Processed: Wed Sep 14 11:03:04 2011 X-DSPAM-Confidence: 0.9996 X-DSPAM-Probability: 0.0000 X-DSPAM-Signature: 8042,4e70c22819272080416527 X-DSPAM-Factors: 27, From*Sam Hartman , 0.00010, List-Help*request, 0.00010, List-Post* X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77E9021F8C6A for ; Fri, 23 Sep 2011 07:12:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xD3f2nfBJOjM for ; Fri, 23 Sep 2011 07:12:33 -0700 (PDT) Received: from backup-server.nordu.net (backup-server.nordu.net [IPv6:2001:948:4:1::66]) by ietfa.amsl.com (Postfix) with ESMTP id 7CFCC21F8C53 for ; Fri, 23 Sep 2011 07:12:33 -0700 (PDT) Received: from [192.36.125.212] (dhcp.pilsnet.sunet.se [192.36.125.212]) (authenticated bits=0) by backup-server.nordu.net (8.14.3/8.14.3) with ESMTP id p8NEF4P3006226 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 23 Sep 2011 16:15:07 +0200 (CEST) Message-ID: <4E7C9468.9090505@sunet.se> Date: Fri, 23 Sep 2011 16:15:04 +0200 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.21) Gecko/20110831 Lightning/1.0b2 Thunderbird/3.1.13 MIME-Version: 1.0 To: abfab@ietf.org References: In-Reply-To: X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [abfab] Core documents: where we are X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Sep 2011 14:12:34 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > In my opinion, it's more important to focus on the technical specs at > this point than the architecture document. We definitely should have This was already discussed in Quebec and the WG concluded that were fine with Elliot putting the architecture document on the back-burner for a little while while the core technical spec was moved ahead. I don't think we need to re-iterate that decision. > some update by IETF 82 to make forward prograss, but I don't think it is > critical that it be complete. In effect I'm arguing that the initial > order of our milestones is wrong and that we want to conclude core specs > before architecture. Yes. cf above. Cheers Leif -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk58lGgACgkQ8Jx8FtbMZnd8ZQCgp491JhYednEnz0vTmgH1dDd9 TCwAniv9Y2/6pEH1tWwmUBOoEC3MFQGt =v+DN -----END PGP SIGNATURE----- From leifj@mnt.se Fri Sep 23 07:18:36 2011 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2DAF21F8CC0 for ; Fri, 23 Sep 2011 07:18:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.266 X-Spam-Level: X-Spam-Status: No, score=-3.266 tagged_above=-999 required=5 tests=[AWL=-0.667, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rucOtGkvyQjl for ; Fri, 23 Sep 2011 07:18:36 -0700 (PDT) Received: from backup-server.nordu.net (backup-server.nordu.net [IPv6:2001:948:4:1::66]) by ietfa.amsl.com (Postfix) with ESMTP id 1A0B221F8CBD for ; Fri, 23 Sep 2011 07:18:35 -0700 (PDT) Received: from [192.36.125.212] (dhcp.pilsnet.sunet.se [192.36.125.212]) (authenticated bits=0) by backup-server.nordu.net (8.14.3/8.14.3) with ESMTP id p8NEL3No004220 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 23 Sep 2011 16:21:05 +0200 (CEST) Message-ID: <4E7C95CF.4040107@mnt.se> Date: Fri, 23 Sep 2011 16:21:03 +0200 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.21) Gecko/20110831 Lightning/1.0b2 Thunderbird/3.1.13 MIME-Version: 1.0 To: abfab@ietf.org References: In-Reply-To: X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [abfab] Core documents: where we are X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Sep 2011 14:18:37 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > * gss-eap: I think this is complete enough that we can get significant > review. There are some open ends: When do you think you and Josh will have an update on 02 out? > > * aaa-saml. > > we've had several discussions of this. We need to specify more semantics > to address issues Jim and I have raised.. > We have a description of the attribute. > We need to turn that into descriptions of the semantics of the > attribute. In effect it needs to be more of a SAML binding. > The fact that this is not written down is hurting us and this doc should > be a real priority. > The charter has us coordinating this with OASIS since a SAML binding should probably be published there but we don't actually have a stuckee for this job. My hope was to get Scott to do it.... hint hint, nudge nudge... > * gss-eap-naming: > This document needs and will get a major update. When do you think we can expect an updated version? Cheers Leif -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk58lc4ACgkQ8Jx8FtbMZne4NQCfSvFTnmHLh0JTCE1iguZQ48kp VREAnRkDuHQ2SItonhw1AvRKasX3sBaq =mcZH -----END PGP SIGNATURE----- From klaas@cisco.com Fri Sep 23 07:36:17 2011 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 668A021F8CB9 for ; Fri, 23 Sep 2011 07:36:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BTFIG685lL4r for ; Fri, 23 Sep 2011 07:36:16 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id BFFF721F8C8E for ; Fri, 23 Sep 2011 07:36:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=klaas@cisco.com; l=1839; q=dns/txt; s=iport; t=1316788731; x=1317998331; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to; bh=EJwRehIrAnclB6DL8Nd5PRnvZBOnahrV/SGKZRB3NPY=; b=jiiqj/k6/EInayPv9cnQtciqhX/vOziTC7Y6wU9G/PlZr0qiCssxuaSi OMijjtmqireJIR/x3b1LhD3Vf9WULRXfhFyvZcgdtXLILFtnB2+DTb2ZM MP9xxneJ3PGewCFtLG7bvFmg8GfvzR8ai3RYhdY/kxCdXugLA6ynwQ+xR A=; X-Files: signature.asc : 163 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AskFAAuZfE6tJXG8/2dsb2JhbABCpiaBbXiBUwEBAQMBEgFmEAsSBi5JDgY1h1aYUQGeMYYhYASTUpEz X-IronPort-AV: E=Sophos;i="4.68,430,1312156800"; d="asc'?scan'208";a="23581294" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-4.cisco.com with ESMTP; 23 Sep 2011 14:38:51 +0000 Received: from rtp-kwiereng-8714.cisco.com (rtp-kwiereng-8714.cisco.com [10.116.7.37]) by rcdn-core2-1.cisco.com (8.14.3/8.14.3) with ESMTP id p8NEcnqn021748; Fri, 23 Sep 2011 14:38:50 GMT Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: multipart/signed; boundary="Apple-Mail=_D755DB07-765C-42BC-BC6E-AC4A699EDF50"; protocol="application/pgp-signature"; micalg=pgp-sha1 From: Klaas Wierenga In-Reply-To: <4E7C927C.2060002@mnt.se> Date: Fri, 23 Sep 2011 16:38:48 +0200 Message-Id: References: <4E6481BE.3060706@mnt.se> <4E7C927C.2060002@mnt.se> To: Leif Johansson X-Mailer: Apple Mail (2.1244.3) Cc: "abfab@ietf.org" Subject: Re: [abfab] progress X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Sep 2011 14:36:17 -0000 --Apple-Mail=_D755DB07-765C-42BC-BC6E-AC4A699EDF50 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Sep 23, 2011, at 4:06 PM, Leif Johansson wrote: >=20 > Hash: SHA1 >=20 > On 09/23/2011 03:58 PM, Sam Hartman wrote: >> I think it would be helpful to have an on-list discussion about = what's >> needed for various documents. >> I'll be happy to start something for aaa-saml, architecture, gss-eap = and >> gss-eap-naming. >> Any chance the chairs could comment or recruit comments on >> applicability? >=20 > Why not just have the editors update the various documents and solicit > review and comment like we normally do in the IETF? >=20 > The chairs are busy pinging people in the background to fulfill their > commitments from the last IETF to review and comment but I suspect an > update of aaa-saml, gss-eap and gss-eap-naming might speed things = along > assuming there are resolved issues that can be reflected in a new = version. >=20 just to add to this, I have talked to Josh and he promised to bring = forward a new AAA-SAML draft that encompasses the issues Jim and you = raised asap. I expect some lively discussion on that both on the list = and in the meeting, given that the proposed changes trickle down in the = other documents. Klaas --Apple-Mail=_D755DB07-765C-42BC-BC6E-AC4A699EDF50 Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- iEYEARECAAYFAk58mfkACgkQH2Wy/p4XeFL1cgCgkmaNIdI77v1QREJH6HaaLAvF jqEAoL7sv8VlRsPFQYrRMIvJE0/yRhMu =UUGL -----END PGP SIGNATURE----- --Apple-Mail=_D755DB07-765C-42BC-BC6E-AC4A699EDF50-- From Josh.Howlett@ja.net Fri Sep 23 07:48:30 2011 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4625D21F8C60 for ; Fri, 23 Sep 2011 07:48:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.833 X-Spam-Level: X-Spam-Status: No, score=-102.833 tagged_above=-999 required=5 tests=[AWL=-0.234, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lfIBUoNiBB9h for ; Fri, 23 Sep 2011 07:48:29 -0700 (PDT) Received: from har003676.ukerna.ac.uk (har003676.ukerna.ac.uk [194.82.140.75]) by ietfa.amsl.com (Postfix) with ESMTP id B174821F8C56 for ; Fri, 23 Sep 2011 07:48:29 -0700 (PDT) Received: from har003676.ukerna.ac.uk (localhost.localdomain [127.0.0.1]) by localhost (Email Security Appliance) with SMTP id C93064A6B71_E7C9CD6B; Fri, 23 Sep 2011 14:51:02 +0000 (GMT) Received: from EXC001.atlas.ukerna.ac.uk (exc001.atlas.ukerna.ac.uk [193.62.83.37]) by har003676.ukerna.ac.uk (Sophos Email Appliance) with ESMTP id 92A544A6B5C_E7C9CD6F; Fri, 23 Sep 2011 14:51:02 +0000 (GMT) Received: from EXC001.atlas.ukerna.ac.uk ([193.62.83.37]) by EXC001 ([193.62.83.37]) with mapi id 14.01.0289.001; Fri, 23 Sep 2011 15:51:02 +0100 From: Josh Howlett To: Klaas Wierenga , Leif Johansson Thread-Topic: [abfab] progress Thread-Index: AQHMa6IKPUBr+ykpX0eDzxPmgmjW3pVbGpWG///xeQCAAAjsAIAAFCiA Date: Fri, 23 Sep 2011 14:51:01 +0000 Message-ID: In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.13.0.110805 x-originating-ip: [194.82.140.76] Content-Type: text/plain; charset="us-ascii" Content-ID: <5B91567A2FB6E34F88769605D02926E6@ukerna.ac.uk> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "abfab@ietf.org" Subject: Re: [abfab] progress X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Sep 2011 14:48:30 -0000 > >just to add to this, I have talked to Josh and he promised to bring >forward a new AAA-SAML draft that encompasses the issues Jim and you >raised asap. I expect some lively discussion on that both on the list and >in the meeting, given that the proposed changes trickle down in the other >documents. I submitted an updated draft about a week or so ago but, now you mention it, I don't think I've seen anything appear. Who should I chase? The document now reluctantly discusses the SAML binding aspects. As Leif indicates ideally this should be done in OASIS SSTC. However I don't think it does any harm to continue developing the binding text within the existing document (and it may even help comprehension). The bindings text can be re-factored out once a volunteer from OASIS SSTC comes forwards *nudge* *nudge*. 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 Oxford, Didcot, Oxfordshire. OX11 0SG From hartmans@painless-security.com Fri Sep 23 08:02:28 2011 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 01F2821F8C15 for ; Fri, 23 Sep 2011 08:02:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.111 X-Spam-Level: X-Spam-Status: No, score=-2.111 tagged_above=-999 required=5 tests=[AWL=0.154, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kzIhhhQzAdKV for ; Fri, 23 Sep 2011 08:02:27 -0700 (PDT) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id 8F02C21F8C11 for ; Fri, 23 Sep 2011 08:02:27 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id 6B93D20424; Fri, 23 Sep 2011 11:06:41 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 7A2EC4234; Fri, 23 Sep 2011 11:04:35 -0400 (EDT) From: Sam Hartman To: Leif Johansson References: <4E6481BE.3060706@mnt.se> <4E7C927C.2060002@mnt.se> Date: Fri, 23 Sep 2011 11:04:35 -0400 In-Reply-To: <4E7C927C.2060002@mnt.se> (Leif Johansson's message of "Fri, 23 Sep 2011 16:06:52 +0200") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: "abfab@ietf.org" Subject: Re: [abfab] progress X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Sep 2011 15:02:28 -0000 >>>>> "Leif" == Leif Johansson writes: Leif> On 09/23/2011 03:58 PM, Sam Hartman wrote: >> I think it would be helpful to have an on-list discussion about >> what's needed for various documents. I'll be happy to start >> something for aaa-saml, architecture, gss-eap and gss-eap-naming. >> Any chance the chairs could comment or recruit comments on >> applicability? Leif> Why not just have the editors update the various documents and Leif> solicit review and comment like we normally do in the IETF? I'm unconvinced any significant update is needed. I think it would be valuable to have a discussion about what updates are needed to that document. You claimed that some combination of you and the authors believed that doc wasn't ready. So I'd like to have a discussion of what needs doing. From hartmans@painless-security.com Fri Sep 23 08:04:37 2011 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 63B6921F8CA4 for ; Fri, 23 Sep 2011 08:04:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.117 X-Spam-Level: X-Spam-Status: No, score=-2.117 tagged_above=-999 required=5 tests=[AWL=0.148, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RhKZoLEcuAbC for ; Fri, 23 Sep 2011 08:04:37 -0700 (PDT) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id 0185921F8CA3 for ; Fri, 23 Sep 2011 08:04:36 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id B6A1020424; Fri, 23 Sep 2011 11:08:54 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id C90714234; Fri, 23 Sep 2011 11:06:48 -0400 (EDT) From: Sam Hartman To: Leif Johansson References: <4E7C95CF.4040107@mnt.se> Date: Fri, 23 Sep 2011 11:06:48 -0400 In-Reply-To: <4E7C95CF.4040107@mnt.se> (Leif Johansson's message of "Fri, 23 Sep 2011 16:21:03 +0200") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: abfab@ietf.org Subject: Re: [abfab] Core documents: where we are X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Sep 2011 15:04:37 -0000 >>>>> "Leif" == Leif Johansson writes: >> * gss-eap: I think this is complete enough that we can get >> significant review. There are some open ends: Leif> Leif> When do you think you and Josh will have an update on 02 out? At some point in October , probably gss-eap right at the cutoff. I don't think those updates significantly affect the ability of people to review it. The updates to aaa-saml and gss-eap-naming are more important, although it's very unlikely we can get started on that before October 12. >> >> * aaa-saml. >> >> we've had several discussions of this. We need to specify more >> semantics to address issues Jim and I have raised.. We have a >> description of the attribute. We need to turn that into >> descriptions of the semantics of the attribute. In effect it >> needs to be more of a SAML binding. The fact that this is not >> written down is hurting us and this doc should be a real >> priority. >> The charter has us coordinating this with OASIS since a SAML binding Leif> should probably be published there but we don't actually have Leif> a stuckee for this job. My hope was to get Scott to do Leif> it.... hint hint, nudge nudge... Hannes and several participants have proposed that be folded into aa-saml. I'm not aware of anyone advocating for OASIS documents at this point. From hartmans@painless-security.com Fri Sep 23 08:08:41 2011 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FF2521F8C9D for ; Fri, 23 Sep 2011 08:08:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.122 X-Spam-Level: X-Spam-Status: No, score=-2.122 tagged_above=-999 required=5 tests=[AWL=0.143, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CEmWqj3L7h-4 for ; Fri, 23 Sep 2011 08:08:40 -0700 (PDT) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id A74EC21F8C7D for ; Fri, 23 Sep 2011 08:08:40 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id 9BB6D20289; Fri, 23 Sep 2011 11:12:58 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id A48E44234; Fri, 23 Sep 2011 11:10:52 -0400 (EDT) From: Sam Hartman To: Leif Johansson References: <4E7C95CF.4040107@mnt.se> Date: Fri, 23 Sep 2011 11:10:52 -0400 In-Reply-To: (Sam Hartman's message of "Fri, 23 Sep 2011 11:06:48 -0400") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: abfab@ietf.org Subject: Re: [abfab] Core documents: where we are X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Sep 2011 15:08:41 -0000 >>>>> "Sam" == Sam Hartman writes: >>>>> "Leif" == Leif Johansson writes: >>> * gss-eap: I think this is complete enough that we can get >>> significant review. There are some open ends: Leif> Leif> When do you think you and Josh will have an update on 02 out? Sam> At some point in October , probably gss-eap right at the Sam> cutoff. I don't think those updates significantly affect the Sam> ability of people to review it. The updates to aaa-saml and Sam> gss-eap-naming are more important, although it's very unlikely Sam> we can get started on that before October 12. >>> >>> * aaa-saml. >>> >>> we've had several discussions of this. We need to specify more >>> semantics to address issues Jim and I have raised.. We have a >>> description of the attribute. We need to turn that into >>> descriptions of the semantics of the attribute. In effect it >>> needs to be more of a SAML binding. The fact that this is not >>> written down is hurting us and this doc should be a real >>> priority. >>> The charter has us coordinating this with OASIS since a SAML binding Leif> should probably be published there but we don't actually have Leif> a stuckee for this job. My hope was to get Scott to do Leif> it.... hint hint, nudge nudge... Sam> Hannes and several participants have proposed that be folded Sam> into aa-saml. I'm not aware of anyone advocating for OASIS Sam> documents at this point. Sam> _______________________________________________ abfab mailing Sam> list abfab@ietf.org https://www.ietf.org/mailman/listinfo/abfab Ah, messages in another thread suggest there are still people who want to see this done in OASIS. There are others who have asked it be done here. I guess that's an open issue. From nico@cryptonector.com Fri Sep 23 08:10:28 2011 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D11021F8CB9 for ; Fri, 23 Sep 2011 08:10:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.677 X-Spam-Level: X-Spam-Status: No, score=-2.677 tagged_above=-999 required=5 tests=[AWL=-0.700, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yhaMhU7rYadA for ; Fri, 23 Sep 2011 08:10:27 -0700 (PDT) Received: from homiemail-a32.g.dreamhost.com (caiajhbdcaid.dreamhost.com [208.97.132.83]) by ietfa.amsl.com (Postfix) with ESMTP id DEF6521F8CB1 for ; Fri, 23 Sep 2011 08:10:27 -0700 (PDT) Received: from homiemail-a32.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a32.g.dreamhost.com (Postfix) with ESMTP id BD77058406A for ; Fri, 23 Sep 2011 08:13:01 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc: content-type; q=dns; s=cryptonector.com; b=PfQUVYLUDVciS78cmL9bJ yIkEqnPwRvFRCXJvov/ibTHAV93v3tL3WiqFt0gNbsNAInZho7YP+a2Aqq1y/cx3 HQr7LZ5ElIygM5SG2y82GdQQnsIPXxZQNnsosNAxn9h06sk2s92JW5UpCMwpzAlp zJ1qFbE+oDKchph9Bnl1R8= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=1FpN5Eeup6U4CN15rODF YxI8OV4=; b=FS8uykm7nfK8TNJ8el8+kbk/dE3JNNhJTbSvAFZtmwDvyrjqYIn1 fp+movK1rsuaf/Q3jP7hSCF0A6crB1NrvtaUkP7z2uIadsME5sP8sJDym4OD2ydN QAm0J3Xh7IkyanIWRwpO1Ep3+XN6RTHnvAHofGvEePQc2k1pT7nOYbY= Received: from mail-gw0-f44.google.com (mail-gw0-f44.google.com [74.125.83.44]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a32.g.dreamhost.com (Postfix) with ESMTPSA id 9EB39584065 for ; Fri, 23 Sep 2011 08:13:01 -0700 (PDT) Received: by gwj15 with SMTP id 15so3515194gwj.31 for ; Fri, 23 Sep 2011 08:13:01 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.38.10 with SMTP id c10mr10613152pbk.58.1316790780896; Fri, 23 Sep 2011 08:13:00 -0700 (PDT) Received: by 10.68.60.4 with HTTP; Fri, 23 Sep 2011 08:13:00 -0700 (PDT) In-Reply-To: References: <4E7C95CF.4040107@mnt.se> Date: Fri, 23 Sep 2011 10:13:00 -0500 Message-ID: From: Nico Williams To: Sam Hartman Content-Type: text/plain; charset=UTF-8 Cc: abfab@ietf.org Subject: Re: [abfab] Core documents: where we are X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Sep 2011 15:10:28 -0000 My advice would be to find a way to do all the work here, and not split any of it to OASIS. From leifj@sunet.se Fri Sep 23 08:44:52 2011 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DCA121F8AF8 for ; Fri, 23 Sep 2011 08:44:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.305 X-Spam-Level: * X-Spam-Status: No, score=1.305 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_17=0.6, MIME_QP_LONG_LINE=1.396, RCVD_ILLEGAL_IP=1.908] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OpyeAGqyvFvm for ; Fri, 23 Sep 2011 08:44:51 -0700 (PDT) Received: from backup-server.nordu.net (backup-server.nordu.net [IPv6:2001:948:4:1::66]) by ietfa.amsl.com (Postfix) with ESMTP id 6E6BF21F8C72 for ; Fri, 23 Sep 2011 08:44:51 -0700 (PDT) Received: from kerio.nordu.net (kerio.nordu.net [109.105.111.52]) by backup-server.nordu.net (8.14.3/8.14.3) with ESMTP id p8NFlGhx003941 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 23 Sep 2011 17:47:20 +0200 (CEST) Received: from [2.68.111.146] ([2.68.111.146]) by kerio.nordu.net; Fri, 23 Sep 2011 17:47:15 +0200 From: "Leif Johansson" References: <4E7C95CF.4040107@mnt.se> Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii In-Reply-To: Message-Id: <71335416-AC1F-4214-8FC7-D8AA78835E7B@sunet.se> Date: Fri, 23 Sep 2011 17:47:11 +0200 To: Nico Williams Mime-Version: 1.0 (iPhone Mail 8H7) Cc: "abfab@ietf.org" Subject: Re: [abfab] Core documents: where we are X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Sep 2011 15:44:52 -0000 It would be convenient for us but I'worried we may miss important feedback. P= erhaps Thomas Hardjono can advise us ... 23 sep 2011 kl. 17:13 skrev "Nico Williams" : > My advice would be to find a way to do all the work here, and not > split any of it to OASIS. > _______________________________________________ > abfab mailing list > abfab@ietf.org > https://www.ietf.org/mailman/listinfo/abfab From leifj@sunet.se Fri Sep 23 08:48:08 2011 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BBE1C21F8CE1 for ; Fri, 23 Sep 2011 08:48:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.005 X-Spam-Level: * X-Spam-Status: No, score=1.005 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_ILLEGAL_IP=1.908] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3wB7CUX9T40Q for ; Fri, 23 Sep 2011 08:48:08 -0700 (PDT) Received: from backup-server.nordu.net (backup-server.nordu.net [IPv6:2001:948:4:1::66]) by ietfa.amsl.com (Postfix) with ESMTP id 0AC3021F8CBC for ; Fri, 23 Sep 2011 08:48:07 -0700 (PDT) Received: from kerio.nordu.net (kerio.nordu.net [109.105.111.52]) by backup-server.nordu.net (8.14.3/8.14.3) with ESMTP id p8NFoc0n029132 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 23 Sep 2011 17:50:41 +0200 (CEST) Received: from [2.68.111.146] ([2.68.111.146]) by kerio.nordu.net; Fri, 23 Sep 2011 17:50:36 +0200 From: "Leif Johansson" References: <4E6481BE.3060706@mnt.se> <4E7C927C.2060002@mnt.se> Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii In-Reply-To: Message-Id: <5A64242D-A2D7-4AE2-85C2-74744A762DB9@sunet.se> Date: Fri, 23 Sep 2011 17:50:30 +0200 To: Sam Hartman Mime-Version: 1.0 (iPhone Mail 8H7) Cc: "abfab@ietf.org" Subject: Re: [abfab] progress X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Sep 2011 15:48:08 -0000 The authors have told the chairs that the applicability stmt needs another r= evision. Joe has promised an update in 1-2 weeks. 23 sep 2011 kl. 17:05 skrev "Sam Hartman" : >>>>>> "Leif" =3D=3D Leif Johansson writes: >=20 > Leif> On 09/23/2011 03:58 PM, Sam Hartman wrote: >>> I think it would be helpful to have an on-list discussion about >>> what's needed for various documents. I'll be happy to start >>> something for aaa-saml, architecture, gss-eap and gss-eap-naming. >>> Any chance the chairs could comment or recruit comments on >>> applicability? >=20 > Leif> Why not just have the editors update the various documents and > Leif> solicit review and comment like we normally do in the IETF? >=20 > I'm unconvinced any significant update is needed. > I think it would be valuable to have a discussion about what updates > are needed to that document. > You claimed that some combination of you and the authors believed that > doc wasn't ready. > So I'd like to have a discussion of what needs doing. > _______________________________________________ > abfab mailing list > abfab@ietf.org > https://www.ietf.org/mailman/listinfo/abfab From cantor.2@osu.edu Fri Sep 23 12:13:27 2011 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F8E621F8CF2 for ; Fri, 23 Sep 2011 12:13:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.188 X-Spam-Level: X-Spam-Status: No, score=-4.188 tagged_above=-999 required=5 tests=[AWL=-1.189, BAYES_00=-2.599, J_CHICKENPOX_17=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lDk29gnXT-wf for ; Fri, 23 Sep 2011 12:13:26 -0700 (PDT) Received: from defang1.it.ohio-state.edu (defang1.it.ohio-state.edu [128.146.216.81]) by ietfa.amsl.com (Postfix) with ESMTP id A112E21F8CC6 for ; Fri, 23 Sep 2011 12:13:24 -0700 (PDT) Received: from CIO-KRC-HT01.osuad.osu.edu (cio-krc-ht01.osuad.osu.edu [164.107.81.37]) by defang1.it.ohio-state.edu (8.13.7/8.13.1) with ESMTP id p8NJFjIg020821; Fri, 23 Sep 2011 15:15:56 -0400 Received: from CIO-KRC-D1MBX01.osuad.osu.edu ([fe80::450b:35e6:80f4:f3e0]) by CIO-KRC-HT01.osuad.osu.edu ([fe80::6d8f:7dea:5691:1620%13]) with mapi; Fri, 23 Sep 2011 15:09:55 -0400 From: "Cantor, Scott" To: Leif Johansson , Nico Williams Thread-Topic: [abfab] Core documents: where we are Thread-Index: AQHMefoKJt22sTkYmES713WLEQkhHpVbRyaAgAAMyACAAAEjAIAAAJkAgAAJjYD///WRgA== Date: Fri, 23 Sep 2011 19:09:51 +0000 Message-ID: In-Reply-To: <71335416-AC1F-4214-8FC7-D8AA78835E7B@sunet.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CanIt-Geo: ip=164.107.81.37; country=US; region=OH; city=Columbus; latitude=39.9968; longitude=-82.9882; metrocode=535; areacode=614; http://maps.google.com/maps?q=39.9968,-82.9882&z=6 X-CanItPRO-Stream: outbound X-Scanned-By: CanIt (www . roaringpenguin . com) on 128.146.216.81 Cc: "abfab@ietf.org" Subject: Re: [abfab] Core documents: where we are X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Sep 2011 19:13:27 -0000 On 9/23/11 11:47 AM, "Leif Johansson" wrote: > >It would be convenient for us but I'worried we may miss important >feedback. Perhaps Thomas Hardjono can advise us ... I can more easily offer a promise of review than I can volunteer to author and shepherd yet another spec at this point. And doing an binding at OASIS is only of interest to me if it's sufficiently generic. I'm not sure yet whether this work is going to be sensibly of use to carry arbitrary SAML protocols. It still feels use case (or profile-) specific to me. -- Scott From hartmans@painless-security.com Fri Sep 23 12:42:08 2011 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5738021F8A7B for ; Fri, 23 Sep 2011 12:42:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.128 X-Spam-Level: X-Spam-Status: No, score=-2.128 tagged_above=-999 required=5 tests=[AWL=0.137, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nVZlphWSZw1d for ; Fri, 23 Sep 2011 12:42:08 -0700 (PDT) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id E505121F8A4B for ; Fri, 23 Sep 2011 12:42:07 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id D1BD020424; Fri, 23 Sep 2011 15:46:23 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id B27594234; Fri, 23 Sep 2011 15:44:17 -0400 (EDT) From: Sam Hartman To: "Cantor\, Scott" References: Date: Fri, 23 Sep 2011 15:44:17 -0400 In-Reply-To: (Scott Cantor's message of "Fri, 23 Sep 2011 19:09:51 +0000") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: "abfab@ietf.org" Subject: Re: [abfab] Core documents: where we are X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Sep 2011 19:42:08 -0000 >>>>> "Cantor," == Cantor, Scott writes: Cantor,> And doing an binding at OASIS is only of interest to me if Cantor,> it's sufficiently generic. I'm not sure yet whether this Cantor,> work is going to be sensibly of use to carry arbitrary SAML Cantor,> protocols. It still feels use case (or profile-) specific Cantor,> to me. I agree. I think we're explicitly making it profile specific. From leifj@sunet.se Fri Sep 23 12:57:21 2011 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F53221F8B16 for ; Fri, 23 Sep 2011 12:57:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.529 X-Spam-Level: X-Spam-Status: No, score=-2.529 tagged_above=-999 required=5 tests=[AWL=0.070, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bwAlyLB02wWD for ; Fri, 23 Sep 2011 12:57:21 -0700 (PDT) Received: from backup-server.nordu.net (backup-server.nordu.net [IPv6:2001:948:4:1::66]) by ietfa.amsl.com (Postfix) with ESMTP id 9F2FE21F8B02 for ; Fri, 23 Sep 2011 12:57:20 -0700 (PDT) Received: from [10.0.0.11] (ua-83-227-179-169.cust.bredbandsbolaget.se [83.227.179.169]) (authenticated bits=0) by backup-server.nordu.net (8.14.3/8.14.3) with ESMTP id p8NJxjHd004832 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 23 Sep 2011 21:59:48 +0200 (CEST) Message-ID: <4E7CE531.1070004@sunet.se> Date: Fri, 23 Sep 2011 21:59:45 +0200 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.21) Gecko/20110831 Lightning/1.0b2 Thunderbird/3.1.13 MIME-Version: 1.0 To: Sam Hartman References: In-Reply-To: X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "abfab@ietf.org" , Thomas Hardjono Subject: Re: [abfab] Core documents: where we are X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Sep 2011 19:57:21 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 09/23/2011 09:44 PM, Sam Hartman wrote: >>>>>> "Cantor," == Cantor, Scott writes: > > > Cantor,> And doing an binding at OASIS is only of interest to me if > Cantor,> it's sufficiently generic. I'm not sure yet whether this > Cantor,> work is going to be sensibly of use to carry arbitrary SAML > Cantor,> protocols. It still feels use case (or profile-) specific > Cantor,> to me. > > I agree. I think we're explicitly making it profile specific. OK so our charter doesn't say we absolutely have to do a binding in OASIS SSTC as long as we coordinate with that group. Scott and Thomas - do you think we can ask the SSTC to review? Cheers Leif -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk585S0ACgkQ8Jx8FtbMZnc03gCfQ/LBej4y/ND9i/gsPzoIQ5nt D0IAnAgkRzVeeiO0UsES8wb8p/HgvayV =nUyK -----END PGP SIGNATURE----- From Josh.Howlett@ja.net Fri Sep 23 14:04:29 2011 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7DB9B21F8CC4 for ; Fri, 23 Sep 2011 14:04:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.89 X-Spam-Level: X-Spam-Status: No, score=-102.89 tagged_above=-999 required=5 tests=[AWL=-0.291, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IqPfKWhR5Evl for ; Fri, 23 Sep 2011 14:04:29 -0700 (PDT) Received: from har003676.ukerna.ac.uk (har003676.ukerna.ac.uk [194.82.140.75]) by ietfa.amsl.com (Postfix) with ESMTP id D9D4C21F8CC3 for ; Fri, 23 Sep 2011 14:04:28 -0700 (PDT) Received: from har003676.ukerna.ac.uk (localhost.localdomain [127.0.0.1]) by localhost (Email Security Appliance) with SMTP id C4CAB4A6B71_E7CF4F4B; Fri, 23 Sep 2011 21:07:00 +0000 (GMT) Received: from EXC001.atlas.ukerna.ac.uk (exc001.atlas.ukerna.ac.uk [193.62.83.37]) by har003676.ukerna.ac.uk (Sophos Email Appliance) with ESMTP id 364574A6B62_E7CF4F4F; Fri, 23 Sep 2011 21:07:00 +0000 (GMT) Received: from EXC001.atlas.ukerna.ac.uk ([193.62.83.37]) by EXC001 ([193.62.83.37]) with mapi id 14.01.0289.001; Fri, 23 Sep 2011 22:06:59 +0100 From: Josh Howlett To: Sam Hartman , "Cantor, Scott" Thread-Topic: [abfab] Core documents: where we are Thread-Index: AQHMefoDTBUf+ktgM0iyUHPFjBmhZJVbEjPo///vpQCAAAmNgIAAOKCAgAAanpSAABbdgA== Date: Fri, 23 Sep 2011 21:06:59 +0000 Message-ID: In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.13.0.110805 x-originating-ip: [194.82.140.76] Content-Type: text/plain; charset="us-ascii" Content-ID: <65789C8D8C212D48B80A16BB70E93624@ukerna.ac.uk> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "abfab@ietf.org" Subject: Re: [abfab] Core documents: where we are X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Sep 2011 21:04:29 -0000 > Cantor,> And doing an binding at OASIS is only of interest to me if > Cantor,> it's sufficiently generic. I'm not sure yet whether this > Cantor,> work is going to be sensibly of use to carry arbitrary SAML > Cantor,> protocols. It still feels use case (or profile-) specific > Cantor,> to me. > >I agree. I think we're explicitly making it profile specific. I think we ultimately need a profile specific solution for Abfab's purposes, and a generic binding that can be applied to other domains. The problem is that its all being shoehorned into single document. Here's a proposal: 1. RADIUS SAML attribute (Abfab): specifies encapsulation of SAML messages within RADIUS messages, per 01. 2. RADIUS SAML binding (OASIS): generic application of (1) for the puspose of a SAML binding 3. Abfab profile (Abfab): application of RADIUS SAML binding within Abfab architecture (covers issues such as authentication and attribute request) I had assumed that (3) would end up as part of the architecture document, but that's now non-normative so perhaps we need a new document... 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 Oxford, Didcot, Oxfordshire. OX11 0SG From cantor.2@osu.edu Fri Sep 23 14:27:06 2011 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D04921F8A7B for ; Fri, 23 Sep 2011 14:27:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.369 X-Spam-Level: X-Spam-Status: No, score=-4.369 tagged_above=-999 required=5 tests=[AWL=-0.770, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h560PR2dtkMR for ; Fri, 23 Sep 2011 14:27:05 -0700 (PDT) Received: from defang1.it.ohio-state.edu (defang1.it.ohio-state.edu [128.146.216.81]) by ietfa.amsl.com (Postfix) with ESMTP id AD45721F8A66 for ; Fri, 23 Sep 2011 14:27:05 -0700 (PDT) Received: from CIO-TNC-HT06.osuad.osu.edu (cio-tnc-ht06.osuad.osu.edu [164.107.81.171]) by defang1.it.ohio-state.edu (8.13.7/8.13.1) with ESMTP id p8NLTeFv018418; Fri, 23 Sep 2011 17:29:40 -0400 Received: from CIO-KRC-D1MBX01.osuad.osu.edu ([fe80::450b:35e6:80f4:f3e0]) by CIO-TNC-HT06.osuad.osu.edu ([fe80::3d16:84bd:8d88:7cfd%13]) with mapi; Fri, 23 Sep 2011 17:29:39 -0400 From: "Cantor, Scott" To: Leif Johansson Thread-Topic: [abfab] Core documents: where we are Thread-Index: AQHMefoKJt22sTkYmES713WLEQkhHpVbRyaAgAAMyACAAAEjAIAAAJkAgAAJjYD///WRgIAATK2AgAAEU4D//9YNgA== Date: Fri, 23 Sep 2011 21:29:37 +0000 Message-ID: In-Reply-To: <4E7CE531.1070004@sunet.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CanIt-Geo: ip=164.107.81.171; country=US; region=OH; city=Columbus; latitude=39.9968; longitude=-82.9882; metrocode=535; areacode=614; http://maps.google.com/maps?q=39.9968,-82.9882&z=6 X-CanItPRO-Stream: outbound X-Scanned-By: CanIt (www . roaringpenguin . com) on 128.146.216.81 Cc: "abfab@ietf.org" , Thomas Hardjono Subject: Re: [abfab] Core documents: where we are X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Sep 2011 21:27:06 -0000 On 9/23/11 3:59 PM, "Leif Johansson" wrote: > >OK so our charter doesn't say we absolutely have to do a binding in >OASIS SSTC as long as we coordinate with that group. > >Scott and Thomas - do you think we can ask the SSTC to review? Yes, though there are all of about 6-8 voting members left, let alone active ones. -- Scott From cantor.2@osu.edu Fri Sep 23 14:33:38 2011 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B42321F8C11 for ; Fri, 23 Sep 2011 14:33:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.299 X-Spam-Level: X-Spam-Status: No, score=-4.299 tagged_above=-999 required=5 tests=[AWL=-0.700, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lB4FHkN6coSp for ; Fri, 23 Sep 2011 14:33:38 -0700 (PDT) Received: from defang19.it.ohio-state.edu (defang19.it.ohio-state.edu [128.146.216.133]) by ietfa.amsl.com (Postfix) with ESMTP id D625321F8C2D for ; Fri, 23 Sep 2011 14:33:37 -0700 (PDT) Received: from CIO-KRC-HT02.osuad.osu.edu (cio-krc-ht02.osuad.osu.edu [164.107.81.40]) by defang19.it.ohio-state.edu (8.13.7/8.13.1) with ESMTP id p8NLa7rA016438; Fri, 23 Sep 2011 17:36:11 -0400 Received: from CIO-KRC-D1MBX01.osuad.osu.edu ([fe80::450b:35e6:80f4:f3e0]) by CIO-KRC-HT02.osuad.osu.edu ([fe80::8554:1787:2a7:72c9%13]) with mapi; Fri, 23 Sep 2011 17:36:09 -0400 From: "Cantor, Scott" To: Josh Howlett , Sam Hartman Thread-Topic: [abfab] Core documents: where we are Thread-Index: AQHMefoKJt22sTkYmES713WLEQkhHpVbRyaAgAAMyACAAAEjAIAAAJkAgAAJjYD///WRgIAATK2AgAAXHID//8UUAA== Date: Fri, 23 Sep 2011 21:36:06 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-ID: <6112bb2b-0a15-4384-abe5-c6e46c85b9d3> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CanIt-Geo: ip=164.107.81.40; country=US; region=OH; city=Columbus; latitude=39.9968; longitude=-82.9882; metrocode=535; areacode=614; http://maps.google.com/maps?q=39.9968,-82.9882&z=6 X-CanItPRO-Stream: outbound X-Scanned-By: CanIt (www . roaringpenguin . com) on 128.146.216.133 Cc: "abfab@ietf.org" Subject: Re: [abfab] Core documents: where we are X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Sep 2011 21:33:38 -0000 On 9/23/11 5:06 PM, "Josh Howlett" wrote: > >I think we ultimately need a profile specific solution for Abfab's >purposes, and a generic binding that can be applied to other domains. The >problem is that its all being shoehorned into single document. Here's a >proposal: > >1. RADIUS SAML attribute (Abfab): specifies encapsulation of SAML messages >within RADIUS messages, per 01. >2. RADIUS SAML binding (OASIS): generic application of (1) for the puspose >of a SAML binding >3. Abfab profile (Abfab): application of RADIUS SAML binding within Abfab >architecture (covers issues such as authentication and attribute request) > >I had assumed that (3) would end up as part of the architecture document, >but that's now non-normative so perhaps we need a new document... Well, you definitely need (3) in some normative document, and it's really the most important piece in SAML terms. I can see having (1) on its own for reuse. (2) doesn't necessarily have to be done on its own right out of the gate; it could be combined with (3) as part of the profile, and if there's interest in reuse, then a new binding could be done to factor it out. At an implementation level, this isn't the kind of binding you really get leverage from anyway. The HTTP and SOAP bindings are all playing in a common framework and you implement them using obvious reusable widgets so that you can plug them in. I don't really see that here because the transport is very specialized (at least to those of us not steeped in this stuff). Unless you have in mind that other bindings over the same transport are on the horizon. -- Scott From hartmans@painless-security.com Fri Sep 23 15:45:01 2011 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94DEA21F8B9A for ; Fri, 23 Sep 2011 15:45:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.133 X-Spam-Level: X-Spam-Status: No, score=-2.133 tagged_above=-999 required=5 tests=[AWL=0.132, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VQgLBwankjC7 for ; Fri, 23 Sep 2011 15:45:01 -0700 (PDT) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id 1F94A21F8B8E for ; Fri, 23 Sep 2011 15:45:01 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id 6E74A20424; Fri, 23 Sep 2011 18:49:17 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 34AC84234; Fri, 23 Sep 2011 18:47:11 -0400 (EDT) From: Sam Hartman To: Josh Howlett References: Date: Fri, 23 Sep 2011 18:47:11 -0400 In-Reply-To: (Josh Howlett's message of "Fri, 23 Sep 2011 21:06:59 +0000") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: "abfab@ietf.org" Subject: Re: [abfab] Core documents: where we are X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Sep 2011 22:45:01 -0000 >>>>> "Josh" == Josh Howlett writes: >> Cantor,> And doing an binding at OASIS is only of interest to me >> if Cantor,> it's sufficiently generic. I'm not sure yet whether >> this Cantor,> work is going to be sensibly of use to carry >> arbitrary SAML Cantor,> protocols. It still feels use case (or >> profile-) specific Cantor,> to me. >> >> I agree. I think we're explicitly making it profile specific. Josh> I think we ultimately need a profile specific solution for Josh> Abfab's purposes, and a generic binding that can be applied to Josh> other domains. The problem is that its all being shoehorned Josh> into single document. Here's a proposal: Josh> 1. RADIUS SAML attribute (Abfab): specifies encapsulation of Josh> SAML messages within RADIUS messages, per 01. 2. I'm very uncomfortable with a generic binding. I think we have a lot of good reasons why the RP needs to know the semantics here. So, I think we need normative references from our specs to the semantics, and the attribute (or a sub-attribute) needs to be scoped to those semantics/profile. So, I'm not very happy with item 1. Josh> RADIUS SAML Josh> binding (OASIS): generic application of (1) for the puspose of Josh> a SAML binding What do we get out of doing this work in OASIS other than OASIS review? Can you contrast with doing it here with OASIS review? Here are my concerns about OASIS 1) Can we come to consensus on something both groups can accept? We seem to believe that the semantics are important. OASIS seems to leave that to profiles. 2) It introduces publication complexity. 3) Do the right people participate? 4) Bringing SSTC up to speed. 5) Strong experience that changing the venue of a work leads to multi-year delays. That's within the IETF from one wg to another. Josh> 3. Abfab profile (Abfab): application of RADIUS Josh> SAML binding within Abfab architecture (covers issues such as Josh> authentication and attribute request) Josh> I had assumed that (3) would end up as part of the Josh> architecture document, but that's now non-normative so perhaps Josh> we need a new document... Or fold it all into aaa-saml. From kwiereng@cisco.com Sun Sep 25 02:07:02 2011 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A10421F84DA for ; Sun, 25 Sep 2011 02:07:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4BUUc-TMiEyt for ; Sun, 25 Sep 2011 02:07:01 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id 04DC521F84D9 for ; Sun, 25 Sep 2011 02:07:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=kwiereng@cisco.com; l=5984; q=dns/txt; s=iport; t=1316941780; x=1318151380; h=mime-version:subject:date:message-id:references:from:to: cc; bh=RZ3vja8CwNwHFUtYSAxVvlISELsIvK8foX/FzrwmT44=; b=G6D0NCRbmQRx91WXatMptiTqS/sojTDJptmArKVQ7jcNsCfE/LENEabS uK42ewlW4EZ2YxUPG1IDZe0ZySj99bRZT/GuyNLjOsX+5QuiHgvu2xAuE J1k7yJ/552zc1enDro3XgcTg85N6zIYphDSNsIt1EZHNkwYUIeAIh8yW1 o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAJbvfk6Q/khN/2dsb2JhbABCDqgMeIFTAQEBAQMBAQEPAQkRAz4LDAQCAQgEDQEDAQEBCgYYBgEmIgYIAgQBEggTB4dcmWIBnH2GK2AEh0KRO4tROQ X-IronPort-AV: E=Sophos;i="4.68,439,1312156800"; d="scan'208,217";a="117100612" Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-1.cisco.com with ESMTP; 25 Sep 2011 09:09:37 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by ams-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p8P99bbB010870; Sun, 25 Sep 2011 09:09:37 GMT Received: from xmb-ams-101.cisco.com ([144.254.74.76]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Sun, 25 Sep 2011 11:09:37 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CC7B62.D915D6C1" Date: Sun, 25 Sep 2011 11:06:25 +0200 Message-ID: <508B5CFB384F7F47951D0325C108B30201650D41@XMB-AMS-101.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [abfab] Core documents: where we are Thread-Index: AQHMefoKJt22sTkYmES713WLEQkhHpVbRyaAgAAMyACAAAEjAIAAAJkAgAAJjYD///WRgIAATK2AgAAXHID//8UUAIACUzVl References: From: "Klaas Wierenga (kwiereng)" To: "Cantor, Scott" , "Josh Howlett" , "Sam Hartman" X-OriginalArrivalTime: 25 Sep 2011 09:09:37.0046 (UTC) FILETIME=[D959E360:01CC7B62] X-Mailman-Approved-At: Sun, 25 Sep 2011 02:23:51 -0700 Cc: abfab@ietf.org Subject: Re: [abfab] Core documents: where we are X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Sep 2011 09:07:02 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CC7B62.D915D6C1 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, This all seems sensible. So how about we proceed inside abfab, get = review of (3) from those who are involved in OASIS to make sure we don't = screw up, and revisit the issue if/when we believe the binding might get = traction beyond this specific case? Klaas -- Klaas Wierenga Consulting Engineer - Office of the CTO Cisco Systems=20 -----Original Message----- From: abfab-bounces@ietf.org on behalf of Cantor, Scott Sent: Fri 9/23/2011 11:36 PM To: Josh Howlett; Sam Hartman Cc: abfab@ietf.org Subject: Re: [abfab] Core documents: where we are =20 On 9/23/11 5:06 PM, "Josh Howlett" wrote: > >I think we ultimately need a profile specific solution for Abfab's >purposes, and a generic binding that can be applied to other domains. = The >problem is that its all being shoehorned into single document. Here's a >proposal: > >1. RADIUS SAML attribute (Abfab): specifies encapsulation of SAML = messages >within RADIUS messages, per 01. >2. RADIUS SAML binding (OASIS): generic application of (1) for the = puspose >of a SAML binding >3. Abfab profile (Abfab): application of RADIUS SAML binding within = Abfab >architecture (covers issues such as authentication and attribute = request) > >I had assumed that (3) would end up as part of the architecture = document, >but that's now non-normative so perhaps we need a new document... Well, you definitely need (3) in some normative document, and it's = really the most important piece in SAML terms. I can see having (1) on its own for reuse. (2) doesn't necessarily have to be done on its own right out = of the gate; it could be combined with (3) as part of the profile, and if there's interest in reuse, then a new binding could be done to factor it out. At an implementation level, this isn't the kind of binding you really = get leverage from anyway. The HTTP and SOAP bindings are all playing in a common framework and you implement them using obvious reusable widgets = so that you can plug them in. I don't really see that here because the transport is very specialized (at least to those of us not steeped in = this stuff). Unless you have in mind that other bindings over the same transport are on the horizon. -- Scott _______________________________________________ abfab mailing list abfab@ietf.org https://www.ietf.org/mailman/listinfo/abfab ------_=_NextPart_001_01CC7B62.D915D6C1 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [abfab] Core documents: where we are

Hi,

This all seems sensible. So how about we proceed inside abfab, get = review of (3) from those who are involved in OASIS to make sure we don't = screw up, and revisit the issue if/when we believe the binding might get = traction beyond this specific case?

Klaas

--
Klaas Wierenga
Consulting Engineer - Office of the CTO
Cisco Systems



-----Original Message-----
From: abfab-bounces@ietf.org on behalf of Cantor, Scott
Sent: Fri 9/23/2011 11:36 PM
To: Josh Howlett; Sam Hartman
Cc: abfab@ietf.org
Subject: Re: [abfab] Core documents: where we are

On 9/23/11 5:06 PM, "Josh Howlett" <Josh.Howlett@ja.net> = wrote:
>
>I think we ultimately need a profile specific solution for = Abfab's
>purposes, and a generic binding that can be applied to other = domains. The
>problem is that its all being shoehorned into single document. = Here's a
>proposal:
>
>1. RADIUS SAML attribute (Abfab): specifies encapsulation of SAML = messages
>within RADIUS messages, per 01.
>2. RADIUS SAML binding (OASIS): generic application of (1) for the = puspose
>of a SAML binding
>3. Abfab profile (Abfab): application of RADIUS SAML binding within = Abfab
>architecture (covers issues such as authentication and attribute = request)
>
>I had assumed that (3) would end up as part of the architecture = document,
>but that's now non-normative so perhaps we need a new = document...

Well, you definitely need (3) in some normative document, and it's = really
the most important piece in SAML terms. I can see having (1) on its = own
for reuse. (2) doesn't necessarily have to be done on its own right out = of
the gate; it could be combined with (3) as part of the profile, and = if
there's interest in reuse, then a new binding could be done to factor = it
out.

At an implementation level, this isn't the kind of binding you really = get
leverage from anyway. The HTTP and SOAP bindings are all playing in = a
common framework and you implement them using obvious reusable widgets = so
that you can plug them in. I don't really see that here because the
transport is very specialized (at least to those of us not steeped in = this
stuff). Unless you have in mind that other bindings over the same
transport are on the horizon.

-- Scott

_______________________________________________
abfab mailing list
abfab@ietf.org
https://www.ietf.org= /mailman/listinfo/abfab

------_=_NextPart_001_01CC7B62.D915D6C1-- From hartmans@painless-security.com Sun Sep 25 13:13:12 2011 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8186F21F84D9 for ; Sun, 25 Sep 2011 13:13:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.137 X-Spam-Level: X-Spam-Status: No, score=-2.137 tagged_above=-999 required=5 tests=[AWL=0.128, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZfNSiNblURzE for ; Sun, 25 Sep 2011 13:13:12 -0700 (PDT) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id 0BF0321F84B2 for ; Sun, 25 Sep 2011 13:13:11 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id E943A20439; Sun, 25 Sep 2011 16:17:28 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id B22E64234; Sun, 25 Sep 2011 16:15:20 -0400 (EDT) From: Sam Hartman To: References: <4E6481BE.3060706@mnt.se> <009501cc7a5c$543d86c0$fcb89440$@augustcellars.com> Date: Sun, 25 Sep 2011 16:15:20 -0400 In-Reply-To: <009501cc7a5c$543d86c0$fcb89440$@augustcellars.com> (Jim Schaad's message of "Fri, 23 Sep 2011 18:50:25 -0700") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: abfab@ietf.org Subject: Re: [abfab] progress X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Sep 2011 20:13:12 -0000 >>>>> "Jim" == Jim Schaad writes: Jim> Sam, EXTREME IRRITATION Jim> I believe that I have provided comments on a number of Jim> documents. To the best of my knowledge many of these comments Jim> are still outstanding and have not had significant changes in Jim> documents resulting from them. This despite the fact that Jim> there was a long discussion between the two of us on Jim> architecture document changes that needed to be made shortly Jim> after the spring face-to-face meeting. Jim> Is it worth it for me to continue reviewing documents if I Jim> never seem to see updates resulting from them. Hi, Jim. I want to confirm the understanding. I think I've addressed your comments on draft-ietf-gss-eap to the best of my ability. If I have not, I'm really sorry and I'd like to deal with it. I think that the architecture document has not been updated significantly at all since you gave your comments, and I think that draft-ietf-gss-eap-naming has not been updated since you gave your comments. First, if you or anyone else wants commit access to the architecture document, my personal opinion is that more help would be great. I'd even love to find that I was no longer involved in the architecture document as an editor. If I remain involved, I do commit to addressing your comments in the next major update and believe your review has been incredibly valuable. I've explained why I think the specs are a higher priority than the architecture document. I'd be happy to have an off-list discussion if you think that's the wrong prioritization. As I mentioned, I do plan on addressing draft-ietf-gss-eap-naming comments in the next month and think draft-ietf-aaa-saml comments need to be addressed in that time frame too. Your comments have been very valuable and I want to do what it takes to make you happy. From leifj@sunet.se Mon Sep 26 00:29:02 2011 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE60E21F8AB9 for ; Mon, 26 Sep 2011 00:29:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hIovny5DLySo for ; Mon, 26 Sep 2011 00:29:02 -0700 (PDT) Received: from backup-server.nordu.net (backup-server.nordu.net [IPv6:2001:948:4:1::66]) by ietfa.amsl.com (Postfix) with ESMTP id 1DEC421F8AAA for ; Mon, 26 Sep 2011 00:29:01 -0700 (PDT) Received: from [192.36.125.212] (dhcp.pilsnet.sunet.se [192.36.125.212]) (authenticated bits=0) by backup-server.nordu.net (8.14.3/8.14.3) with ESMTP id p8Q7VbII026004 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 26 Sep 2011 09:31:41 +0200 (CEST) Message-ID: <4E802A59.9080300@sunet.se> Date: Mon, 26 Sep 2011 09:31:37 +0200 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.21) Gecko/20110831 Lightning/1.0b2 Thunderbird/3.1.13 MIME-Version: 1.0 To: abfab@ietf.org References: <4E6481BE.3060706@mnt.se> <009501cc7a5c$543d86c0$fcb89440$@augustcellars.com> In-Reply-To: X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [abfab] progress X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Sep 2011 07:29:03 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > priority than the architecture document. I'd be happy to have an > off-list discussion if you think that's the wrong prioritization. If anyone in the WG feels we should change our prioritization this should actually be on-list since the WG already has consensus to do core documents before architecture. In other words: Sam isn't just expressing his personal opinion here but is actually reflecting WG consensus. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk6AKlkACgkQ8Jx8FtbMZndTtwCfYvFUqQ3whImq6n3Wnd41Ip6O ZYcAn3ri3IOdydCDFn0YEjt+bx4Dek4T =WCUP -----END PGP SIGNATURE-----