Return-Path: Received: (from root@localhost) by example.com (8.11.6/8.11.6/SuSE Linux 0.5) id h4CMt1U02501 for root; Mon, 12 May 2003 17:55:01 -0500 Date: Thu, 4 Feb 2010 15:48:19 -0000 Sender: Moonshot project community list Message-Id: <200305122255.h4CMt1U02501@example.com> To: RANDOM_USER@example.com MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Test JANET(UK) is a trading name of The JNT Association, a company limited by guarantee which is registered in England under No. 2881024=20 and whose Registered Office is at Lumen House, Library Avenue, Harwell Science and Innovation Campus, Didcot, Oxfordshire. OX11 0SG - providing a clearer picture of how the technology would work from the PoV of the various actors, and how it satifies their goals as described in the use-case section. - providing a bit more detail describing how the various technologies are composed together. - explaining how trust establishment could be made to work, in practical operational and organisational terms, with the kinds of properties (scaling, semantics, security properties & assumptions, etc) that we're interested in. Any other ideas where the document could be improved would be very welcome. josh. JANET(UK) is a trading name of The JNT Association, a company limited by guarantee which is registered in England under No. 2881024=20 and whose Registered Office is at Lumen House, Library Avenue, Harwell Science and Innovation Campus, Didcot, Oxfordshire. OX11 0SG this works at an implementation level with GSS. In particular, it seems very undesirable to force all the cross-domain credentials out to endpoints. --Sam From hartmans@painless-security.com Mon Dec 13 11:40:50 2010 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7863C28C112 for ; Mon, 13 Dec 2010 11:40:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[AWL=-0.711, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mmi6iYIpUdzQ for ; Mon, 13 Dec 2010 11:40:49 -0800 (PST) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by core3.amsl.com (Postfix) with ESMTP id 65A4D28C111 for ; Mon, 13 Dec 2010 11:40:49 -0800 (PST) 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 4643D20220; Mon, 13 Dec 2010 14:41:24 -0500 (EST) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 9DA4441F7; Mon, 13 Dec 2010 14:42:19 -0500 (EST) From: Sam Hartman To: abfab@ietf.org Date: Mon, 13 Dec 2010 14:42:19 -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: mrex@sap.com Subject: [abfab] Should gss-eap support empty target_name X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 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, 13 Dec 2010 19:40:50 -0000 Folks, GSS-API has two modes of naming acceptors. The first is to specify an explicit name in the call to gss_init_sec_context. If authentication succeeds, then the initiator knows that the acceptor is the entity identified by that name. The other option is to pass in no name. In this optional mode, the initiator authenticates to the target. If mutual authentication is requested, the initiator learns the name of the target, but does not verify that name. This can be used to support leap-of-faith style authentication. An application can remember the target name that was received and warn if this name ever changes. The first mode--specified target name--is required. The second mode is optional but recommended by RFC 2743. I'm not aware of IETF protocols that consume GSS-API and use the empty target name mode. We've seen some discussion of these two modes and the tradeoffs between them in the kitten WG recently. Currently the gss-eap implementation and specification do not support empty target_name. (Nor does Kerberos nor the Kerberos derivatives.) It's kind of complex for us to support this mode. The problem is that in order to verify the target name we'd need to know what it is in order to pass it into EAP channel binding during the EAP authentication process. So, we somehow have to learn the target name from the acceptor fairly early on. Currently, we just exchange EAP tokens at that stage of the authentication. So, that would mean: * Somehow indicate to the target/acceptor that we want to know the target name * Add a new token where the acceptor tells us This is kind of messy because you presumably want the token where we learn the target name to be combined with an EAP token to avoid adding a round trip. That makes things a bit more annoying. However if people are going to find this capability useful, we should do it. We could add support for empty target name later, but we could not easily add graceful failure. If you wanted empty target name and the other side didn't implement that, you'd probably get a fairly messy failure. (There are some heavy-weight mechanisms available like a new mechanism OID, but that seems like a very big hammer for this.) --Sam From hartmans@painless-security.com Mon Dec 13 11:46:22 2010 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 445C628C0EB for ; Mon, 13 Dec 2010 11:46:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.739 X-Spam-Level: X-Spam-Status: No, score=-2.739 tagged_above=-999 required=5 tests=[AWL=-0.474, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KUAZ3r9l9c9u for ; Mon, 13 Dec 2010 11:46:21 -0800 (PST) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by core3.amsl.com (Postfix) with ESMTP id 8F76928C0DF for ; Mon, 13 Dec 2010 11:46:21 -0800 (PST) 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 16D5F20220; Mon, 13 Dec 2010 14:46:59 -0500 (EST) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 6C99941F7; Mon, 13 Dec 2010 14:47:54 -0500 (EST) From: Sam Hartman To: abfab@ietf.org References: Date: Mon, 13 Dec 2010 14:47:54 -0500 In-Reply-To: (Sam Hartman's message of "Mon, 13 Dec 2010 14:42:19 -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: mrex@sap.com Subject: [abfab] Should GSS-EAP support server name indication? X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 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, 13 Dec 2010 19:46:22 -0000 Folks, while writing up my null target name mail, I realized there's another question about support. TLS has an extension where a client can indicate what it believes the server name is before the authentication. This allows name-based virtual hosting among other things. Right now, we don't support a similarconcept for GSS-EAP. An IDP actually would be in a technical position to support aliases for the RP. However, the IDP is in no position to actually know what the aliases are. So, if we do want to have virtual hosting, we probably need to have some way to indicate the server name to the RP. Do we need this? From Nicolas.Williams@oracle.com Mon Dec 13 12:33:16 2010 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DDFB928C14A for ; Mon, 13 Dec 2010 12:33:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.537 X-Spam-Level: X-Spam-Status: No, score=-6.537 tagged_above=-999 required=5 tests=[AWL=0.061, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GZoA4bt79RfR for ; Mon, 13 Dec 2010 12:33:16 -0800 (PST) Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by core3.amsl.com (Postfix) with ESMTP id 17AFE28C139 for ; Mon, 13 Dec 2010 12:33:15 -0800 (PST) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id oBDKYpQW000992 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 13 Dec 2010 20:34:53 GMT Received: from acsmt353.oracle.com (acsmt353.oracle.com [141.146.40.153]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id oBDKUVjJ031559; Mon, 13 Dec 2010 20:34:50 GMT Received: from abhmt002.oracle.com by acsmt353.oracle.com with ESMTP id 870482141292272445; Mon, 13 Dec 2010 12:34:05 -0800 Received: from oracle.com (/10.135.193.24) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 13 Dec 2010 12:34:05 -0800 Date: Mon, 13 Dec 2010 14:34:03 -0600 From: Nicolas Williams To: Sam Hartman Message-ID: <20101213203403.GC29086@oracle.com> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2010-03-02) Cc: abfab@ietf.org, mrex@sap.com Subject: Re: [abfab] Should GSS-EAP support server name indication? X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 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, 13 Dec 2010 20:33:17 -0000 On Mon, Dec 13, 2010 at 02:47:54PM -0500, Sam Hartman wrote: > > > Folks, while writing up my null target name mail, I realized there's > another question about support. > > TLS has an extension where a client can indicate what it believes the > server name is before the authentication. This allows name-based > virtual hosting among other things. > > Right now, we don't support a similarconcept for GSS-EAP. > > An IDP actually would be in a technical position to support aliases for the RP. > However, the IDP is in no position to actually know what the aliases > are. > > So, if we do want to have virtual hosting, we probably need to have some > way to indicate the server name to the RP. > > Do we need this? Yes, I believe that you do. Nico -- From Nicolas.Williams@oracle.com Mon Dec 13 12:47:21 2010 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5989028C12D for ; Mon, 13 Dec 2010 12:47:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.538 X-Spam-Level: X-Spam-Status: No, score=-6.538 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d7wziTcxK0Mt for ; Mon, 13 Dec 2010 12:47:20 -0800 (PST) Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by core3.amsl.com (Postfix) with ESMTP id 655A628C144 for ; Mon, 13 Dec 2010 12:47:20 -0800 (PST) Received: from rcsinet13.oracle.com (rcsinet13.oracle.com [148.87.113.125]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id oBDKmulG030788 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 13 Dec 2010 20:48:58 GMT Received: from acsmt353.oracle.com (acsmt353.oracle.com [141.146.40.153]) by rcsinet13.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id oBDKmuuO028017; Mon, 13 Dec 2010 20:48:56 GMT Received: from abhmt008.oracle.com by acsmt355.oracle.com with ESMTP id 870536881292273332; Mon, 13 Dec 2010 12:48:52 -0800 Received: from oracle.com (/10.135.193.24) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 13 Dec 2010 12:48:51 -0800 Date: Mon, 13 Dec 2010 14:48:46 -0600 From: Nicolas Williams To: Sam Hartman Message-ID: <20101213204846.GD29086@oracle.com> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2010-03-02) Cc: abfab@ietf.org, mrex@sap.com Subject: Re: [abfab] Should gss-eap support empty target_name X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 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, 13 Dec 2010 20:47:21 -0000 On Mon, Dec 13, 2010 at 02:42:19PM -0500, Sam Hartman wrote: > Folks, GSS-API has two modes of naming acceptors. The first is to > specify an explicit name in the call to gss_init_sec_context. If > authentication succeeds, then the initiator knows that the acceptor is > the entity identified by that name. > > The other option is to pass in no name. > [...] > > This can be used to support leap-of-faith style authentication. An > application can remember the target name that was received and warn if > this name ever changes. I think this may be desirable for some mechanisms, particularly PKI-based mechanisms, in at least some use cases. Though even then it's best, UI-wise, if the application knows the acceptor name a priori. > The first mode--specified target name--is required. The second mode is > optional but recommended by RFC 2743. I'm not aware of IETF protocols > that consume GSS-API and use the empty target name mode. Me either. > We've seen some discussion of these two modes and the tradeoffs between > them in the kitten WG recently. Indeed. > Currently the gss-eap implementation and specification do not support > empty target_name. (Nor does Kerberos nor the Kerberos derivatives.) > > It's kind of complex for us to support this mode. The problem is that > in order to verify the target name we'd need to know what it is in order > to pass it into EAP channel binding during the EAP authentication > process. So, we somehow have to learn the target name from the acceptor > fairly early on. I don't understand. Since EAP is initiated by the server, surely you get to use the first GSS round-trip to exchange the "I don't know your name" / "my name is XYZ" messages, along with the initial EAP message. Also, the acceptor's choice of name can't affect the construction of the initial security context token, thus learning it from the first reply token can't actually result in needing extra round-trips. What am I missing? > Currently, we just exchange EAP tokens at that stage of the > authentication. A stackable mechanism could be used, as a last resort, to get the acceptor's name from the acceptor in a round-trip just for that purpose... It'd be better if the mechanism supported such a feature natively. I think the key question is: will ABFAB apps need this feature? I don't know the answer, which I suspect will depend on context. For the applications that I think you have in mind (e.g., traditional SASL and GSS-API applications) there's no need for this feature (there's a non-existence proof, as it were, of this assertion, no? please correct me if not). > So, that would mean: > > * Somehow indicate to the target/acceptor that we want to know the > target name > > * Add a new token where the acceptor tells us It'd be a whole new round-trip. OTOH, since EAP is initiated by the server... the initial context token can't bear anything terribly useful, and the first reply token sure could bear the acceptor name. If you just provide a flags field in the initial security context token and some framing in the first reply token, then I think you can revisit this issue later, if you ever need to. But if it's as simple as I'm thinking it is, do it now. Nico -- From cantor.2@osu.edu Mon Dec 13 16:44:34 2010 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 58CFF3A6E1A for ; Mon, 13 Dec 2010 16:44:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oQweJpRCPpdl for ; Mon, 13 Dec 2010 16:44:33 -0800 (PST) Received: from defang12.it.ohio-state.edu (defang12.it.ohio-state.edu [128.146.216.21]) by core3.amsl.com (Postfix) with ESMTP id 5CAE73A6E25 for ; Mon, 13 Dec 2010 16:44:31 -0800 (PST) Received: from CIO-TNC-HT05.osuad.osu.edu (cio-tnc-ht05.osuad.osu.edu [164.107.81.168]) by defang12.it.ohio-state.edu (8.13.7/8.13.1) with ESMTP id oBE0k7ET014374; Mon, 13 Dec 2010 19:46:07 -0500 Received: from CIO-KRC-D1MBX01.osuad.osu.edu ([fe80::450b:35e6:80f4:f3e0]) by CIO-TNC-HT05.osuad.osu.edu ([fe80::28c9:db48:3fa3:b384%24]) with mapi; Mon, 13 Dec 2010 19:43:28 -0500 From: "Cantor, Scott E." To: Sam Hartman , "abfab@ietf.org" Thread-Topic: [abfab] Should gss-eap support empty target_name Thread-Index: AQHLmv2KYIv/FebrXkuERkfB5vMkPpOfGpiA Date: Tue, 14 Dec 2010 00:46:05 +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: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CanIt-Geo: ip=164.107.81.168; country=US; region=OH; city=Wooster; postalcode=44691; latitude=40.8077; longitude=-81.9730; metrocode=510; areacode=330; http://maps.google.com/maps?q=40.8077,-81.9730&z=6 X-CanItPRO-Stream: outbound X-Scanned-By: CanIt (www . roaringpenguin . com) on 128.146.216.21 Subject: Re: [abfab] Should gss-eap support empty target_name X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 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, 14 Dec 2010 00:44:34 -0000 On 12/13/10 2:42 PM, "Sam Hartman" wrote: >This can be used to support leap-of-faith style authentication. An >application can remember the target name that was received and warn if >this name ever changes. What is it that the application is "remembering" (the analogy to the SSH public key) across sessions? -- Scott From cantor.2@osu.edu Mon Dec 13 18:45:16 2010 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EC2103A6E32 for ; Mon, 13 Dec 2010 18:45:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.099 X-Spam-Level: X-Spam-Status: No, score=-3.099 tagged_above=-999 required=5 tests=[AWL=-0.500, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yiKt9y0UNfSb for ; Mon, 13 Dec 2010 18:45:16 -0800 (PST) Received: from defang8.it.ohio-state.edu (defang8.it.ohio-state.edu [128.146.216.89]) by core3.amsl.com (Postfix) with ESMTP id 014013A6D5D for ; Mon, 13 Dec 2010 18:45:13 -0800 (PST) Received: from CIO-TNC-HT05.osuad.osu.edu (cio-tnc-ht05.osuad.osu.edu [164.107.81.168]) by defang8.it.ohio-state.edu (8.13.7/8.13.1) with ESMTP id oBE2knk7010520; Mon, 13 Dec 2010 21:46:50 -0500 Received: from CIO-KRC-D1MBX01.osuad.osu.edu ([fe80::450b:35e6:80f4:f3e0]) by CIO-TNC-HT05.osuad.osu.edu ([fe80::28c9:db48:3fa3:b384%24]) with mapi; Mon, 13 Dec 2010 21:44:10 -0500 From: "Cantor, Scott E." To: "Henry B. Hotz" Thread-Topic: [abfab] Should gss-eap support empty target_name Thread-Index: AQHLmv2KYIv/FebrXkuERkfB5vMkPpOfGpiAgABq3ID//7beAA== Date: Tue, 14 Dec 2010 02:46:48 +0000 Message-ID: In-Reply-To: <00B4F7E0-4A0B-4CFC-B90E-E843EA865313@oxy.edu> 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.168; country=US; region=OH; city=Wooster; postalcode=44691; latitude=40.8077; longitude=-81.9730; metrocode=510; areacode=330; http://maps.google.com/maps?q=40.8077,-81.9730&z=6 X-CanItPRO-Stream: outbound X-Scanned-By: CanIt (www . roaringpenguin . com) on 128.146.216.89 Cc: "abfab@ietf.org" Subject: Re: [abfab] Should gss-eap support empty target_name X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 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, 14 Dec 2010 02:45:17 -0000 >IIUC it would be the GSS name (display form?) of the server. So I'm basically connecting to some assumed service at a particular endpoint, but not with a "known" GSS identity, and then I store the fact that the assumed service identity is actually some particular GSS name so any future connections use the name. Is that the idea? Yes, that seems useful to me, but then I'm a believer in dumping commercial CAs in favor of the certpatrol model too. -- Scott From hartmans@painless-security.com Tue Dec 14 04:37:13 2010 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5D53D3A6F5F for ; Tue, 14 Dec 2010 04:37:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.621 X-Spam-Level: X-Spam-Status: No, score=-2.621 tagged_above=-999 required=5 tests=[AWL=-0.356, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5HiMgAnrDZpc for ; Tue, 14 Dec 2010 04:37:12 -0800 (PST) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by core3.amsl.com (Postfix) with ESMTP id 9FC593A6E00 for ; Tue, 14 Dec 2010 04:37:12 -0800 (PST) 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 4FB64202C9; Tue, 14 Dec 2010 07:37:50 -0500 (EST) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 442B941F7; Tue, 14 Dec 2010 07:38:45 -0500 (EST) From: Sam Hartman To: "Cantor\, Scott E." References: Date: Tue, 14 Dec 2010 07:38:45 -0500 In-Reply-To: (Scott E. Cantor's message of "Tue, 14 Dec 2010 02:46:48 +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" , "Henry B. Hotz" Subject: Re: [abfab] Should gss-eap support empty target_name X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 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, 14 Dec 2010 12:37:13 -0000 >>>>> "Cantor," == Cantor, Scott E writes: >> IIUC it would be the GSS name (display form?) of the server. Cantor,> So I'm basically connecting to some assumed service at a Cantor,> particular endpoint, but not with a "known" GSS identity, Cantor,> and then I store the fact that the assumed service identity Cantor,> is actually some particular GSS name so any future Cantor,> connections use the name. Is that the idea? Cantor,> Yes, that seems useful to me, but then I'm a believer in Cantor,> dumping commercial CAs in favor of the certpatrol model Cantor,> too. That's the idea. --Sam From Nicolas.Williams@oracle.com Tue Dec 14 07:53:33 2010 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A91283A6FA8 for ; Tue, 14 Dec 2010 07:53:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.54 X-Spam-Level: X-Spam-Status: No, score=-6.54 tagged_above=-999 required=5 tests=[AWL=0.058, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tS0n8jUcm4ZS for ; Tue, 14 Dec 2010 07:53:33 -0800 (PST) Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by core3.amsl.com (Postfix) with ESMTP id D5E553A6F9B for ; Tue, 14 Dec 2010 07:53:32 -0800 (PST) Received: from rcsinet15.oracle.com (rcsinet15.oracle.com [148.87.113.117]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id oBEFtA5W004053 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 14 Dec 2010 15:55:11 GMT Received: from acsmt354.oracle.com (acsmt354.oracle.com [141.146.40.154]) by rcsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id oBEFqUGT030833; Tue, 14 Dec 2010 15:55:08 GMT Received: from abhmt004.oracle.com by acsmt354.oracle.com with ESMTP id 852822561292342079; Tue, 14 Dec 2010 07:54:39 -0800 Received: from oracle.com (/10.135.188.51) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 14 Dec 2010 07:54:38 -0800 Date: Tue, 14 Dec 2010 09:54:36 -0600 From: Nicolas Williams To: "Cantor, Scott E." Message-ID: <20101214155436.GF1091@oracle.com> References: <00B4F7E0-4A0B-4CFC-B90E-E843EA865313@oxy.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2010-03-02) Cc: "abfab@ietf.org" , "Henry B. Hotz" Subject: Re: [abfab] Should gss-eap support empty target_name X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 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, 14 Dec 2010 15:53:33 -0000 On Tue, Dec 14, 2010 at 02:46:48AM +0000, Cantor, Scott E. wrote: > >IIUC it would be the GSS name (display form?) of the server. > > So I'm basically connecting to some assumed service at a particular > endpoint, but not with a "known" GSS identity, and then I store the fact > that the assumed service identity is actually some particular GSS name so > any future connections use the name. Is that the idea? To be more specific, the application would store a tuple consisting of the "name" (or whatever) given by the user and either the display name of, or better yet, exported name token form of the acceptor's actual name, indexed by the former. The "name" provided by the user needn't resemble a hostname, though often it will be (and when it is I think this feature has little value unless the mechanism has no way to authenticate hostnames). Nico -- From hbhotz@dslextreme.com Mon Dec 13 18:06:58 2010 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EB4D728C0CF for ; Mon, 13 Dec 2010 18:06:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.103 X-Spam-Level: X-Spam-Status: No, score=-3.103 tagged_above=-999 required=5 tests=[AWL=0.496, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QNJBmLm6iHj0 for ; Mon, 13 Dec 2010 18:06:57 -0800 (PST) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id 6C1D728C137 for ; Mon, 13 Dec 2010 18:06:57 -0800 (PST) Received: by iwn40 with SMTP id 40so175352iwn.31 for ; Mon, 13 Dec 2010 18:08:36 -0800 (PST) Received: by 10.42.172.134 with SMTP id n6mr3569648icz.131.1292292516377; Mon, 13 Dec 2010 18:08:36 -0800 (PST) Received: from laphotz.jpl.nasa.gov (laphotz.jpl.nasa.gov [128.149.133.44]) by mx.google.com with ESMTPS id 34sm6680915ibi.20.2010.12.13.18.08.34 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 13 Dec 2010 18:08:35 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: "Henry B. Hotz" In-Reply-To: Date: Mon, 13 Dec 2010 18:08:33 -0800 Content-Transfer-Encoding: 7bit Message-Id: <00B4F7E0-4A0B-4CFC-B90E-E843EA865313@oxy.edu> References: To: "Cantor, Scott E." X-Mailer: Apple Mail (2.1081) X-Mailman-Approved-At: Tue, 14 Dec 2010 12:13:14 -0800 Cc: "abfab@ietf.org" Subject: Re: [abfab] Should gss-eap support empty target_name X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 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, 14 Dec 2010 02:06:59 -0000 IIUC it would be the GSS name (display form?) of the server. On Dec 13, 2010, at 4:46 PM, Cantor, Scott E. wrote: > On 12/13/10 2:42 PM, "Sam Hartman" wrote: >> This can be used to support leap-of-faith style authentication. An >> application can remember the target name that was received and warn if >> this name ever changes. > > What is it that the application is "remembering" (the analogy to the SSH > public key) across sessions? > > -- Scott ------------------------------------------------------ The opinions expressed in this message are mine, not those of Caltech, JPL, NASA, or the US Government. Henry.B.Hotz@jpl.nasa.gov, or hbhotz@oxy.edu From ietf@augustcellars.com Tue Dec 14 13:56:12 2010 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 01AB428C130 for ; Tue, 14 Dec 2010 13:56:12 -0800 (PST) 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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GFejIqZl6MTK for ; Tue, 14 Dec 2010 13:56:11 -0800 (PST) Received: from new-smtp01.pacifier.net (new-smtp01.pacifier.net [64.255.237.177]) by core3.amsl.com (Postfix) with ESMTP id 45B7928C13F for ; Tue, 14 Dec 2010 13:56:11 -0800 (PST) Received: from TITUS (static-96-253-133-202.sttlwa.dsl-w.verizon.net [96.253.133.202]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by new-smtp01.pacifier.net (Postfix) with ESMTPSA id E90632CA02; Tue, 14 Dec 2010 13:57:51 -0800 (PST) From: "Jim Schaad" To: "'Nicolas Williams'" , "'Sam Hartman'" References: <20101213203403.GC29086@oracle.com> In-Reply-To: <20101213203403.GC29086@oracle.com> Date: Tue, 14 Dec 2010 14:13:21 -0800 Message-ID: <02f701cb9bdc$1f4ef610$5dece230$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQFgJYJIgZEwPL9IYA5A2SRvhLlgDwLWydiBAdl206yUUesj4A== Content-Language: en-us Cc: abfab@ietf.org, mrex@sap.com Subject: Re: [abfab] Should GSS-EAP support server name indication? X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 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, 14 Dec 2010 21:56:12 -0000 +1 > -----Original Message----- > From: abfab-bounces@ietf.org [mailto:abfab-bounces@ietf.org] On Behalf Of > Nicolas Williams > Sent: Monday, December 13, 2010 12:34 PM > To: Sam Hartman > Cc: abfab@ietf.org; mrex@sap.com > Subject: Re: [abfab] Should GSS-EAP support server name indication? > > On Mon, Dec 13, 2010 at 02:47:54PM -0500, Sam Hartman wrote: > > > > > > Folks, while writing up my null target name mail, I realized there's > > another question about support. > > > > TLS has an extension where a client can indicate what it believes the > > server name is before the authentication. This allows name-based > > virtual hosting among other things. > > > > Right now, we don't support a similarconcept for GSS-EAP. > > > > An IDP actually would be in a technical position to support aliases for the RP. > > However, the IDP is in no position to actually know what the aliases > > are. > > > > So, if we do want to have virtual hosting, we probably need to have > > some way to indicate the server name to the RP. > > > > Do we need this? > > Yes, I believe that you do. > > Nico > -- > _______________________________________________ > abfab mailing list > abfab@ietf.org > https://www.ietf.org/mailman/listinfo/abfab From ietf@augustcellars.com Tue Dec 14 14:04:24 2010 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1CB1C28C149 for ; Tue, 14 Dec 2010 14:04:24 -0800 (PST) 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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GqdF51XQ7Zx2 for ; Tue, 14 Dec 2010 14:04:23 -0800 (PST) Received: from smtp1.pacifier.net (smtp1.pacifier.net [64.255.237.171]) by core3.amsl.com (Postfix) with ESMTP id 7A76728C133 for ; Tue, 14 Dec 2010 14:04:22 -0800 (PST) Received: from TITUS (static-96-253-133-202.sttlwa.dsl-w.verizon.net [96.253.133.202]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp1.pacifier.net (Postfix) with ESMTP id 868326EF31 for ; Tue, 14 Dec 2010 14:06:03 -0800 (PST) From: "Jim Schaad" To: Date: Tue, 14 Dec 2010 14:21:33 -0800 Message-ID: <02f801cb9bdd$4422f350$cc68d9f0$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: Acub3CyF0OxP9zTHRpS3uFM3ksF3lA== Content-Language: en-us Subject: [abfab] Passing multiple SASL statements X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 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, 14 Dec 2010 22:04:24 -0000 At the f2f meeting, I said that I thought it was important that we have the ability to pass multiple SASL statements as part of the AAA system. I still think this is a requirement. A response was given from the chat room that this required that a query/response be given as well. I have been thinking on this both in this context and in a different context and I have come to the conclusion that I disagree with that statement. It may be useful for a server to be able to do a query for additional SASL statements but it is hardly required as there are a number of ways this could be handled. One way would be for the access denied message to indicate what additional statements are required. I can easily see situations where I cannot get all of the attributes needed in a single SASL statement. I can also see situations where I can know in advance what statements are required. This requires the ability to send multiple statements but not a query/response ability. That being said, I think that some type of query/response ability is required in order to reduce the number of restarts of the protocol. I don't want to start it, get the denied, I need to have this as well three or four times before finally getting access. The computational and traffic loads are going to be greater if one has to setup and tear down gss-api several times. Jim From lukeh@padl.com Tue Dec 14 14:06:10 2010 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 48B5B28C152 for ; Tue, 14 Dec 2010 14:06:10 -0800 (PST) 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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P2dK3RKfY-MF for ; Tue, 14 Dec 2010 14:06:09 -0800 (PST) Received: from us.padl.com (us.padl.com [216.154.215.154]) by core3.amsl.com (Postfix) with ESMTP id 78DD428C133 for ; Tue, 14 Dec 2010 14:06:09 -0800 (PST) Received: by us.padl.com with ESMTP id oBEM7SBr023799; Tue, 14 Dec 2010 17:07:32 -0500 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Luke Howard In-Reply-To: <02f801cb9bdd$4422f350$cc68d9f0$@augustcellars.com> Date: Wed, 15 Dec 2010 09:07:33 +1100 Content-Transfer-Encoding: 7bit Message-Id: <97A14F1C-72F5-4F4B-89EE-2E9B6E5E5174@padl.com> References: <02f801cb9bdd$4422f350$cc68d9f0$@augustcellars.com> To: Jim Schaad X-Mailer: Apple Mail (2.1082) X-SMTP-Vilter-Version: 1.3.6 X-Spamd-Symbols: AWL,BAYES_00 X-SMTP-Vilter-Spam-Backend: spamd X-Spam-Threshold: 5.0 X-Spam-Probability: -0.5 Cc: abfab@ietf.org Subject: Re: [abfab] Passing multiple SASL statements X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 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, 14 Dec 2010 22:06:10 -0000 > I can easily see situations where I cannot get all of the attributes needed > in a single SASL statement. I can also see situations where I can You're talking about SAML, right? You can have multiple SAML attribute statements in an assertion, does help? -- Luke From leifj@sunet.se Tue Dec 14 14:08:54 2010 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A59A33A683E for ; Tue, 14 Dec 2010 14:08:54 -0800 (PST) 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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WjCa68x788Fc for ; Tue, 14 Dec 2010 14:08:53 -0800 (PST) Received: from backup-server.nordu.net (backup-server.nordu.net [IPv6:2001:948:4:1::66]) by core3.amsl.com (Postfix) with ESMTP id 6C56E28C133 for ; Tue, 14 Dec 2010 14:08:46 -0800 (PST) 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 oBEMAHru000746 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 14 Dec 2010 23:10:20 +0100 (CET) Message-ID: <4D07EB49.2090809@sunet.se> Date: Tue, 14 Dec 2010 23:10:17 +0100 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.13) Gecko/20101208 Lightning/1.0b2 Thunderbird/3.1.7 MIME-Version: 1.0 To: abfab@ietf.org References: <02f801cb9bdd$4422f350$cc68d9f0$@augustcellars.com> <97A14F1C-72F5-4F4B-89EE-2E9B6E5E5174@padl.com> In-Reply-To: <97A14F1C-72F5-4F4B-89EE-2E9B6E5E5174@padl.com> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [abfab] Passing multiple SASL statements X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 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, 14 Dec 2010 22:08:54 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 12/14/2010 11:07 PM, Luke Howard wrote: >> I can easily see situations where I cannot get all of the attributes needed >> in a single SASL statement. I can also see situations where I can > > You're talking about SAML, right? That must be it. We were talking about SAML Response vs SAML Assertion. I seem to recall that the room was in favour of using SAML Responses. This was in the context of Josh's AAA draft. Cheers Leif -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk0H60kACgkQ8Jx8FtbMZnc5kQCgvMdHr2ditbbPX/uHq+irOX9j g8wAn0e+9UqMYpVugSbXVSkyNE13HH72 =jsjf -----END PGP SIGNATURE----- From cantor.2@osu.edu Tue Dec 14 14:12:09 2010 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8E04E28C157 for ; Tue, 14 Dec 2010 14:12:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.537 X-Spam-Level: X-Spam-Status: No, score=-3.537 tagged_above=-999 required=5 tests=[AWL=0.062, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nFzNc+YnmIVI for ; Tue, 14 Dec 2010 14:12:00 -0800 (PST) Received: from defang16.it.ohio-state.edu (defang16.it.ohio-state.edu [128.146.216.130]) by core3.amsl.com (Postfix) with ESMTP id EBC4528C133 for ; Tue, 14 Dec 2010 14:11:55 -0800 (PST) Received: from CIO-KRC-HT02.osuad.osu.edu ([164.107.81.41]) by defang16.it.ohio-state.edu (8.13.7/8.13.1) with ESMTP id oBEMDPGM027561 for ; Tue, 14 Dec 2010 17:13:35 -0500 Received: from CIO-KRC-D1MBX01.osuad.osu.edu ([fe80::450b:35e6:80f4:f3e0]) by CIO-KRC-HT02.osuad.osu.edu ([2002:a46b:5129::a46b:5129]) with mapi; Tue, 14 Dec 2010 17:10:49 -0500 From: "Cantor, Scott E." To: "abfab@ietf.org" Thread-Topic: [abfab] Passing multiple SASL statements Thread-Index: Acub3CyF0OxP9zTHRpS3uFM3ksF3lAAANQ/A Date: Tue, 14 Dec 2010 22:13:31 +0000 Message-ID: <7EE86E89365CA94F8E7B8251F9260710021281@CIO-KRC-D1MBX01.osuad.osu.edu> References: <02f801cb9bdd$4422f350$cc68d9f0$@augustcellars.com> In-Reply-To: <02f801cb9bdd$4422f350$cc68d9f0$@augustcellars.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CanIt-Geo: ip=164.107.81.41; country=US; region=OH; city=Wooster; postalcode=44691; latitude=40.8077; longitude=-81.9730; metrocode=510; areacode=330; http://maps.google.com/maps?q=40.8077,-81.9730&z=6 X-CanItPRO-Stream: outbound X-Scanned-By: CanIt (www . roaringpenguin . com) on 128.146.216.130 Subject: Re: [abfab] Passing multiple SASL statements X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 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, 14 Dec 2010 22:12:10 -0000 > At the f2f meeting, I said that I thought it was important that we have t= he > ability to pass multiple SASL statements as part of the AAA system. I st= ill > think this is a requirement. SASL, or SAML? Assuming you mean the latter: A SAML Response contains 0 to N Assertions. A SAML Assertion is issued by exactly one authority, and can have any numbe= r of Statements, but conventionally, just has one of any given type. A SAML AttributeStatement has 1 to N Attributes. So which are you proposing is needed? > A response was given from the chat room that this required that a > query/response be given as well. I believe what I said was that a convenient way to carry multiple Assertion= s within a single atomic structure defined by SAML is a Response. I didn't = mean to imply that one couldn't frame multiple Assertions arbitrarily in so= me other way, and I didn't mean to imply that using a Response implied a Qu= ery or Request. It doesn't have to. > I can easily see situations where I cannot get all of the attributes need= ed > in a single SASL statement. I can also see situations where I can know i= n > advance what statements are required. This requires the ability to send > multiple statements but not a query/response ability. The reality is that one channel exchanging data with one authority is not g= oing to solve every problem anyway. But, for clarification, I would pick a different word than Statement, that = isn't the unit you want here. =20 -- Scott From hartmans@painless-security.com Tue Dec 14 14:19:24 2010 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 781C028C0E6 for ; Tue, 14 Dec 2010 14:19:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.55 X-Spam-Level: X-Spam-Status: No, score=-2.55 tagged_above=-999 required=5 tests=[AWL=-0.284, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N878TLNPc-g3 for ; Tue, 14 Dec 2010 14:19:20 -0800 (PST) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by core3.amsl.com (Postfix) with ESMTP id 2DE0528C100 for ; Tue, 14 Dec 2010 14:19:18 -0800 (PST) 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 445FC2029B; Tue, 14 Dec 2010 17:19:55 -0500 (EST) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id CFA0B4060; Tue, 14 Dec 2010 17:20:49 -0500 (EST) From: Sam Hartman To: "Jim Schaad" References: <02f801cb9bdd$4422f350$cc68d9f0$@augustcellars.com> Date: Tue, 14 Dec 2010 17:20:49 -0500 In-Reply-To: <02f801cb9bdd$4422f350$cc68d9f0$@augustcellars.com> (Jim Schaad's message of "Tue, 14 Dec 2010 14:21:33 -0800") 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] Passing multiple SAML statements X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 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, 14 Dec 2010 22:19:24 -0000 >>>>> "Jim" == Jim Schaad writes: Jim> At the f2f meeting, I said that I thought it was important that Jim> we have the ability to pass multiple SASL statements as part of Jim> the AAA system. I still think this is a requirement. Do you think multiple SAML responses are needed or simply a single response containing potentially multiple assertions? I'm in favor of multiple assertions in a response. I think that supporting multiple responses provides significant trust complexity, especially if the responses are from different parties. This complexity is amplified when we try and provide access to applications. So, I'd prefer to avoid it. Jim> A response was given from the chat room that this required that Jim> a query/response be given as well. I have been thinking on Jim> this both in this context and in a different context and I have Jim> come to the conclusion that I disagree with that statement. I also believe that supporting multiple assertions (or even multiple responses) does not require a server query. Jim> It Jim> may be useful for a server to be able to do a query for Jim> additional SASL statements but it is hardly required as there Jim> are a number of ways this could be handled. One way would be This makes no sense at all. The party sending the access-reject is the same party who would send the SAML responses in the access-accept case. It makes no sense for that party to send an access-reject saying "here are other statements you would need. I decided not to provide them so I denied your access." From ietf@augustcellars.com Tue Dec 14 14:56:13 2010 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0DBBC28C136 for ; Tue, 14 Dec 2010 14:56:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.518 X-Spam-Level: X-Spam-Status: No, score=-2.518 tagged_above=-999 required=5 tests=[AWL=0.081, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tq40m-nB+lOG for ; Tue, 14 Dec 2010 14:56:12 -0800 (PST) Received: from new-smtp01.pacifier.net (new-smtp01.pacifier.net [64.255.237.177]) by core3.amsl.com (Postfix) with ESMTP id 5849628C100 for ; Tue, 14 Dec 2010 14:56:12 -0800 (PST) Received: from TITUS (unknown [207.202.179.27]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by new-smtp01.pacifier.net (Postfix) with ESMTPSA id 289762CA1D; Tue, 14 Dec 2010 14:57:45 -0800 (PST) From: "Jim Schaad" To: "'Luke Howard'" References: <02f801cb9bdd$4422f350$cc68d9f0$@augustcellars.com> <97A14F1C-72F5-4F4B-89EE-2E9B6E5E5174@padl.com> In-Reply-To: <97A14F1C-72F5-4F4B-89EE-2E9B6E5E5174@padl.com> Date: Tue, 14 Dec 2010 15:13:17 -0800 Message-ID: <02fc01cb9be4$82764970$8762dc50$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQFHACtfJms4F60bU0rWOn4oVwvMpAJJRZSylJd98cA= Content-Language: en-us Cc: abfab@ietf.org Subject: Re: [abfab] Passing multiple SASL statements X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 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, 14 Dec 2010 22:56:13 -0000 One of these days I will get back to using SAML for SAML. I got confused about 6 months ago and still have not managed to always come up with the right one all of the time. You can have multiple assertions in a single SAML statement, however you might need assertions that are supplied by two different issuers. In this case you would need to have multiple SAML statements. One would assume that there would be a common assertion that is shared so that they could be correlated. Jim > -----Original Message----- > From: Luke Howard [mailto:lukeh@padl.com] > Sent: Tuesday, December 14, 2010 2:08 PM > To: Jim Schaad > Cc: abfab@ietf.org > Subject: Re: [abfab] Passing multiple SASL statements > > > I can easily see situations where I cannot get all of the attributes > > needed in a single SASL statement. I can also see situations where I > > can > > You're talking about SAML, right? > > You can have multiple SAML attribute statements in an assertion, does help? > > -- Luke From ietf@augustcellars.com Tue Dec 14 15:01:25 2010 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5F1D628C127 for ; Tue, 14 Dec 2010 15:01:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.528 X-Spam-Level: X-Spam-Status: No, score=-2.528 tagged_above=-999 required=5 tests=[AWL=0.071, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yNmNyaTzUDVR for ; Tue, 14 Dec 2010 15:01:24 -0800 (PST) Received: from smtp1.pacifier.net (smtp1.pacifier.net [64.255.237.171]) by core3.amsl.com (Postfix) with ESMTP id 8DB3F28C100 for ; Tue, 14 Dec 2010 15:01:24 -0800 (PST) Received: from TITUS (unknown [207.202.179.27]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp1.pacifier.net (Postfix) with ESMTP id 824FC6EF28; Tue, 14 Dec 2010 15:03:00 -0800 (PST) From: "Jim Schaad" To: "'Cantor, Scott E.'" , References: <02f801cb9bdd$4422f350$cc68d9f0$@augustcellars.com> <7EE86E89365CA94F8E7B8251F9260710021281@CIO-KRC-D1MBX01.osuad.osu.edu> In-Reply-To: <7EE86E89365CA94F8E7B8251F9260710021281@CIO-KRC-D1MBX01.osuad.osu.edu> Date: Tue, 14 Dec 2010 15:18:31 -0800 Message-ID: <02fd01cb9be5$3cadf2c0$b609d840$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQFHACtfJms4F60bU0rWOn4oVwvMpAIW0CuVlJkS8zA= Content-Language: en-us Subject: Re: [abfab] Passing multiple SASL statements X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 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, 14 Dec 2010 23:01:25 -0000 > -----Original Message----- > From: abfab-bounces@ietf.org [mailto:abfab-bounces@ietf.org] On Behalf Of > Cantor, Scott E. > Sent: Tuesday, December 14, 2010 2:14 PM > To: abfab@ietf.org > Subject: Re: [abfab] Passing multiple SASL statements > > > At the f2f meeting, I said that I thought it was important that we > > have the ability to pass multiple SASL statements as part of the AAA > > system. I still think this is a requirement. > > SASL, or SAML? > > Assuming you mean the latter: > > A SAML Response contains 0 to N Assertions. > > A SAML Assertion is issued by exactly one authority, and can have any number > of Statements, but conventionally, just has one of any given type. > > A SAML AttributeStatement has 1 to N Attributes. > > So which are you proposing is needed? > > > A response was given from the chat room that this required that a > > query/response be given as well. > > I believe what I said was that a convenient way to carry multiple Assertions > within a single atomic structure defined by SAML is a Response. I didn't mean > to imply that one couldn't frame multiple Assertions arbitrarily in some other > way, and I didn't mean to imply that using a Response implied a Query or > Request. It doesn't have to. Then I managed to mis-hear what was said. I was hearing that a query/response was being suggested. I am not sure that there would be any benefit to using a response as a container rather than just allowing multiple assertions to be transmitted individually. > > > I can easily see situations where I cannot get all of the attributes > > needed in a single SASL statement. I can also see situations where I > > can know in advance what statements are required. This requires the > > ability to send multiple statements but not a query/response ability. > > The reality is that one channel exchanging data with one authority is not going > to solve every problem anyway. > > But, for clarification, I would pick a different word than Statement, that isn't > the unit you want here. You are correct. I had my words backwards. I meant to say multiple SAML assertions. > > -- Scott > > _______________________________________________ > abfab mailing list > abfab@ietf.org > https://www.ietf.org/mailman/listinfo/abfab From cantor.2@osu.edu Tue Dec 14 15:07:48 2010 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D624128C127 for ; Tue, 14 Dec 2010 15:07:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.543 X-Spam-Level: X-Spam-Status: No, score=-3.543 tagged_above=-999 required=5 tests=[AWL=0.056, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M6e7Is9tcaLj for ; Tue, 14 Dec 2010 15:07:48 -0800 (PST) Received: from defang14.it.ohio-state.edu (defang14.it.ohio-state.edu [128.146.216.128]) by core3.amsl.com (Postfix) with ESMTP id 127AE28C100 for ; Tue, 14 Dec 2010 15:07:46 -0800 (PST) Received: from CIO-KRC-HT01.osuad.osu.edu ([164.107.81.38]) by defang14.it.ohio-state.edu (8.13.7/8.13.1) with ESMTP id oBEN9OIX010261; Tue, 14 Dec 2010 18:09:25 -0500 Received: from CIO-KRC-D1MBX01.osuad.osu.edu ([fe80::450b:35e6:80f4:f3e0]) by CIO-KRC-HT01.osuad.osu.edu ([2002:a46b:5126::a46b:5126]) with mapi; Tue, 14 Dec 2010 18:06:40 -0500 From: "Cantor, Scott E." To: Jim Schaad , Luke Howard Thread-Topic: [abfab] Passing multiple SASL statements Thread-Index: Acub3CyF0OxP9zTHRpS3uFM3ksF3lAAKQr6AAAJLtID//6sQgA== Date: Tue, 14 Dec 2010 23:09:17 +0000 Message-ID: In-Reply-To: <02fc01cb9be4$82764970$8762dc50$@augustcellars.com> 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: <19d87e10-85f2-4dda-ae8c-be00d85d5169> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CanIt-Geo: ip=164.107.81.38; country=US; region=OH; city=Wooster; postalcode=44691; latitude=40.8077; longitude=-81.9730; metrocode=510; areacode=330; http://maps.google.com/maps?q=40.8077,-81.9730&z=6 X-CanItPRO-Stream: outbound X-Scanned-By: CanIt (www . roaringpenguin . com) on 128.146.216.128 Cc: "abfab@ietf.org" Subject: Re: [abfab] Passing multiple SASL statements X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 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, 14 Dec 2010 23:07:48 -0000 >You can have multiple assertions in a single SAML statement, however you >might need assertions that are supplied by two different issuers. In this >case you would need to have multiple SAML statements. One would assume >that >there would be a common assertion that is shared so that they could be >correlated. Your terms are off here, so it's very important to be clear. An assertion has exactly one issuer, and you cannot combine statements from different issuers in one assertion. If you s/statement/Response, you'd have it, I think, but a Response also comes from one Issuer. Given a profile allowing mixed issuers within the Response's assertions, that's allowed, albeit complex. -- Scott From cantor.2@osu.edu Tue Dec 14 15:09:48 2010 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3254628C127 for ; Tue, 14 Dec 2010 15:09:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.549 X-Spam-Level: X-Spam-Status: No, score=-3.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qupYHY+0uAYl for ; Tue, 14 Dec 2010 15:09:47 -0800 (PST) Received: from defang17.it.ohio-state.edu (defang17.it.ohio-state.edu [128.146.216.131]) by core3.amsl.com (Postfix) with ESMTP id 493AE28C100 for ; Tue, 14 Dec 2010 15:09:47 -0800 (PST) Received: from CIO-KRC-HT02.osuad.osu.edu ([164.107.81.41]) by defang17.it.ohio-state.edu (8.13.7/8.13.1) with ESMTP id oBENBP5R008089; Tue, 14 Dec 2010 18:11:25 -0500 Received: from CIO-KRC-D1MBX01.osuad.osu.edu ([fe80::450b:35e6:80f4:f3e0]) by CIO-KRC-HT02.osuad.osu.edu ([2002:a46b:5129::a46b:5129]) with mapi; Tue, 14 Dec 2010 18:08:42 -0500 From: "Cantor, Scott E." To: Jim Schaad , "abfab@ietf.org" Thread-Topic: [abfab] Passing multiple SASL statements Thread-Index: Acub3CyF0OxP9zTHRpS3uFM3ksF3lAAANQ/AAAyILYD//6oqAA== Date: Tue, 14 Dec 2010 23:11:18 +0000 Message-ID: In-Reply-To: <02fd01cb9be5$3cadf2c0$b609d840$@augustcellars.com> 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: <15ef03a4-a6ff-4fc7-8fb5-d50945e4dd1f> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CanIt-Geo: ip=164.107.81.41; country=US; region=OH; city=Wooster; postalcode=44691; latitude=40.8077; longitude=-81.9730; metrocode=510; areacode=330; http://maps.google.com/maps?q=40.8077,-81.9730&z=6 X-CanItPRO-Stream: outbound X-Scanned-By: CanIt (www . roaringpenguin . com) on 128.146.216.131 Subject: Re: [abfab] Passing multiple SASL statements X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 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, 14 Dec 2010 23:09:48 -0000 >Then I managed to mis-hear what was said. I was hearing that a >query/response was being suggested. I am not sure that there would be any >benefit to using a response as a container rather than just allowing >multiple assertions to be transmitted individually. There may not be, and a Response has baggage of its own, it just depends on the framing possible within the particular protocol. For example, if a given framework allowed only a single value for some attribute or property that was used to mean "SAML assertion", you'd have a problem handling >1. -- Scott From ietf@augustcellars.com Tue Dec 14 15:12:34 2010 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 24B8E28C143 for ; Tue, 14 Dec 2010 15:12:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.536 X-Spam-Level: X-Spam-Status: No, score=-2.536 tagged_above=-999 required=5 tests=[AWL=0.063, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l0DIVFh1p+tv for ; Tue, 14 Dec 2010 15:12:33 -0800 (PST) Received: from smtp2.pacifier.net (smtp2.pacifier.net [64.255.237.172]) by core3.amsl.com (Postfix) with ESMTP id 2C98628C152 for ; Tue, 14 Dec 2010 15:12:33 -0800 (PST) Received: from TITUS (unknown [207.202.179.27]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp2.pacifier.net (Postfix) with ESMTP id 0077F6A459; Tue, 14 Dec 2010 15:14:13 -0800 (PST) From: "Jim Schaad" To: "'Sam Hartman'" References: <02f801cb9bdd$4422f350$cc68d9f0$@augustcellars.com> In-Reply-To: Date: Tue, 14 Dec 2010 15:29:45 -0800 Message-ID: <02fe01cb9be6$cb34ce50$619e6af0$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQFHACtfJms4F60bU0rWOn4oVwvMpAGHvBctlJ2MWiA= Content-Language: en-us Cc: abfab@ietf.org Subject: Re: [abfab] Passing multiple SAML statements X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 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, 14 Dec 2010 23:12:34 -0000 Sam, I need to get my terms in agreement with others so that I can make sure we are talking the same language. This is part of the problem of not having lived in the specifications for long enough but just dipping into them occasionally as needed. What I thought was a statement appears to be a SAML assertion. That is an atomic unit that is signed by a single entity and contains multiple (what I thought of as an assertion) statements about an individual. When I was dealing with the question of responses - I was only thinking of a query/response protocol rather than just an xml data carrying unit. > -----Original Message----- > From: Sam Hartman [mailto:hartmans@painless-security.com] > Sent: Tuesday, December 14, 2010 2:21 PM > To: Jim Schaad > Cc: abfab@ietf.org > Subject: Re: [abfab] Passing multiple SAML statements > > >>>>> "Jim" == Jim Schaad writes: > > Jim> At the f2f meeting, I said that I thought it was important that > Jim> we have the ability to pass multiple SASL statements as part of > Jim> the AAA system. I still think this is a requirement. > Do you think multiple SAML responses are needed or simply a single response > containing potentially multiple assertions? I believe that one needs to be able to get multiple SAML assertions - from different entities - for some policies to be correctly enforced. This is because a single assertion issuer may not be authoritative for all statements. > > I'm in favor of multiple assertions in a response. > I think that supporting multiple responses provides significant trust complexity, > especially if the responses are from different parties. > This complexity is amplified when we try and provide access to applications. > So, I'd prefer to avoid it. I don't see a great complexity being added unless that enforcement policy needs it. For most applications it is sufficient for a single entity to be able to issue the statements. However, I don't believe that it is sufficient. If one looks at the old X.509 world there is a distinction that was made between identity certificates and attribute certificates for a reason. > > > > Jim> A response was given from the chat room that this required that > Jim> a query/response be given as well. I have been thinking on > Jim> this both in this context and in a different context and I have > Jim> come to the conclusion that I disagree with that statement. > > I also believe that supporting multiple assertions (or even multiple > responses) does not require a server query. > > Jim> It > Jim> may be useful for a server to be able to do a query for > Jim> additional SASL statements but it is hardly required as there > Jim> are a number of ways this could be handled. One way would be > > This makes no sense at all. > > The party sending the access-reject is the same party who would send the > SAML responses in the access-accept case. It makes no sense for that party to > send an access-reject saying "here are other statements you would need. I > decided not to provide them so I denied your access." If this is true then I have fundamentally mis-understood the entire model and need to go back and re-read it. I was assuming that what happens is that I send a request to a service, supplying credentials in the form of SAML assertions and that service will either accept or reject my request based on the supplied credentials. In that case the entity supplying the service could say you are denied because you did not give me an X credential, or just ask back for one using a query/response protocol either to me or yet another party. Jim From hartmans@painless-security.com Tue Dec 14 16:33:50 2010 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 740BD3A6E13 for ; Tue, 14 Dec 2010 16:33:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.502 X-Spam-Level: X-Spam-Status: No, score=-2.502 tagged_above=-999 required=5 tests=[AWL=-0.237, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id go5+G55r5vub for ; Tue, 14 Dec 2010 16:33:49 -0800 (PST) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by core3.amsl.com (Postfix) with ESMTP id CAFB83A6E0F for ; Tue, 14 Dec 2010 16:33:49 -0800 (PST) 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 3BCC72029D; Tue, 14 Dec 2010 19:34:26 -0500 (EST) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id AA9914060; Tue, 14 Dec 2010 19:35:18 -0500 (EST) From: Sam Hartman To: "Jim Schaad" References: <02f801cb9bdd$4422f350$cc68d9f0$@augustcellars.com> <02fe01cb9be6$cb34ce50$619e6af0$@augustcellars.com> Date: Tue, 14 Dec 2010 19:35:18 -0500 In-Reply-To: <02fe01cb9be6$cb34ce50$619e6af0$@augustcellars.com> (Jim Schaad's message of "Tue, 14 Dec 2010 15:29:45 -0800") 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] Passing multiple SAML statements X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 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, 15 Dec 2010 00:33:50 -0000 Jim, I believe it will be quite challenging to support assertions from multiple different issuers in the initial ABFAb authentication. It sounds like you want to support this. I'm going to ask you to work through the details especially at the behavior of the GSS acceptor and of the interactions with GSS name attributes. Once you've worked through that then I think we can evaluate the complexity tradeoff. I'm happy to help you understand the current state so you can understand how it would need to change. Does this sound fair? --Sam From ietf@augustcellars.com Tue Dec 14 16:54:54 2010 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 73D803A6E22 for ; Tue, 14 Dec 2010 16:54:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.552 X-Spam-Level: X-Spam-Status: No, score=-2.552 tagged_above=-999 required=5 tests=[AWL=0.047, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LOT--6b7zuRD for ; Tue, 14 Dec 2010 16:54:53 -0800 (PST) Received: from new-smtp01.pacifier.net (new-smtp01.pacifier.net [64.255.237.177]) by core3.amsl.com (Postfix) with ESMTP id BB81C3A6E1D for ; Tue, 14 Dec 2010 16:54:53 -0800 (PST) Received: from TITUS (unknown [207.202.179.27]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by new-smtp01.pacifier.net (Postfix) with ESMTPSA id C5CE92CA0C; Tue, 14 Dec 2010 16:56:34 -0800 (PST) From: "Jim Schaad" To: "'Sam Hartman'" References: <02f801cb9bdd$4422f350$cc68d9f0$@augustcellars.com> <02fe01cb9be6$cb34ce50$619e6af0$@augustcellars.com> In-Reply-To: Date: Tue, 14 Dec 2010 17:12:06 -0800 Message-ID: <030701cb9bf5$17aba9d0$4702fd70$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQFHACtfJms4F60bU0rWOn4oVwvMpAGHvBctAgVltS8CK3qKUJR8JO4Q Content-Language: en-us Cc: abfab@ietf.org Subject: Re: [abfab] Passing multiple SAML statements X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 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, 15 Dec 2010 00:54:54 -0000 That sounds fair. > -----Original Message----- > From: Sam Hartman [mailto:hartmans@painless-security.com] > Sent: Tuesday, December 14, 2010 4:35 PM > To: Jim Schaad > Cc: abfab@ietf.org > Subject: Re: [abfab] Passing multiple SAML statements > > Jim, I believe it will be quite challenging to support assertions from multiple > different issuers in the initial ABFAb authentication. > > It sounds like you want to support this. I'm going to ask you to work through the > details especially at the behavior of the GSS acceptor and of the interactions > with GSS name attributes. > Once you've worked through that then I think we can evaluate the complexity > tradeoff. > > I'm happy to help you understand the current state so you can understand how > it would need to change. > > Does this sound fair? > > --Sam From Josh.Howlett@ja.net Wed Dec 15 01:01:53 2010 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 290493A6FEF for ; Wed, 15 Dec 2010 01:01:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.241 X-Spam-Level: X-Spam-Status: No, score=-102.241 tagged_above=-999 required=5 tests=[AWL=0.358, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9P56INgOYRAa for ; Wed, 15 Dec 2010 01:01:52 -0800 (PST) Received: from har003676.ukerna.ac.uk (har003676.ukerna.ac.uk [194.82.140.75]) by core3.amsl.com (Postfix) with ESMTP id 4F5393A6FEC for ; Wed, 15 Dec 2010 01:01:52 -0800 (PST) Received: from har003676.ukerna.ac.uk (localhost.localdomain [127.0.0.1]) by localhost (Email Security Appliance) with SMTP id 063DE4A6B66_D088465B; Wed, 15 Dec 2010 09:03:33 +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 E97754A6B3B_D088462F; Wed, 15 Dec 2010 09:03:30 +0000 (GMT) Received: from EXC001.atlas.ukerna.ac.uk ([193.62.83.37]) by EXC001 ([193.62.83.37]) with mapi; Wed, 15 Dec 2010 09:03:48 +0000 From: Josh Howlett To: Sam Hartman , Jim Schaad Thread-Topic: [abfab] Passing multiple SAML statements Thread-Index: AQHLm+/yhZB3v5Yve0KQcu+FlOT3IpOhJ2VQ Date: Wed, 15 Dec 2010 09:03:47 +0000 Message-ID: <55DC663C2F4F9F439F23543E0078E8B304170C@EXC001> References: <02f801cb9bdd$4422f350$cc68d9f0$@augustcellars.com> <02fe01cb9be6$cb34ce50$619e6af0$@augustcellars.com> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Josh Howlett , "abfab@ietf.org" Subject: Re: [abfab] Passing multiple SAML statements X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 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, 15 Dec 2010 09:01:53 -0000 Sam, I think Jim's requirements can be satisfied with the approach we discussed = in private email a few days ago with Luke: SAML Requests and Responses tran= sported in a distinct AAA transaction that follows the AAA transaction for = the EAP authentication, routed using an NAI that names the subject and the = realm. I think Luke confirmed that the GSS interactions wouldn't be prohibi= tively difficult. A SAML requester can trivially obtain assertions from N providers by invoki= ng the AAA transaction N times. We concluded that a RADIUS Access-Request that didn't contain any authentic= ation data (it would only contain the User-Name and the SAML-Message attrib= utes) *might* transgress the spirit of the RADIUS spec. Josh.=20 JANET(UK) is a trading name of The JNT Association, a company limited by guarantee which is registered in England under No. 2881024=20 and whose Registered Office is at Lumen House, Library Avenue, Harwell Science and Innovation Campus, Didcot, Oxfordshire. OX11 0SG From aland@deployingradius.com Wed Dec 15 01:21:19 2010 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C3F4A3A7003 for ; Wed, 15 Dec 2010 01:21:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.583 X-Spam-Level: X-Spam-Status: No, score=-102.583 tagged_above=-999 required=5 tests=[AWL=0.016, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s4uYqDO9CpXV for ; Wed, 15 Dec 2010 01:21:19 -0800 (PST) Received: from liberty.deployingradius.com (liberty.deployingradius.com [88.191.76.128]) by core3.amsl.com (Postfix) with ESMTP id D3B443A7002 for ; Wed, 15 Dec 2010 01:21:18 -0800 (PST) Message-ID: <4D0888F2.8060606@deployingradius.com> Date: Wed, 15 Dec 2010 10:22:58 +0100 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Josh Howlett References: <02f801cb9bdd$4422f350$cc68d9f0$@augustcellars.com> <02fe01cb9be6$cb34ce50$619e6af0$@augustcellars.com> <55DC663C2F4F9F439F23543E0078E8B304170C@EXC001> In-Reply-To: <55DC663C2F4F9F439F23543E0078E8B304170C@EXC001> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Jim Schaad , "abfab@ietf.org" Subject: Re: [abfab] Passing multiple SAML statements X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 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, 15 Dec 2010 09:21:19 -0000 Josh Howlett wrote: > We concluded that a RADIUS Access-Request that didn't contain any authentication data (it would only contain the User-Name and the SAML-Message attributes) *might* transgress the spirit of the RADIUS spec. Yes. What *is* possible is to have an initial authentication, and then to have the Access-Accept contain a State attribute. Subsequent *authorizations* can use that State, along with "Service-Type = Authorize-Only", to get additional / different authorizations. This is deployed and is allowed by the specs, but isn't described in detail anywhere. Alan DeKok. From Josh.Howlett@ja.net Wed Dec 15 01:37:58 2010 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B1EF83A7003 for ; Wed, 15 Dec 2010 01:37:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.286 X-Spam-Level: X-Spam-Status: No, score=-102.286 tagged_above=-999 required=5 tests=[AWL=0.313, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w1f3dOn-SgMw for ; Wed, 15 Dec 2010 01:37:57 -0800 (PST) Received: from har003676.ukerna.ac.uk (har003676.ukerna.ac.uk [194.82.140.75]) by core3.amsl.com (Postfix) with ESMTP id BACE93A700B for ; Wed, 15 Dec 2010 01:37:57 -0800 (PST) Received: from har003676.ukerna.ac.uk (localhost.localdomain [127.0.0.1]) by localhost (Email Security Appliance) with SMTP id 1DECA4A6B66_D088CDBB; Wed, 15 Dec 2010 09:39:39 +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 0695D4A6B4E_D088CD8F; Wed, 15 Dec 2010 09:39:36 +0000 (GMT) Received: from EXC001.atlas.ukerna.ac.uk ([193.62.83.37]) by EXC001 ([193.62.83.37]) with mapi; Wed, 15 Dec 2010 09:39:53 +0000 From: Josh Howlett To: Alan DeKok Thread-Topic: [abfab] Passing multiple SAML statements Thread-Index: AQHLm+/yhZB3v5Yve0KQcu+FlOT3IpOhJ2VQgAAUDQCAAAOSIA== Date: Wed, 15 Dec 2010 09:39:33 +0000 Message-ID: <55DC663C2F4F9F439F23543E0078E8B3041826@EXC001> References: <02f801cb9bdd$4422f350$cc68d9f0$@augustcellars.com> <02fe01cb9be6$cb34ce50$619e6af0$@augustcellars.com> <55DC663C2F4F9F439F23543E0078E8B304170C@EXC001> <4D0888F2.8060606@deployingradius.com> In-Reply-To: <4D0888F2.8060606@deployingradius.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Josh Howlett , Jim Schaad , "abfab@ietf.org" Subject: Re: [abfab] Passing multiple SAML statements X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 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, 15 Dec 2010 09:37:58 -0000 > > We concluded that a RADIUS Access-Request that didn't contain any > > authentication data (it would only contain the User-Name and the SAML- > > Message attributes) *might* transgress the spirit of the RADIUS spec. >=20 > Yes. >=20 > What *is* possible is to have an initial authentication, and then to > have the Access-Accept contain a State attribute. Subsequent > *authorizations* can use that State, along with "Service-Type =3D > Authorize-Only", to get additional / different authorizations. And these subsequent authorisations are requested in a RADIUS Access-Reques= t message? Thanks, Josh. JANET(UK) is a trading name of The JNT Association, a company limited by guarantee which is registered in England under No. 2881024=20 and whose Registered Office is at Lumen House, Library Avenue, Harwell Science and Innovation Campus, Didcot, Oxfordshire. OX11 0SG From aland@deployingradius.com Wed Dec 15 02:46:19 2010 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D911328C15F for ; Wed, 15 Dec 2010 02:46:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.585 X-Spam-Level: X-Spam-Status: No, score=-102.585 tagged_above=-999 required=5 tests=[AWL=0.014, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t+jR7iz0AOwZ for ; Wed, 15 Dec 2010 02:46:19 -0800 (PST) Received: from liberty.deployingradius.com (liberty.deployingradius.com [88.191.76.128]) by core3.amsl.com (Postfix) with ESMTP id 11DAB28C115 for ; Wed, 15 Dec 2010 02:46:19 -0800 (PST) Message-ID: <4D089CE0.1060203@deployingradius.com> Date: Wed, 15 Dec 2010 11:48:00 +0100 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Josh Howlett References: <02f801cb9bdd$4422f350$cc68d9f0$@augustcellars.com> <02fe01cb9be6$cb34ce50$619e6af0$@augustcellars.com> <55DC663C2F4F9F439F23543E0078E8B304170C@EXC001> <4D0888F2.8060606@deployingradius.com> <55DC663C2F4F9F439F23543E0078E8B3041826@EXC001> In-Reply-To: <55DC663C2F4F9F439F23543E0078E8B3041826@EXC001> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Jim Schaad , "abfab@ietf.org" Subject: Re: [abfab] Passing multiple SAML statements X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 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, 15 Dec 2010 10:46:20 -0000 Josh Howlett wrote: >> What *is* possible is to have an initial authentication, and then to >> have the Access-Accept contain a State attribute. Subsequent >> *authorizations* can use that State, along with "Service-Type = >> Authorize-Only", to get additional / different authorizations. > > And these subsequent authorisations are requested in a RADIUS Access-Request message? Yes. They should also include "session identification attributes", like User-Name, and anything else that might seem useful... Alan DeKok. From Josh.Howlett@ja.net Wed Dec 15 03:40:24 2010 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4D43328C0D8 for ; Wed, 15 Dec 2010 03:40:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.32 X-Spam-Level: X-Spam-Status: No, score=-102.32 tagged_above=-999 required=5 tests=[AWL=0.279, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L2GYpFheiE50 for ; Wed, 15 Dec 2010 03:40:23 -0800 (PST) Received: from har003676.ukerna.ac.uk (har003676.ukerna.ac.uk [194.82.140.75]) by core3.amsl.com (Postfix) with ESMTP id 4178C3A703B for ; Wed, 15 Dec 2010 03:40:23 -0800 (PST) Received: from har003676.ukerna.ac.uk (localhost.localdomain [127.0.0.1]) by localhost (Email Security Appliance) with SMTP id 50F374A6B9E_D08A98CB; Wed, 15 Dec 2010 11:42:04 +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 3DE024A6B75_D08A989F; Wed, 15 Dec 2010 11:42:01 +0000 (GMT) Received: from EXC001.atlas.ukerna.ac.uk ([193.62.83.37]) by EXC001 ([193.62.83.37]) with mapi; Wed, 15 Dec 2010 11:42:18 +0000 From: Josh Howlett To: Alan DeKok Thread-Topic: [abfab] Passing multiple SAML statements Thread-Index: AQHLm+/yhZB3v5Yve0KQcu+FlOT3IpOhJ2VQgAAUDQCAACVcsA== Date: Wed, 15 Dec 2010 11:41:58 +0000 Message-ID: <55DC663C2F4F9F439F23543E0078E8B3041A27@EXC001> References: <02f801cb9bdd$4422f350$cc68d9f0$@augustcellars.com> <02fe01cb9be6$cb34ce50$619e6af0$@augustcellars.com> <55DC663C2F4F9F439F23543E0078E8B304170C@EXC001> <4D0888F2.8060606@deployingradius.com> In-Reply-To: <4D0888F2.8060606@deployingradius.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Josh Howlett , Jim Schaad , "abfab@ietf.org" Subject: Re: [abfab] Passing multiple SAML statements X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 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, 15 Dec 2010 11:40:24 -0000 > What *is* possible is to have an initial authentication, and then to > have the Access-Accept contain a State attribute. Subsequent > *authorizations* can use that State, along with "Service-Type =3D > Authorize-Only", to get additional / different authorizations. >=20 > This is deployed and is allowed by the specs, but isn't described in > detail anywhere. Is it described in at least /some/ level of detail somewhere, or should I g= o read the FreeRADIUS source? Josh. JANET(UK) is a trading name of The JNT Association, a company limited by guarantee which is registered in England under No. 2881024=20 and whose Registered Office is at Lumen House, Library Avenue, Harwell Science and Innovation Campus, Didcot, Oxfordshire. OX11 0SG From aland@deployingradius.com Wed Dec 15 03:51:53 2010 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DAD7428C103 for ; Wed, 15 Dec 2010 03:51:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.585 X-Spam-Level: X-Spam-Status: No, score=-102.585 tagged_above=-999 required=5 tests=[AWL=0.014, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XRGAlGRuHMn7 for ; Wed, 15 Dec 2010 03:51:53 -0800 (PST) Received: from liberty.deployingradius.com (liberty.deployingradius.com [88.191.76.128]) by core3.amsl.com (Postfix) with ESMTP id 258FE28C0D8 for ; Wed, 15 Dec 2010 03:51:53 -0800 (PST) Message-ID: <4D08AC3E.7030403@deployingradius.com> Date: Wed, 15 Dec 2010 12:53:34 +0100 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Josh Howlett References: <02f801cb9bdd$4422f350$cc68d9f0$@augustcellars.com> <02fe01cb9be6$cb34ce50$619e6af0$@augustcellars.com> <55DC663C2F4F9F439F23543E0078E8B304170C@EXC001> <4D0888F2.8060606@deployingradius.com> <55DC663C2F4F9F439F23543E0078E8B3041A27@EXC001> In-Reply-To: <55DC663C2F4F9F439F23543E0078E8B3041A27@EXC001> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Jim Schaad , "abfab@ietf.org" Subject: Re: [abfab] Passing multiple SAML statements X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 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, 15 Dec 2010 11:51:53 -0000 Josh Howlett wrote: >> This is deployed and is allowed by the specs, but isn't described in >> detail anywhere. > > Is it described in at least /some/ level of detail somewhere, or should I go read the FreeRADIUS source? It's hinted at in various places. RFC 5080, Section 2.1.1. RFC 5176 Section 3.2 discusses it, but in the context of CoA packets. RFC 5580 discusses it, too. There are no configuration examples available because it's not widely used outside of large WiMAX and 3G systems. Alan DeKok. From hartmans@painless-security.com Thu Dec 16 11:45:56 2010 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3D03A3A6949 for ; Thu, 16 Dec 2010 11:45:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.468 X-Spam-Level: X-Spam-Status: No, score=-2.468 tagged_above=-999 required=5 tests=[AWL=-0.203, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZZi86hHZCxK7 for ; Thu, 16 Dec 2010 11:45:55 -0800 (PST) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by core3.amsl.com (Postfix) with ESMTP id 58A8B3A6924 for ; Thu, 16 Dec 2010 11:45:55 -0800 (PST) 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 660B82029D for ; Thu, 16 Dec 2010 14:46:32 -0500 (EST) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id ABAAA4060; Thu, 16 Dec 2010 14:47:24 -0500 (EST) From: Sam Hartman To: abfab@ietf.org Date: Thu, 16 Dec 2010 14:47:24 -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 Subject: [abfab] SAML attribute queries: AAA or SOAP X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 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, 16 Dec 2010 19:45:56 -0000 Josh has been pondering some of the longer-term scalability issues of ABFAB and SAML. In order for SAML communication to happen, the entities involved need SAML metadata. For example, an RP needs metadata in order to know how to contact an IDP and in order to understand scope restrictions on identifiers used by an IDP. We'd been assuming that we would eventually need to build a protocol to exchange SAML metadata in a scalable manner leveraging the AAA fabric. However, Josh has recently been exploring the idea of simply using SAML over the AAA fabric directly. As Josh and Alan discussed earlier this week, RADIUS supports an authorization-only service that can be used to request additional authorization information. It's my understanding that Diameter applications can do something similar. So, Josh is proposing that we permit sending SAML attribute queries over AAA transport. An application would decide it needed attributes and this would generate a authorization only request for these attributes; the response would be processed. Josh is hoping to get away without needing SAML metadata. This is similar in motivation to a previous proposal we had: the alternative security mechanism. In that proposal, we used AAA to set up keys for SAML messages. We dropped that proposal because other aspects of the metadata that we'd need were not handled by that proposal and because the scalable metadata protocol would be a better approach.. One question is to what extent does using AAA as a transport for SAML messages actually address all the reasons we need metadata. Another question is is this actually easier to specify and implement than a metadata distribution protocol. I'm bringing this up now to get Scott, Leif and others into the discussion. I'm sure I'm leaving details out; in many cases it's because I don't have them. We just went over the general proposal on a call this morning. Also, I'm not entirely sure that this is really an abfab issue rather than a moonshot issue. I decided to post to the IETF list because it may have some standardization implications and I think we'll get a broader group here. --Sam From hartmans@painless-security.com Thu Dec 16 12:34:44 2010 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BB3243A6924 for ; Thu, 16 Dec 2010 12:34:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.443 X-Spam-Level: X-Spam-Status: No, score=-2.443 tagged_above=-999 required=5 tests=[AWL=-0.178, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pzvgpDxja7bd for ; Thu, 16 Dec 2010 12:34:44 -0800 (PST) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by core3.amsl.com (Postfix) with ESMTP id 024B73A6920 for ; Thu, 16 Dec 2010 12:34:44 -0800 (PST) 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 3E495202C9; Thu, 16 Dec 2010 15:35:24 -0500 (EST) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id B3F474060; Thu, 16 Dec 2010 15:36:16 -0500 (EST) From: Sam Hartman To: Nicolas Williams References: <20101213204846.GD29086@oracle.com> Date: Thu, 16 Dec 2010 15:36:16 -0500 In-Reply-To: <20101213204846.GD29086@oracle.com> (Nicolas Williams's message of "Mon, 13 Dec 2010 14:48:46 -0600") 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, mrex@sap.com Subject: Re: [abfab] Should gss-eap support empty target_name X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 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, 16 Dec 2010 20:34:44 -0000 >>>>> "Nicolas" == Nicolas Williams writes: Nicolas> If you just provide a flags field in the initial security Nicolas> context token and some framing in the first reply token, Nicolas> then I think you can revisit this issue later, if you ever Nicolas> need to. But if it's as simple as I'm thinking it is, do Nicolas> it now. My concern about complexity was avoiding the framing in the context token. Currently we have no framing except for the extension token. Adding that involves either always having framing or deciding when not to have framing as well as deciding what to do with tokens received in the framing, etc. However in the grand scheme of things that is not a huge cost. --Sam From Nicolas.Williams@oracle.com Thu Dec 16 12:50:11 2010 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4675F3A696C for ; Thu, 16 Dec 2010 12:50:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.546 X-Spam-Level: X-Spam-Status: No, score=-6.546 tagged_above=-999 required=5 tests=[AWL=0.052, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VKTzUul5FmJz for ; Thu, 16 Dec 2010 12:50:08 -0800 (PST) Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by core3.amsl.com (Postfix) with ESMTP id 566203A695B for ; Thu, 16 Dec 2010 12:50:08 -0800 (PST) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id oBGKpqBV023700 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 16 Dec 2010 20:51:53 GMT Received: from acsmt354.oracle.com (acsmt354.oracle.com [141.146.40.154]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id oBGKllBx013573; Thu, 16 Dec 2010 20:51:51 GMT Received: from abhmt007.oracle.com by acsmt353.oracle.com with ESMTP id 860821911292532709; Thu, 16 Dec 2010 12:51:49 -0800 Received: from oracle.com (/10.135.188.51) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 16 Dec 2010 12:51:48 -0800 Date: Thu, 16 Dec 2010 14:51:48 -0600 From: Nicolas Williams To: Sam Hartman Message-ID: <20101216205147.GA1091@oracle.com> References: <20101213204846.GD29086@oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2010-03-02) Cc: abfab@ietf.org, mrex@sap.com Subject: Re: [abfab] Should gss-eap support empty target_name X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 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, 16 Dec 2010 20:50:11 -0000 On Thu, Dec 16, 2010 at 03:36:16PM -0500, Sam Hartman wrote: > Nicolas> If you just provide a flags field in the initial security > Nicolas> context token and some framing in the first reply token, > Nicolas> then I think you can revisit this issue later, if you ever > Nicolas> need to. But if it's as simple as I'm thinking it is, do > Nicolas> it now. > > My concern about complexity was avoiding the framing in the context > token. Currently we have no framing except for the extension token. > Adding that involves either always having framing or deciding when not > to have framing as well as deciding what to do with tokens received in > the framing, etc. > > However in the grand scheme of things that is not a huge cost. You're reminding me about the 640KB problem. Why paint yourself into a corner? Just to save a few branches?? Economically, I don't see the point. Nico -- From leifj@sunet.se Thu Dec 16 13:17:41 2010 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9F3DF3A69DF for ; Thu, 16 Dec 2010 13:17:41 -0800 (PST) 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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KneuLD7jkbq0 for ; Thu, 16 Dec 2010 13:17:40 -0800 (PST) Received: from backup-server.nordu.net (backup-server.nordu.net [IPv6:2001:948:4:1::66]) by core3.amsl.com (Postfix) with ESMTP id 706863A6934 for ; Thu, 16 Dec 2010 13:17:40 -0800 (PST) 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 oBGLJKuR011488 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 16 Dec 2010 22:19:24 +0100 (CET) Message-ID: <4D0A8258.9080501@sunet.se> Date: Thu, 16 Dec 2010 22:19:20 +0100 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.13) Gecko/20101208 Lightning/1.0b2 Thunderbird/3.1.7 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] SAML attribute queries: AAA or SOAP X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 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, 16 Dec 2010 21:17:41 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 With no chair hat on whatsoever ... That depends on what you think you want metadata for. If you only think about metadata as a way to provide location-identifier indepencence then you may be right that SAML over AAA is good enough. However SAML metadata gets you a bunch of things beyond a well known protocol endpoint. One of them is key-management but other things might also become important for abfab eventually such as contact information and various UI hints. Cheers Leif -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEUEARECAAYFAk0Kgk8ACgkQ8Jx8FtbMZneVpACfVlC8ImqexkqPjWhV4qm4IeZy jJoAmMKd8leqmhdl2vlpCPFtyaqwp74= =1org -----END PGP SIGNATURE----- From leifj@sunet.se Thu Dec 16 13:17:41 2010 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AF8203A6934 for ; Thu, 16 Dec 2010 13:17:41 -0800 (PST) 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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zDCz8TCAUUvg for ; Thu, 16 Dec 2010 13:17:40 -0800 (PST) Received: from backup-server.nordu.net (backup-server.nordu.net [IPv6:2001:948:4:1::66]) by core3.amsl.com (Postfix) with ESMTP id 706F63A69DE for ; Thu, 16 Dec 2010 13:17:40 -0800 (PST) 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 oBGLJKAr029545 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 16 Dec 2010 22:19:24 +0100 (CET) Message-ID: <4D0A8258.3070302@sunet.se> Date: Thu, 16 Dec 2010 22:19:20 +0100 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.13) Gecko/20101208 Lightning/1.0b2 Thunderbird/3.1.7 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] SAML attribute queries: AAA or SOAP X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 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, 16 Dec 2010 21:17:41 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 With no chair hat on whatsoever ... > One question is to what extent does using AAA as a transport for SAML > messages actually address all the reasons we need metadata. Another > question is is this actually easier to specify and implement than a > metadata distribution protocol. That depends on what you think you want metadata for. If you only think about metadata as a way to provide location-identifier indepencence then you may be right that SAML over AAA is good enough. However SAML metadata gets you a bunch of things beyond a well known protocol endpoint. One of them is key-management but other things might also become important for abfab eventually such as contact information and various UI hints. Cheers Leif -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk0KglAACgkQ8Jx8FtbMZneZ7gCfY6zAbCHIwhXFOHRXmTx1Qp40 8W4An3oiknHvqE2RKG2wZJ4mny6+2OLf =4+o1 -----END PGP SIGNATURE----- From hartmans@painless-security.com Thu Dec 16 13:21:35 2010 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 491CA3A691D for ; Thu, 16 Dec 2010 13:21:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.423 X-Spam-Level: X-Spam-Status: No, score=-2.423 tagged_above=-999 required=5 tests=[AWL=-0.158, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZVFiDVe73qbr for ; Thu, 16 Dec 2010 13:21:34 -0800 (PST) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by core3.amsl.com (Postfix) with ESMTP id 7C3EA3A68E1 for ; Thu, 16 Dec 2010 13:21:34 -0800 (PST) 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 C19B92016B; Thu, 16 Dec 2010 16:22:12 -0500 (EST) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 449784060; Thu, 16 Dec 2010 16:23:05 -0500 (EST) From: Sam Hartman To: Leif Johansson References: <4D0A8258.3070302@sunet.se> Date: Thu, 16 Dec 2010 16:23:05 -0500 In-Reply-To: <4D0A8258.3070302@sunet.se> (Leif Johansson's message of "Thu, 16 Dec 2010 22:19:20 +0100") 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] SAML attribute queries: AAA or SOAP X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 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, 16 Dec 2010 21:21:35 -0000 >>>>> "Leif" == Leif Johansson writes: Leif> With no chair hat on whatsoever ... >> One question is to what extent does using AAA as a transport for >> SAML messages actually address all the reasons we need metadata. >> Another question is is this actually easier to specify and >> implement than a metadata distribution protocol. Leif> That depends on what you think you want metadata for. If you Leif> only think about metadata as a way to provide Leif> location-identifier indepencence then you may be right that Leif> SAML over AAA is good enough. Leif> However SAML metadata gets you a bunch of things beyond a well Leif> known protocol endpoint. One of them is key-management but Leif> other things might also become important for abfab eventually Leif> such as contact information and various UI hints. And this is the discussion I want to see happen here. I'm not going to be much of a participant; I don't have the background. From cantor.2@osu.edu Thu Dec 16 13:24:37 2010 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8BECA3A69CD for ; Thu, 16 Dec 2010 13:24:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.554 X-Spam-Level: X-Spam-Status: No, score=-3.554 tagged_above=-999 required=5 tests=[AWL=0.045, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8CEVmT+eShom for ; Thu, 16 Dec 2010 13:24:36 -0800 (PST) Received: from defang3.it.ohio-state.edu (defang3.it.ohio-state.edu [128.146.216.83]) by core3.amsl.com (Postfix) with ESMTP id A64833A68E1 for ; Thu, 16 Dec 2010 13:24:36 -0800 (PST) Received: from CIO-KRC-HT01.osuad.osu.edu ([164.107.81.38]) by defang3.it.ohio-state.edu (8.13.7/8.13.1) with ESMTP id oBGLQKwS011559; Thu, 16 Dec 2010 16:26:21 -0500 Received: from CIO-KRC-D1MBX01.osuad.osu.edu ([fe80::450b:35e6:80f4:f3e0]) by CIO-KRC-HT01.osuad.osu.edu ([2002:a46b:5126::a46b:5126]) with mapi; Thu, 16 Dec 2010 16:23:30 -0500 From: "Cantor, Scott E." To: Leif Johansson , "abfab@ietf.org" Thread-Topic: [abfab] SAML attribute queries: AAA or SOAP Thread-Index: AQHLnVm5XAXmTCqpM0utngdemQ5X+pOj5uwA//+tBtA= Date: Thu, 16 Dec 2010 21:26:19 +0000 Message-ID: <7EE86E89365CA94F8E7B8251F92607100227A9@CIO-KRC-D1MBX01.osuad.osu.edu> References: <4D0A8258.9080501@sunet.se> In-Reply-To: <4D0A8258.9080501@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-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CanIt-Geo: ip=164.107.81.38; country=US; region=OH; city=Wooster; postalcode=44691; latitude=40.8077; longitude=-81.9730; metrocode=510; areacode=330; http://maps.google.com/maps?q=40.8077,-81.9730&z=6 X-CanItPRO-Stream: outbound X-Scanned-By: CanIt (www . roaringpenguin . com) on 128.146.216.83 Subject: Re: [abfab] SAML attribute queries: AAA or SOAP X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 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, 16 Dec 2010 21:24:37 -0000 > However SAML metadata gets you a bunch of things beyond a well known > protocol endpoint. One of them is key-management but other things might > also become important for abfab eventually such as contact information > and various UI hints. I think Moonshot at least has been on record looking for AAA alternatives t= o metadata-based key management, so I doubt that's a selling point. A lot of the typical uses probably go away if the AAA infrastructure handle= s everything. Attribute policy might be an exception, but metadata isn't th= e only way to drive that (and that's typically attribute *source* metadata,= and the usual complaints about using metadata relate to the relying party = having to make it available to the IdP/AA, not the other way around. Even O= penID doesn't pretend knowing the OP is somehow irrelevant.) I suspect that this would be an adequate substitute for relying party metad= ata, and that metadata for the other end would be needed less, and could st= ill be provided without complicating things very much. -- Scott From hartmans@painless-security.com Thu Dec 16 13:25:11 2010 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D8C0A3A69CA for ; Thu, 16 Dec 2010 13:25:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.407 X-Spam-Level: X-Spam-Status: No, score=-2.407 tagged_above=-999 required=5 tests=[AWL=-0.142, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tOem4wU1p5cs for ; Thu, 16 Dec 2010 13:25:11 -0800 (PST) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by core3.amsl.com (Postfix) with ESMTP id 466C93A68E1 for ; Thu, 16 Dec 2010 13:25:11 -0800 (PST) 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 0B8A1202C9; Thu, 16 Dec 2010 16:25:52 -0500 (EST) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 4A81A4060; Thu, 16 Dec 2010 16:26:45 -0500 (EST) From: Sam Hartman To: Nicolas Williams References: <20101213204846.GD29086@oracle.com> <20101216205147.GA1091@oracle.com> Date: Thu, 16 Dec 2010 16:26:45 -0500 In-Reply-To: <20101216205147.GA1091@oracle.com> (Nicolas Williams's message of "Thu, 16 Dec 2010 14:51:48 -0600") 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, mrex@sap.com Subject: Re: [abfab] Should gss-eap support empty target_name X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 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, 16 Dec 2010 21:25:11 -0000 Any opinions on whether we always frame or never frame? Or should we just use an AVP structure for all tokens with a special AVP for EAP tokens? What's the behavior on receiving something unexpected? --Sam From Nicolas.Williams@oracle.com Thu Dec 16 13:28:39 2010 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3553A3A69DB for ; Thu, 16 Dec 2010 13:28:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.547 X-Spam-Level: X-Spam-Status: No, score=-6.547 tagged_above=-999 required=5 tests=[AWL=0.051, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w1EHP7OLJeuQ for ; Thu, 16 Dec 2010 13:28:38 -0800 (PST) Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by core3.amsl.com (Postfix) with ESMTP id 6B62B3A68E1 for ; Thu, 16 Dec 2010 13:28:38 -0800 (PST) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id oBGLUMib016769 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 16 Dec 2010 21:30:23 GMT Received: from acsmt355.oracle.com (acsmt355.oracle.com [141.146.40.155]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id oBGLUL7i003060; Thu, 16 Dec 2010 21:30:21 GMT Received: from abhmt008.oracle.com by acsmt354.oracle.com with ESMTP id 882231591292535018; Thu, 16 Dec 2010 13:30:18 -0800 Received: from oracle.com (/10.135.188.51) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 16 Dec 2010 13:30:18 -0800 Date: Thu, 16 Dec 2010 15:30:16 -0600 From: Nicolas Williams To: Sam Hartman Message-ID: <20101216213015.GD1091@oracle.com> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2010-03-02) Cc: abfab@ietf.org Subject: Re: [abfab] SAML attribute queries: AAA or SOAP X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 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, 16 Dec 2010 21:28:39 -0000 On Thu, Dec 16, 2010 at 02:47:24PM -0500, Sam Hartman wrote: > One question is to what extent does using AAA as a transport for SAML > messages actually address all the reasons we need metadata. Another > question is is this actually easier to specify and implement than a > metadata distribution protocol. You mention SOAP, but only in the subject line. Would SOAP be the alternative transport? If so, given that you'll need AAA anyways, why add one more protocol to this mix? It certainly wouldn't make implementation easier. Nico -- From cantor.2@osu.edu Thu Dec 16 13:34:10 2010 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3F5BF3A69E6 for ; Thu, 16 Dec 2010 13:34:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.557 X-Spam-Level: X-Spam-Status: No, score=-3.557 tagged_above=-999 required=5 tests=[AWL=0.042, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EzDGbF1KkMzv for ; Thu, 16 Dec 2010 13:34:09 -0800 (PST) Received: from defang11.it.ohio-state.edu (defang11.it.ohio-state.edu [128.146.216.18]) by core3.amsl.com (Postfix) with ESMTP id 601AC3A69CF for ; Thu, 16 Dec 2010 13:34:09 -0800 (PST) Received: from CIO-KRC-HT02.osuad.osu.edu ([164.107.81.41]) by defang11.it.ohio-state.edu (8.13.7/8.13.1) with ESMTP id oBGLZqFB019414; Thu, 16 Dec 2010 16:35:53 -0500 Received: from CIO-KRC-D1MBX01.osuad.osu.edu ([fe80::450b:35e6:80f4:f3e0]) by CIO-KRC-HT02.osuad.osu.edu ([2002:a46b:5129::a46b:5129]) with mapi; Thu, 16 Dec 2010 16:33:03 -0500 From: "Cantor, Scott E." To: Nicolas Williams Thread-Topic: [abfab] SAML attribute queries: AAA or SOAP Thread-Index: AQHLnVm5XAXmTCqpM0utngdemQ5X+pOj6foA//+tNIA= Date: Thu, 16 Dec 2010 21:35:53 +0000 Message-ID: <7EE86E89365CA94F8E7B8251F92607100227ED@CIO-KRC-D1MBX01.osuad.osu.edu> References: <20101216213015.GD1091@oracle.com> In-Reply-To: <20101216213015.GD1091@oracle.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CanIt-Geo: ip=164.107.81.41; country=US; region=OH; city=Wooster; postalcode=44691; latitude=40.8077; longitude=-81.9730; metrocode=510; areacode=330; http://maps.google.com/maps?q=40.8077,-81.9730&z=6 X-CanItPRO-Stream: outbound X-Scanned-By: CanIt (www . roaringpenguin . com) on 128.146.216.18 Cc: "abfab@ietf.org" Subject: Re: [abfab] SAML attribute queries: AAA or SOAP X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 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, 16 Dec 2010 21:34:10 -0000 > You mention SOAP, but only in the subject line. Would SOAP be the > alternative transport? If so, given that you'll need AAA anyways, why > add one more protocol to this mix? It certainly wouldn't make > implementation easier. One reason is that all existing SAML standards and code for queries is SOAP= -based, and uses traditonal security mechanisms (signing, TLS). You can reu= se that code and those services, with the attendant implications, or standa= rdize and implement something new. -- Scott From leifj@sunet.se Thu Dec 16 13:34:43 2010 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 658B53A69EF for ; Thu, 16 Dec 2010 13:34:43 -0800 (PST) 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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ifCBfaHIcbcL for ; Thu, 16 Dec 2010 13:34:41 -0800 (PST) Received: from backup-server.nordu.net (backup-server.nordu.net [IPv6:2001:948:4:1::66]) by core3.amsl.com (Postfix) with ESMTP id AE52D3A69CF for ; Thu, 16 Dec 2010 13:34:41 -0800 (PST) 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 oBGLaNrM015550 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 16 Dec 2010 22:36:25 +0100 (CET) Message-ID: <4D0A8657.8080305@sunet.se> Date: Thu, 16 Dec 2010 22:36:23 +0100 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.13) Gecko/20101208 Lightning/1.0b2 Thunderbird/3.1.7 MIME-Version: 1.0 To: "Cantor, Scott E." References: <4D0A8258.9080501@sunet.se> <7EE86E89365CA94F8E7B8251F92607100227A9@CIO-KRC-D1MBX01.osuad.osu.edu> In-Reply-To: <7EE86E89365CA94F8E7B8251F92607100227A9@CIO-KRC-D1MBX01.osuad.osu.edu> 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] SAML attribute queries: AAA or SOAP X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 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, 16 Dec 2010 21:34:43 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 12/16/2010 10:26 PM, Cantor, Scott E. wrote: >> However SAML metadata gets you a bunch of things beyond a well known >> protocol endpoint. One of them is key-management but other things might >> also become important for abfab eventually such as contact information >> and various UI hints. > > I think Moonshot at least has been on record looking for AAA alternatives to metadata-based key management, so I doubt that's a selling point. > > A lot of the typical uses probably go away if the AAA infrastructure handles everything. Attribute policy might be an exception, but metadata isn't the only way to drive that (and that's typically attribute *source* metadata, and the usual complaints about using metadata relate to the relying party having to make it available to the IdP/AA, not the other way around. Even OpenID doesn't pretend knowing the OP is somehow irrelevant.) > > I suspect that this would be an adequate substitute for relying party metadata, and that metadata for the other end would be needed less, and could still be provided without complicating things very much. I have a feeling som of the UI hints that people have been talking about will turn out to be important for rendering something sensible to the user in the login dialog. I'm not sure where the complexity break-even point is for keeping metadata in the mix though. Cheers Leif -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk0KhlYACgkQ8Jx8FtbMZnfDhACgvgvUTtO8p7oQBPRMdKy9YG3/ FUYAnR+RflB+xwoAEvBdorbpZ0hwwSfV =yM+b -----END PGP SIGNATURE----- From cantor.2@osu.edu Thu Dec 16 13:36:42 2010 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6D0153A69F5 for ; Thu, 16 Dec 2010 13:36:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.561 X-Spam-Level: X-Spam-Status: No, score=-3.561 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eoiWUW09pl7F for ; Thu, 16 Dec 2010 13:36:41 -0800 (PST) Received: from defang12.it.ohio-state.edu (defang12.it.ohio-state.edu [128.146.216.21]) by core3.amsl.com (Postfix) with ESMTP id 8AFB03A69F3 for ; Thu, 16 Dec 2010 13:36:41 -0800 (PST) Received: from CIO-TNC-HT05.osuad.osu.edu (cio-tnc-ht05.osuad.osu.edu [164.107.81.168]) by defang12.it.ohio-state.edu (8.13.7/8.13.1) with ESMTP id oBGLcQPJ030961; Thu, 16 Dec 2010 16:38:26 -0500 Received: from CIO-KRC-D1MBX01.osuad.osu.edu ([fe80::450b:35e6:80f4:f3e0]) by CIO-TNC-HT05.osuad.osu.edu ([fe80::28c9:db48:3fa3:b384%24]) with mapi; Thu, 16 Dec 2010 16:35:36 -0500 From: "Cantor, Scott E." To: Leif Johansson Thread-Topic: [abfab] SAML attribute queries: AAA or SOAP Thread-Index: AQHLnVm5XAXmTCqpM0utngdemQ5X+pOj5uwA//+tBtCAAFe9gP//rF+A Date: Thu, 16 Dec 2010 21:38:26 +0000 Message-ID: <7EE86E89365CA94F8E7B8251F9260710022813@CIO-KRC-D1MBX01.osuad.osu.edu> References: <4D0A8258.9080501@sunet.se> <7EE86E89365CA94F8E7B8251F92607100227A9@CIO-KRC-D1MBX01.osuad.osu.edu> <4D0A8657.8080305@sunet.se> In-Reply-To: <4D0A8657.8080305@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-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CanIt-Geo: ip=164.107.81.168; country=US; region=OH; city=Wooster; postalcode=44691; latitude=40.8077; longitude=-81.9730; metrocode=510; areacode=330; http://maps.google.com/maps?q=40.8077,-81.9730&z=6 X-CanItPRO-Stream: outbound X-Scanned-By: CanIt (www . roaringpenguin . com) on 128.146.216.21 Cc: "abfab@ietf.org" Subject: Re: [abfab] SAML attribute queries: AAA or SOAP X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 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, 16 Dec 2010 21:36:42 -0000 > I have a feeling som of the UI hints that people have been talking about > will turn out to be important for rendering something sensible to the > user in the login dialog. Maybe, but I don't think there's the same discovery aspect here, and unless= there's a way to handle user consent in the flow, I don't know what you'd = be presenting or for what purpose yet. -- Scott From Nicolas.Williams@oracle.com Thu Dec 16 13:47:59 2010 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C74093A69F3 for ; Thu, 16 Dec 2010 13:47:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.547 X-Spam-Level: X-Spam-Status: No, score=-6.547 tagged_above=-999 required=5 tests=[AWL=0.051, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xivFA1Co7CVr for ; Thu, 16 Dec 2010 13:47:59 -0800 (PST) Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by core3.amsl.com (Postfix) with ESMTP id AF5EF3A6A05 for ; Thu, 16 Dec 2010 13:47:56 -0800 (PST) Received: from rcsinet13.oracle.com (rcsinet13.oracle.com [148.87.113.125]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id oBGLneDb023420 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 16 Dec 2010 21:49:42 GMT Received: from acsmt353.oracle.com (acsmt353.oracle.com [141.146.40.153]) by rcsinet13.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id oBGLneYF016999; Thu, 16 Dec 2010 21:49:40 GMT Received: from abhmt020.oracle.com by acsmt353.oracle.com with ESMTP id 861018351292536164; Thu, 16 Dec 2010 13:49:24 -0800 Received: from oracle.com (/10.135.188.51) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 16 Dec 2010 13:49:23 -0800 Date: Thu, 16 Dec 2010 15:49:22 -0600 From: Nicolas Williams To: "Cantor, Scott E." Message-ID: <20101216214922.GF1091@oracle.com> References: <20101216213015.GD1091@oracle.com> <7EE86E89365CA94F8E7B8251F92607100227ED@CIO-KRC-D1MBX01.osuad.osu.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7EE86E89365CA94F8E7B8251F92607100227ED@CIO-KRC-D1MBX01.osuad.osu.edu> User-Agent: Mutt/1.5.20 (2010-03-02) Cc: "abfab@ietf.org" Subject: Re: [abfab] SAML attribute queries: AAA or SOAP X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 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, 16 Dec 2010 21:47:59 -0000 On Thu, Dec 16, 2010 at 09:35:53PM +0000, Cantor, Scott E. wrote: > > You mention SOAP, but only in the subject line. Would SOAP be the > > alternative transport? If so, given that you'll need AAA anyways, why > > add one more protocol to this mix? It certainly wouldn't make > > implementation easier. > > One reason is that all existing SAML standards and code for queries is > SOAP-based, and uses traditonal security mechanisms (signing, TLS). > You can reuse that code and those services, with the attendant > implications, or standardize and implement something new. I understand that that exists and is based on SOAP. The question is whether it can be avoided at the RP. Using AAA as a transport for SAML means it can be avoided at the RP. To me that's a plus. From Nicolas.Williams@oracle.com Thu Dec 16 13:48:59 2010 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4D6F43A69F3 for ; Thu, 16 Dec 2010 13:48:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.548 X-Spam-Level: X-Spam-Status: No, score=-6.548 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0mJRlqila-2L for ; Thu, 16 Dec 2010 13:48:58 -0800 (PST) Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by core3.amsl.com (Postfix) with ESMTP id 7A7E03A6919 for ; Thu, 16 Dec 2010 13:48:58 -0800 (PST) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id oBGLogV7024973 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 16 Dec 2010 21:50:43 GMT Received: from acsmt355.oracle.com (acsmt355.oracle.com [141.146.40.155]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id oBGLocs5032114; Thu, 16 Dec 2010 21:50:42 GMT Received: from abhmt008.oracle.com by acsmt355.oracle.com with ESMTP id 882279791292536062; Thu, 16 Dec 2010 13:47:42 -0800 Received: from oracle.com (/10.135.188.51) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 16 Dec 2010 13:47:41 -0800 Date: Thu, 16 Dec 2010 15:47:40 -0600 From: Nicolas Williams To: Sam Hartman Message-ID: <20101216214740.GE1091@oracle.com> References: <20101213204846.GD29086@oracle.com> <20101216205147.GA1091@oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2010-03-02) Cc: abfab@ietf.org, mrex@sap.com Subject: Re: [abfab] Should gss-eap support empty target_name X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 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, 16 Dec 2010 21:48:59 -0000 On Thu, Dec 16, 2010 at 04:26:45PM -0500, Sam Hartman wrote: > Any opinions on whether we always frame or never frame? > Or should we just use an AVP structure for all tokens with a special AVP > for EAP tokens? > What's the behavior on receiving something unexpected? Good questions. AVP/TLV works for me. It can be optimized for the case where the initiator sent an "empty" [*] initial context token, such that in the case the reply is a naked initial EAP message. The GSS-API does not allow empty tokens. I'm not sure that a token consisting only of the initial context token header is legal, so I assume that you'll need at least a one-byte initial context token. Given the above assumption, I'd say: make the initial context token consist of a 32 bit long bit string, each bit being a flag acting as an attribute name, and follow it with length-value pairs, one per-flag set and in the flags' numerical order. The reply token would be a naked EAP message only when the initiator set no flags, else it would be length-value pairs corresponding to those flags that were set, in the same order, followed by a naked EAP message. Seems simple to me... Most if not all of the GSS context flags can be hardwired. For example you could always get sequence numbers in per-message tokens so replay and OOS detection is always available, and confidentiality protection is always available if the enctype supports it, with the enctype implied by the mechanism OID. But in the future we might get new flags worth negotiating without having to add a new mechanism OID. For this reason, and to support target_name == GSS_C_NO_NAME, I strongly encourage you to add this minimal level of faming. Nico -- From leifj@sunet.se Thu Dec 16 14:10:10 2010 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 04E853A695B for ; Thu, 16 Dec 2010 14:10:10 -0800 (PST) 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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ppsv8vgFVGiz for ; Thu, 16 Dec 2010 14:10:09 -0800 (PST) Received: from backup-server.nordu.net (backup-server.nordu.net [IPv6:2001:948:4:1::66]) by core3.amsl.com (Postfix) with ESMTP id E1AA43A6953 for ; Thu, 16 Dec 2010 14:10:08 -0800 (PST) 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 oBGMBoAn010488 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 16 Dec 2010 23:11:53 +0100 (CET) Message-ID: <4D0A8EA6.6000404@sunet.se> Date: Thu, 16 Dec 2010 23:11:50 +0100 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.13) Gecko/20101208 Lightning/1.0b2 Thunderbird/3.1.7 MIME-Version: 1.0 To: "Cantor, Scott E." References: <4D0A8258.9080501@sunet.se> <7EE86E89365CA94F8E7B8251F92607100227A9@CIO-KRC-D1MBX01.osuad.osu.edu> <4D0A8657.8080305@sunet.se> <7EE86E89365CA94F8E7B8251F9260710022813@CIO-KRC-D1MBX01.osuad.osu.edu> In-Reply-To: <7EE86E89365CA94F8E7B8251F9260710022813@CIO-KRC-D1MBX01.osuad.osu.edu> 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] SAML attribute queries: AAA or SOAP X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 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, 16 Dec 2010 22:10:10 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 12/16/2010 10:38 PM, Cantor, Scott E. wrote: >> I have a feeling som of the UI hints that people have been talking about >> will turn out to be important for rendering something sensible to the >> user in the login dialog. > > Maybe, but I don't think there's the same discovery aspect here, and unless there's a way to handle user consent in the flow, I don't know what you'd be presenting or for what purpose yet. > > -- Scott > I was thinking that since the IdP can't provide its own look and feel it would need a way to inform the client on what logo and contact URLs to display at least. Cheers -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk0KjqYACgkQ8Jx8FtbMZndF3ACcD64D5dfKM8BvXfDrPoUauGJI CQQAnArU3S6m5RxD+l7gVgsb4VfHdJdM =nZbd -----END PGP SIGNATURE----- From hartmans@painless-security.com Thu Dec 16 14:37:58 2010 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5D07C3A69E4 for ; Thu, 16 Dec 2010 14:37:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.394 X-Spam-Level: X-Spam-Status: No, score=-2.394 tagged_above=-999 required=5 tests=[AWL=-0.129, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 10QpBq1iShFl for ; Thu, 16 Dec 2010 14:37:57 -0800 (PST) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by core3.amsl.com (Postfix) with ESMTP id 9CE783A69DE for ; Thu, 16 Dec 2010 14:37:57 -0800 (PST) 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 DF17F2016B; Thu, 16 Dec 2010 17:38:37 -0500 (EST) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 2D0384060; Thu, 16 Dec 2010 17:39:27 -0500 (EST) From: Sam Hartman To: "Cantor\, Scott E." References: <4D0A8258.9080501@sunet.se> <7EE86E89365CA94F8E7B8251F92607100227A9@CIO-KRC-D1MBX01.osuad.osu.edu> Date: Thu, 16 Dec 2010 17:39:27 -0500 In-Reply-To: <7EE86E89365CA94F8E7B8251F92607100227A9@CIO-KRC-D1MBX01.osuad.osu.edu> (Scott E. Cantor's message of "Thu, 16 Dec 2010 21:26:19 +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] SAML attribute queries: AAA or SOAP X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 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, 16 Dec 2010 22:37:58 -0000 One thing that running SAML over AAA does require is a real solution for the AAA MTU problem. We cannot both use attribute query as our response for RADIUS MTU issues and also claim we run attribute queries over RADIUS. --Sam From hartmans@painless-security.com Thu Dec 16 14:39:19 2010 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 592173A69E3 for ; Thu, 16 Dec 2010 14:39:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.384 X-Spam-Level: X-Spam-Status: No, score=-2.384 tagged_above=-999 required=5 tests=[AWL=-0.119, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W+-ndJkude9o for ; Thu, 16 Dec 2010 14:39:18 -0800 (PST) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by core3.amsl.com (Postfix) with ESMTP id AD8163A6934 for ; Thu, 16 Dec 2010 14:39:18 -0800 (PST) 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 93EF0202B3; Thu, 16 Dec 2010 17:39:59 -0500 (EST) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id C63BF4060; Thu, 16 Dec 2010 17:40:52 -0500 (EST) From: Sam Hartman To: Nicolas Williams References: <20101216213015.GD1091@oracle.com> Date: Thu, 16 Dec 2010 17:40:52 -0500 In-Reply-To: <20101216213015.GD1091@oracle.com> (Nicolas Williams's message of "Thu, 16 Dec 2010 15:30:16 -0600") 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] SAML attribute queries: AAA or SOAP X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 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, 16 Dec 2010 22:39:19 -0000 >>>>> "Nicolas" == Nicolas Williams writes: Nicolas> On Thu, Dec 16, 2010 at 02:47:24PM -0500, Sam Hartman wrote: >> One question is to what extent does using AAA as a transport for >> SAML messages actually address all the reasons we need metadata. >> Another question is is this actually easier to specify and >> implement than a metadata distribution protocol. Nicolas> You mention SOAP, but only in the subject line. Would SOAP Nicolas> be the alternative transport? If so, given that you'll Nicolas> need AAA anyways, why add one more protocol to this mix? Nicolas> It certainly wouldn't make implementation easier. SOAP is the transport. However most if not all the SAML libraries can already deal with that. From Nicolas.Williams@oracle.com Thu Dec 16 14:39:36 2010 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 44F0C3A69E3 for ; Thu, 16 Dec 2010 14:39:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.549 X-Spam-Level: X-Spam-Status: No, score=-6.549 tagged_above=-999 required=5 tests=[AWL=0.049, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A+W2v3bcrQ9z for ; Thu, 16 Dec 2010 14:39:35 -0800 (PST) Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by core3.amsl.com (Postfix) with ESMTP id 7249B3A6934 for ; Thu, 16 Dec 2010 14:39:35 -0800 (PST) Received: from rcsinet13.oracle.com (rcsinet13.oracle.com [148.87.113.125]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id oBGMfJpm004118 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 16 Dec 2010 22:41:20 GMT Received: from acsmt353.oracle.com (acsmt353.oracle.com [141.146.40.153]) by rcsinet13.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id oBGMfI8c016180; Thu, 16 Dec 2010 22:41:19 GMT Received: from abhmt020.oracle.com by acsmt353.oracle.com with ESMTP id 882443881292539272; Thu, 16 Dec 2010 14:41:12 -0800 Received: from oracle.com (/10.135.188.51) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 16 Dec 2010 14:41:12 -0800 Date: Thu, 16 Dec 2010 16:41:11 -0600 From: Nicolas Williams To: Sam Hartman Message-ID: <20101216224110.GH1091@oracle.com> References: <4D0A8258.9080501@sunet.se> <7EE86E89365CA94F8E7B8251F92607100227A9@CIO-KRC-D1MBX01.osuad.osu.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2010-03-02) Cc: "abfab@ietf.org" Subject: Re: [abfab] SAML attribute queries: AAA or SOAP X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 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, 16 Dec 2010 22:39:36 -0000 On Thu, Dec 16, 2010 at 05:39:27PM -0500, Sam Hartman wrote: > One thing that running SAML over AAA does require is a real solution for > the AAA MTU problem. > We cannot both use attribute query as our response for RADIUS MTU issues > and also claim we run attribute queries over RADIUS. Right. I figured you were going there. Fragmentation is not pretty. From hartmans@painless-security.com Thu Dec 16 14:42:37 2010 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9C3073A69E3 for ; Thu, 16 Dec 2010 14:42:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.374 X-Spam-Level: X-Spam-Status: No, score=-2.374 tagged_above=-999 required=5 tests=[AWL=-0.109, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i3nW32GO6UUU for ; Thu, 16 Dec 2010 14:42:37 -0800 (PST) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by core3.amsl.com (Postfix) with ESMTP id EA20F3A6934 for ; Thu, 16 Dec 2010 14:42:36 -0800 (PST) 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 C9BC92016B; Thu, 16 Dec 2010 17:43:17 -0500 (EST) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 695814060; Thu, 16 Dec 2010 17:44:10 -0500 (EST) From: Sam Hartman To: Nicolas Williams References: <20101213204846.GD29086@oracle.com> <20101216205147.GA1091@oracle.com> <20101216214740.GE1091@oracle.com> Date: Thu, 16 Dec 2010 17:44:10 -0500 In-Reply-To: <20101216214740.GE1091@oracle.com> (Nicolas Williams's message of "Thu, 16 Dec 2010 15:47:40 -0600") 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, mrex@sap.com Subject: Re: [abfab] Should gss-eap support empty target_name X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 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, 16 Dec 2010 22:42:37 -0000 >>>>> "Nicolas" == Nicolas Williams writes: Nicolas> Given the above assumption, I'd say: make the initial Nicolas> context token consist of a 32 bit long bit string, each bit Nicolas> being a flag acting as an attribute name, and follow it Nicolas> with length-value pairs, one per-flag set and in the flags' Nicolas> numerical order. The reply token would be a naked EAP Nicolas> message only when the initiator set no flags, else it would Nicolas> be length-value pairs corresponding to those flags that Nicolas> were set, in the same order, followed by a naked EAP Nicolas> message. Nicolas> Seems simple to me... This does not seem very simple to me. If we do something in this space my preference is to use our existing extension token framing (see mail from Luke--roughly, attribute IP, length, value for everything) for all tokens. --Sam From Nicolas.Williams@oracle.com Thu Dec 16 14:54:11 2010 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DB9103A6979 for ; Thu, 16 Dec 2010 14:54:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.549 X-Spam-Level: X-Spam-Status: No, score=-6.549 tagged_above=-999 required=5 tests=[AWL=0.049, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HkDfE0a3RBNg for ; Thu, 16 Dec 2010 14:54:11 -0800 (PST) Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by core3.amsl.com (Postfix) with ESMTP id 2921C3A6919 for ; Thu, 16 Dec 2010 14:54:11 -0800 (PST) Received: from rcsinet13.oracle.com (rcsinet13.oracle.com [148.87.113.125]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id oBGMttKp027635 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 16 Dec 2010 22:55:56 GMT Received: from acsmt353.oracle.com (acsmt353.oracle.com [141.146.40.153]) by rcsinet13.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id oBGMpT2S010892; Thu, 16 Dec 2010 22:55:54 GMT Received: from abhmt013.oracle.com by acsmt355.oracle.com with ESMTP id 861188061292540050; Thu, 16 Dec 2010 14:54:10 -0800 Received: from oracle.com (/10.135.188.51) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 16 Dec 2010 14:54:09 -0800 Date: Thu, 16 Dec 2010 16:54:04 -0600 From: Nicolas Williams To: Sam Hartman Message-ID: <20101216225404.GI1091@oracle.com> References: <20101213204846.GD29086@oracle.com> <20101216205147.GA1091@oracle.com> <20101216214740.GE1091@oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2010-03-02) Cc: abfab@ietf.org, mrex@sap.com Subject: Re: [abfab] Should gss-eap support empty target_name X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 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, 16 Dec 2010 22:54:11 -0000 On Thu, Dec 16, 2010 at 05:44:10PM -0500, Sam Hartman wrote: > Nicolas> Seems simple to me... > > This does not seem very simple to me. If we do something in this space > my preference is to use our existing extension token framing (see mail > from Luke--roughly, attribute IP, length, value for everything) for all > tokens. It's all the same to me. From Nicolas.Williams@oracle.com Thu Dec 16 15:14:12 2010 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B00863A69F6 for ; Thu, 16 Dec 2010 15:14:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.55 X-Spam-Level: X-Spam-Status: No, score=-6.55 tagged_above=-999 required=5 tests=[AWL=0.048, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rfCLq6oCED84 for ; Thu, 16 Dec 2010 15:14:11 -0800 (PST) Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by core3.amsl.com (Postfix) with ESMTP id 387213A6979 for ; Thu, 16 Dec 2010 15:14:11 -0800 (PST) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id oBGNFt1X002999 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 16 Dec 2010 23:15:56 GMT Received: from acsmt354.oracle.com (acsmt354.oracle.com [141.146.40.154]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id oBGN7VJH024873; Thu, 16 Dec 2010 23:15:54 GMT Received: from abhmt021.oracle.com by acsmt355.oracle.com with ESMTP id 861235521292541323; Thu, 16 Dec 2010 15:15:23 -0800 Received: from oracle.com (/10.135.188.51) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 16 Dec 2010 15:15:23 -0800 Date: Thu, 16 Dec 2010 17:15:22 -0600 From: Nicolas Williams To: Martin Rex Message-ID: <20101216231521.GJ1091@oracle.com> References: <20101216214740.GE1091@oracle.com> <201012162309.oBGN9VlK025619@fs4113.wdf.sap.corp> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201012162309.oBGN9VlK025619@fs4113.wdf.sap.corp> User-Agent: Mutt/1.5.20 (2010-03-02) Cc: abfab@ietf.org Subject: Re: [abfab] Should gss-eap support empty target_name X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 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, 16 Dec 2010 23:14:12 -0000 On Fri, Dec 17, 2010 at 12:09:31AM +0100, Martin Rex wrote: > Nicolas Williams wrote: > > > > On Thu, Dec 16, 2010 at 04:26:45PM -0500, Sam Hartman wrote: > > > Any opinions on whether we always frame or never frame? > > > Or should we just use an AVP structure for all tokens with a special AVP > > > for EAP tokens? > > > What's the behavior on receiving something unexpected? > > > > Good questions. AVP/TLV works for me. It can be optimized for the case > > where the initiator sent an "empty" [*] initial context token, such that > > in the case the reply is a naked initial EAP message. > > > > The GSS-API does not allow empty tokens. I'm not sure that a token > > consisting only of the initial context token header is legal, so I > > assume that you'll need at least a one-byte initial context token. > > The initial context token, per GSS-API standard, is the only token > where the generic framing (including the mechanism OID) is _mandatory_. For standard mechanisms, yes, which this would be. But can there be no bytes following that header? I'm not sure. Since this mechanism is based on EAP, and EAP is initiated by the other party, in this case the initial context token need not bear any data at all other than that mechanism OID header. Nico -- From Josh.Howlett@ja.net Fri Dec 17 02:03:16 2010 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DC5053A6926 for ; Fri, 17 Dec 2010 02:03:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.348 X-Spam-Level: X-Spam-Status: No, score=-102.348 tagged_above=-999 required=5 tests=[AWL=0.251, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zGGSzvbWJr7P for ; Fri, 17 Dec 2010 02:03:16 -0800 (PST) Received: from har003676.ukerna.ac.uk (har003676.ukerna.ac.uk [194.82.140.75]) by core3.amsl.com (Postfix) with ESMTP id EEA893A67FC for ; Fri, 17 Dec 2010 02:03:15 -0800 (PST) Received: from har003676.ukerna.ac.uk (localhost.localdomain [127.0.0.1]) by localhost (Email Security Appliance) with SMTP id D3B4B4A6B66_D0B35CCB; Fri, 17 Dec 2010 10:05: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 B40D14A6B70_D0B35CAF; Fri, 17 Dec 2010 10:04:58 +0000 (GMT) Received: from EXC001.atlas.ukerna.ac.uk ([193.62.83.37]) by EXC001 ([193.62.83.37]) with mapi; Fri, 17 Dec 2010 10:05:16 +0000 From: Josh Howlett To: "Cantor, Scott E." , Leif Johansson Thread-Topic: [abfab] SAML attribute queries: AAA or SOAP Thread-Index: AQHLnVozOCF8kWHMY0a/0yJ15QM6Z5OjkxkAgAAB9ICAAALQgIAAAJIAgADCfPA= Date: Fri, 17 Dec 2010 10:04:57 +0000 Message-ID: <55DC663C2F4F9F439F23543E0078E8B3043FF5@EXC001> References: <4D0A8258.9080501@sunet.se> <7EE86E89365CA94F8E7B8251F92607100227A9@CIO-KRC-D1MBX01.osuad.osu.edu> <4D0A8657.8080305@sunet.se> <7EE86E89365CA94F8E7B8251F9260710022813@CIO-KRC-D1MBX01.osuad.osu.edu> In-Reply-To: <7EE86E89365CA94F8E7B8251F9260710022813@CIO-KRC-D1MBX01.osuad.osu.edu> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Josh Howlett , "abfab@ietf.org" Subject: Re: [abfab] SAML attribute queries: AAA or SOAP X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 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, 17 Dec 2010 10:03:17 -0000 > > I have a feeling som of the UI hints that people have been talking about > > will turn out to be important for rendering something sensible to the > > user in the login dialog. >=20 > Maybe, but I don't think there's the same discovery aspect here Right. I am sympathetic to Leif's proposition that a trusted container could poten= tially still be useful in a number of ways, even if we're not using it for = the normal reasons of publishing endpoint locations and keys, but I think t= hat Nico's argument is more compelling: metadata-less operation makes ABFAB= much simpler. I definitely don't think that ABFAB should prohibit the use of SOAP. I thin= k that ABFAB should have some opinions about how SOAP-based communications = can be used within the architecture, and perhaps even how the metadata that= supports those communications comes to be resolved and trusted. However, it's a really non-trivial exercise to analyse the various approach= es for doing this, and their respective trade-offs; and so I think at this = stage it would be helpful to get agreement on what should constitute the se= t of 'base' ABFAB technologies.=20 So, should SOAP be in this base set? As Sam suggests, I think that depends = on whether we find a compelling answer to the AAA MTU issue. One possible a= nswer is Diameter. Another possible answer is to seek to increase the RADIU= S MTU. Another possibility it to learn to live with it, which is grim but n= ot untenable: if we're not signing the SAML PDUs (relying on AAA integrity = protection), 4kb of compressed XML is a still a handy amount of data. Josh. JANET(UK) is a trading name of The JNT Association, a company limited by guarantee which is registered in England under No. 2881024=20 and whose Registered Office is at Lumen House, Library Avenue, Harwell Science and Innovation Campus, Didcot, Oxfordshire. OX11 0SG From lear@cisco.com Fri Dec 17 02:44:51 2010 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 931E83A69CA for ; Fri, 17 Dec 2010 02:44:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.132 X-Spam-Level: X-Spam-Status: No, score=-110.132 tagged_above=-999 required=5 tests=[AWL=0.467, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vLwlDaWDD4ex for ; Fri, 17 Dec 2010 02:44:50 -0800 (PST) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by core3.amsl.com (Postfix) with ESMTP id 7C07C3A694A for ; Fri, 17 Dec 2010 02:44:50 -0800 (PST) Authentication-Results: ams-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Am0EAL/NCk2Q/khMgWdsb2JhbACDZKBUFQEBFiIkqBWKS5BwgSGBbAGBSHQEiwCLKw X-IronPort-AV: E=Sophos;i="4.59,360,1288569600"; d="scan'208";a="15458676" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-2.cisco.com with ESMTP; 17 Dec 2010 10:46:36 +0000 Received: from dhcp-10-55-88-78.cisco.com (dhcp-10-55-88-78.cisco.com [10.55.88.78]) by ams-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id oBHAka6N019869; Fri, 17 Dec 2010 10:46:36 GMT Message-ID: <4D0B3F95.8090105@cisco.com> Date: Fri, 17 Dec 2010 11:46:45 +0100 From: Eliot Lear User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Lightning/1.0b2 Thunderbird/3.1.7 MIME-Version: 1.0 To: "Cantor, Scott E." References: <4D0A8258.9080501@sunet.se> <7EE86E89365CA94F8E7B8251F92607100227A9@CIO-KRC-D1MBX01.osuad.osu.edu> <4D0A8657.8080305@sunet.se> <7EE86E89365CA94F8E7B8251F9260710022813@CIO-KRC-D1MBX01.osuad.osu.edu> In-Reply-To: <7EE86E89365CA94F8E7B8251F9260710022813@CIO-KRC-D1MBX01.osuad.osu.edu> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "abfab@ietf.org" Subject: Re: [abfab] SAML attribute queries: AAA or SOAP X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 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, 17 Dec 2010 10:44:51 -0000 Hi, On 12/16/10 10:38 PM, Cantor, Scott E. wrote: >> I have a feeling som of the UI hints that people have been talking about >> will turn out to be important for rendering something sensible to the >> user in the login dialog. > Maybe, but I don't think there's the same discovery aspect here, and unless there's a way to handle user consent in the flow, I don't know what you'd be presenting or for what purpose yet. > Right. Metadata covers a whole raft of possibilities. Precisely what are we talking about? are we talking about specific end point information? Are we talking about branding images? Are we talking about transaction-related data? Thanks, Eliot From lear@cisco.com Fri Dec 17 02:46:07 2010 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 38D7F3A697D for ; Fri, 17 Dec 2010 02:46:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.145 X-Spam-Level: X-Spam-Status: No, score=-110.145 tagged_above=-999 required=5 tests=[AWL=0.454, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Or65u0qobi5t for ; Fri, 17 Dec 2010 02:46:06 -0800 (PST) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by core3.amsl.com (Postfix) with ESMTP id 9F8F73A694A for ; Fri, 17 Dec 2010 02:46:05 -0800 (PST) Authentication-Results: ams-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Am0EAOrOCk2Q/khMgWdsb2JhbACDZKBTFQEBFiIkqBaKS5BwgSGDNXQEiwA X-IronPort-AV: E=Sophos;i="4.59,360,1288569600"; d="scan'208";a="15458776" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-2.cisco.com with ESMTP; 17 Dec 2010 10:47:51 +0000 Received: from dhcp-10-55-88-78.cisco.com (dhcp-10-55-88-78.cisco.com [10.55.88.78]) by ams-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id oBHAlpuU020205; Fri, 17 Dec 2010 10:47:51 GMT Message-ID: <4D0B3FE0.50507@cisco.com> Date: Fri, 17 Dec 2010 11:48:00 +0100 From: Eliot Lear User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Lightning/1.0b2 Thunderbird/3.1.7 MIME-Version: 1.0 To: Sam Hartman References: <4D0A8258.9080501@sunet.se> <7EE86E89365CA94F8E7B8251F92607100227A9@CIO-KRC-D1MBX01.osuad.osu.edu> In-Reply-To: X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "abfab@ietf.org" Subject: Re: [abfab] SAML attribute queries: AAA or SOAP X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 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, 17 Dec 2010 10:46:07 -0000 On 12/16/10 11:39 PM, Sam Hartman wrote: > One thing that running SAML over AAA does require is a real solution for > the AAA MTU problem. > We cannot both use attribute query as our response for RADIUS MTU issues > and also claim we run attribute queries over RADIUS. Is this problem limited to Radius/UDP? Eliot From aland@deployingradius.com Fri Dec 17 02:51:00 2010 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1FEFF3A69FD for ; Fri, 17 Dec 2010 02:51:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.587 X-Spam-Level: X-Spam-Status: No, score=-102.587 tagged_above=-999 required=5 tests=[AWL=0.012, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 10R1qIUXLMKv for ; Fri, 17 Dec 2010 02:50:59 -0800 (PST) Received: from liberty.deployingradius.com (liberty.deployingradius.com [88.191.76.128]) by core3.amsl.com (Postfix) with ESMTP id 549833A69F1 for ; Fri, 17 Dec 2010 02:50:59 -0800 (PST) Message-ID: <4D0B40FC.3060805@deployingradius.com> Date: Fri, 17 Dec 2010 11:52:44 +0100 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Eliot Lear References: <4D0A8258.9080501@sunet.se> <7EE86E89365CA94F8E7B8251F92607100227A9@CIO-KRC-D1MBX01.osuad.osu.edu> <4D0B3FE0.50507@cisco.com> In-Reply-To: <4D0B3FE0.50507@cisco.com> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "abfab@ietf.org" Subject: Re: [abfab] SAML attribute queries: AAA or SOAP X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 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, 17 Dec 2010 10:51:00 -0000 Eliot Lear wrote: >> We cannot both use attribute query as our response for RADIUS MTU issues >> and also claim we run attribute queries over RADIUS. > > Is this problem limited to Radius/UDP? It's a general problem in RADIUS. No other transport has been defined, though others are being worked on (TCP, TLS, DTLS) There have been discussions about updating the MTU limits, but it will take time before it's standardized and deployed. Alan DeKok. From Josh.Howlett@ja.net Fri Dec 17 02:56:05 2010 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AB7E53A6ADF for ; Fri, 17 Dec 2010 02:56:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.371 X-Spam-Level: X-Spam-Status: No, score=-102.371 tagged_above=-999 required=5 tests=[AWL=0.228, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bCiI+Vw88PYS for ; Fri, 17 Dec 2010 02:56:05 -0800 (PST) Received: from har003676.ukerna.ac.uk (har003676.ukerna.ac.uk [194.82.140.75]) by core3.amsl.com (Postfix) with ESMTP id C6C8D3A6AE2 for ; Fri, 17 Dec 2010 02:56:04 -0800 (PST) Received: from har003676.ukerna.ac.uk (localhost.localdomain [127.0.0.1]) by localhost (Email Security Appliance) with SMTP id B7E374A6B66_D0B422EB; Fri, 17 Dec 2010 10:57:50 +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 A2ECD4A6B4E_D0B422CF; Fri, 17 Dec 2010 10:57:48 +0000 (GMT) Received: from EXC001.atlas.ukerna.ac.uk ([193.62.83.37]) by EXC001 ([193.62.83.37]) with mapi; Fri, 17 Dec 2010 10:58:05 +0000 From: Josh Howlett To: Alan DeKok , Eliot Lear Thread-Topic: [abfab] SAML attribute queries: AAA or SOAP Thread-Index: AQHLnVozOCF8kWHMY0a/0yJ15QM6Z5Ojqb6sgADLTACAAAFSAIAAADwg Date: Fri, 17 Dec 2010 10:57:46 +0000 Message-ID: <55DC663C2F4F9F439F23543E0078E8B304412F@EXC001> References: <4D0A8258.9080501@sunet.se> <7EE86E89365CA94F8E7B8251F92607100227A9@CIO-KRC-D1MBX01.osuad.osu.edu> <4D0B3FE0.50507@cisco.com> <4D0B40FC.3060805@deployingradius.com> In-Reply-To: <4D0B40FC.3060805@deployingradius.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Josh Howlett , "abfab@ietf.org" Subject: Re: [abfab] SAML attribute queries: AAA or SOAP X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 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, 17 Dec 2010 10:56:05 -0000 > There have been discussions about updating the MTU limits, but it > will take time before it's standardized and deployed. Perhaps this is a naive question, but why would it need to take much time t= o standardise? It's just a matter of picking a number 4=3D<64kb, right? Josh. JANET(UK) is a trading name of The JNT Association, a company limited by guarantee which is registered in England under No. 2881024=20 and whose Registered Office is at Lumen House, Library Avenue, Harwell Science and Innovation Campus, Didcot, Oxfordshire. OX11 0SG From aland@deployingradius.com Fri Dec 17 03:00:57 2010 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 877023A6AE1 for ; Fri, 17 Dec 2010 03:00:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.587 X-Spam-Level: X-Spam-Status: No, score=-102.587 tagged_above=-999 required=5 tests=[AWL=0.012, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ihpzNGroMzhd for ; Fri, 17 Dec 2010 03:00:56 -0800 (PST) Received: from liberty.deployingradius.com (liberty.deployingradius.com [88.191.76.128]) by core3.amsl.com (Postfix) with ESMTP id C07433A6AE3 for ; Fri, 17 Dec 2010 03:00:56 -0800 (PST) Message-ID: <4D0B4352.7090000@deployingradius.com> Date: Fri, 17 Dec 2010 12:02:42 +0100 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Josh Howlett References: <4D0A8258.9080501@sunet.se> <7EE86E89365CA94F8E7B8251F92607100227A9@CIO-KRC-D1MBX01.osuad.osu.edu> <4D0B3FE0.50507@cisco.com> <4D0B40FC.3060805@deployingradius.com> <55DC663C2F4F9F439F23543E0078E8B304412F@EXC001> In-Reply-To: <55DC663C2F4F9F439F23543E0078E8B304412F@EXC001> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "abfab@ietf.org" Subject: Re: [abfab] SAML attribute queries: AAA or SOAP X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 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, 17 Dec 2010 11:00:57 -0000 Josh Howlett wrote: >> There have been discussions about updating the MTU limits, but it >> will take time before it's standardized and deployed. > > Perhaps this is a naive question, but why would it need to take much time to standardise? It's just a matter of picking a number 4=<64kb, right? What is the impact of changing it? On the network, servers, clients, etc. Does anyone know? Who has the time to write the document, shepherd it, get reviewers, etc? Even high priority specifications can take months to years to get published. Alan DeKok. From lear@cisco.com Fri Dec 17 03:01:25 2010 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A404B3A6ADF for ; Fri, 17 Dec 2010 03:01:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.158 X-Spam-Level: X-Spam-Status: No, score=-110.158 tagged_above=-999 required=5 tests=[AWL=0.441, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m8yMIiMpQjNL for ; Fri, 17 Dec 2010 03:01:25 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id ABFB73A69EC for ; Fri, 17 Dec 2010 03:01:24 -0800 (PST) Authentication-Results: ams-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Am0EAG/SCk2Q/khNgWdsb2JhbACDZKBRFQEBFiIkqD+KS5BugSGDNXQEiwA X-IronPort-AV: E=Sophos;i="4.59,360,1288569600"; d="scan'208";a="71900383" Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-1.cisco.com with ESMTP; 17 Dec 2010 11:03:10 +0000 Received: from dhcp-10-55-88-78.cisco.com (dhcp-10-55-88-78.cisco.com [10.55.88.78]) by ams-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id oBHB3Avt029408; Fri, 17 Dec 2010 11:03:10 GMT Message-ID: <4D0B4377.5080001@cisco.com> Date: Fri, 17 Dec 2010 12:03:19 +0100 From: Eliot Lear User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Lightning/1.0b2 Thunderbird/3.1.7 MIME-Version: 1.0 To: Josh Howlett References: <4D0A8258.9080501@sunet.se> <7EE86E89365CA94F8E7B8251F92607100227A9@CIO-KRC-D1MBX01.osuad.osu.edu> <4D0B3FE0.50507@cisco.com> <4D0B40FC.3060805@deployingradius.com> <55DC663C2F4F9F439F23543E0078E8B304412F@EXC001> In-Reply-To: <55DC663C2F4F9F439F23543E0078E8B304412F@EXC001> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "abfab@ietf.org" Subject: Re: [abfab] SAML attribute queries: AAA or SOAP X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 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, 17 Dec 2010 11:01:25 -0000 I On 12/17/10 11:57 AM, Josh Howlett wrote: >> There have been discussions about updating the MTU limits, but it >> will take time before it's standardized and deployed. > Perhaps this is a naive question, but why would it need to take much time to standardise? It's just a matter of picking a number 4=<64kb, right? I probably wouldn't screw around with UDP, and if we're doing TCP, then we need to do it over TLS/SSL. I'm sure there's a draft out there somewhere... "Bueller? Bueller?" Eliot From aland@deployingradius.com Fri Dec 17 03:10:10 2010 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6186F3A6AE6 for ; Fri, 17 Dec 2010 03:10:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.587 X-Spam-Level: X-Spam-Status: No, score=-102.587 tagged_above=-999 required=5 tests=[AWL=0.012, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ier6b9PSAFpS for ; Fri, 17 Dec 2010 03:10:09 -0800 (PST) Received: from liberty.deployingradius.com (liberty.deployingradius.com [88.191.76.128]) by core3.amsl.com (Postfix) with ESMTP id 37B023A6AE2 for ; Fri, 17 Dec 2010 03:10:09 -0800 (PST) Message-ID: <4D0B457B.7020203@deployingradius.com> Date: Fri, 17 Dec 2010 12:11:55 +0100 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Eliot Lear References: <4D0A8258.9080501@sunet.se> <7EE86E89365CA94F8E7B8251F92607100227A9@CIO-KRC-D1MBX01.osuad.osu.edu> <4D0B3FE0.50507@cisco.com> <4D0B40FC.3060805@deployingradius.com> <55DC663C2F4F9F439F23543E0078E8B304412F@EXC001> <4D0B4377.5080001@cisco.com> In-Reply-To: <4D0B4377.5080001@cisco.com> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Josh Howlett , "abfab@ietf.org" Subject: Re: [abfab] SAML attribute queries: AAA or SOAP X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 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, 17 Dec 2010 11:10:10 -0000 Eliot Lear wrote: > I probably wouldn't screw around with UDP, and if we're doing TCP, then > we need to do it over TLS/SSL. I'm sure there's a draft out there > somewhere... http://tools.ietf.org/html/draft-ietf-radext-radsec-07 Multiple interoperable implementations, too. Alan DeKok. From gabilm@um.es Fri Dec 17 04:49:20 2010 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 025CD3A6B0E for ; Fri, 17 Dec 2010 04:49:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m3GleP8IuBfa for ; Fri, 17 Dec 2010 04:49:19 -0800 (PST) Received: from xenon11.um.es (xenon11.um.es [155.54.212.165]) by core3.amsl.com (Postfix) with ESMTP id B77283A6B11 for ; Fri, 17 Dec 2010 04:49:18 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by xenon11.um.es (Postfix) with ESMTP id 95A7F53DBC for ; Fri, 17 Dec 2010 13:51:03 +0100 (CET) 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 xf7qt1MrUj90 for ; Fri, 17 Dec 2010 13:51:03 +0100 (CET) Received: from MacBook-Pro-de-Gabriel-Lopez.local (unknown [84.236.164.151]) (Authenticated sender: gabilm) by xenon11.um.es (Postfix) with ESMTPA id DAC0C53613 for ; Fri, 17 Dec 2010 13:51:01 +0100 (CET) Message-ID: <4D0B5C82.3000201@um.es> Date: Fri, 17 Dec 2010 13:50:10 +0100 From: =?ISO-8859-1?Q?Gabriel_L=F3pez?= User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; es-ES; rv:1.9.2.13) Gecko/20101207 Lightning/1.0b2 Thunderbird/3.1.7 MIME-Version: 1.0 To: "abfab@ietf.org" References: <4D0A8258.9080501@sunet.se> <7EE86E89365CA94F8E7B8251F92607100227A9@CIO-KRC-D1MBX01.osuad.osu.edu> <4D0A8657.8080305@sunet.se> <7EE86E89365CA94F8E7B8251F9260710022813@CIO-KRC-D1MBX01.osuad.osu.edu> <55DC663C2F4F9F439F23543E0078E8B3043FF5@EXC001> In-Reply-To: <55DC663C2F4F9F439F23543E0078E8B3043FF5@EXC001> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [abfab] SAML attribute queries: AAA or SOAP X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 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, 17 Dec 2010 12:49:20 -0000 Hi, If you suppose AAA will provide the trust infrastructure (no PKI-like infrastructures) then you should make use of SAML/RADIUS. You should not sign or cypher SAML assertions, so you can encapsulate SAML over RADIUS (fragmentation/RadSec/Diameter). But if you suppose there also could be a underlaying PKI-like infrastructure to manage trust (what I think is the most realistic scenario) then you should provide both alternatives: to encapsulate SAML assertions over RADIUS and to allow service providers to request end user attributes latter by means of SOAP bindings. The question is why do not provide both alternatives? Best regards, Gabi. El 17/12/10 11:04, Josh Howlett escribió: >>> I have a feeling som of the UI hints that people have been talking about >>> will turn out to be important for rendering something sensible to the >>> user in the login dialog. >> Maybe, but I don't think there's the same discovery aspect here > Right. > > I am sympathetic to Leif's proposition that a trusted container could potentially still be useful in a number of ways, even if we're not using it for the normal reasons of publishing endpoint locations and keys, but I think that Nico's argument is more compelling: metadata-less operation makes ABFAB much simpler. > > I definitely don't think that ABFAB should prohibit the use of SOAP. I think that ABFAB should have some opinions about how SOAP-based communications can be used within the architecture, and perhaps even how the metadata that supports those communications comes to be resolved and trusted. > > However, it's a really non-trivial exercise to analyse the various approaches for doing this, and their respective trade-offs; and so I think at this stage it would be helpful to get agreement on what should constitute the set of 'base' ABFAB technologies. > > So, should SOAP be in this base set? As Sam suggests, I think that depends on whether we find a compelling answer to the AAA MTU issue. One possible answer is Diameter. Another possible answer is to seek to increase the RADIUS MTU. Another possibility it to learn to live with it, which is grim but not untenable: if we're not signing the SAML PDUs (relying on AAA integrity protection), 4kb of compressed XML is a still a handy amount of data. > > Josh. > > JANET(UK) is a trading name of The JNT Association, a company limited > by guarantee which is registered in England under No. 2881024 > and whose Registered Office is at Lumen House, Library Avenue, > Harwell Science and Innovation Campus, Didcot, Oxfordshire. OX11 0SG > > _______________________________________________ > abfab mailing list > abfab@ietf.org > https://www.ietf.org/mailman/listinfo/abfab -- ---------------------------------------------------------------- Gabriel López Millán Departamento de Ingeniería de la Información y las Comunicaciones University of Murcia Spain Tel: +34 868888504 Fax: +34 868884151 email: gabilm@um.es From mrex@sap.com Thu Dec 16 15:07:49 2010 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 323783A69F6 for ; Thu, 16 Dec 2010 15:07:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.139 X-Spam-Level: X-Spam-Status: No, score=-10.139 tagged_above=-999 required=5 tests=[AWL=0.110, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f3M4nAPBLEqS for ; Thu, 16 Dec 2010 15:07:48 -0800 (PST) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by core3.amsl.com (Postfix) with ESMTP id 27A983A6915 for ; Thu, 16 Dec 2010 15:07:47 -0800 (PST) Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id oBGN9WYO007562 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 17 Dec 2010 00:09:33 +0100 (MET) From: Martin Rex Message-Id: <201012162309.oBGN9VlK025619@fs4113.wdf.sap.corp> To: Nicolas.Williams@oracle.com (Nicolas Williams) Date: Fri, 17 Dec 2010 00:09:31 +0100 (MET) In-Reply-To: <20101216214740.GE1091@oracle.com> from "Nicolas Williams" at Dec 16, 10 03:47:40 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Scanner: Virus Scanner virwal04 X-SAP: out X-Mailman-Approved-At: Fri, 17 Dec 2010 05:44:08 -0800 Cc: abfab@ietf.org, mrex@sap.com Subject: Re: [abfab] Should gss-eap support empty target_name X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mrex@sap.com List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Dec 2010 23:07:49 -0000 Nicolas Williams wrote: > > On Thu, Dec 16, 2010 at 04:26:45PM -0500, Sam Hartman wrote: > > Any opinions on whether we always frame or never frame? > > Or should we just use an AVP structure for all tokens with a special AVP > > for EAP tokens? > > What's the behavior on receiving something unexpected? > > Good questions. AVP/TLV works for me. It can be optimized for the case > where the initiator sent an "empty" [*] initial context token, such that > in the case the reply is a naked initial EAP message. > > The GSS-API does not allow empty tokens. I'm not sure that a token > consisting only of the initial context token header is legal, so I > assume that you'll need at least a one-byte initial context token. The initial context token, per GSS-API standard, is the only token where the generic framing (including the mechanism OID) is _mandatory_. (so that the acceptor can figure out whether it is interoperable with the initiator and any intermediate glue mech layers can correctly dispatch the initial token to the correct mechanism implementation, creating a gsssapi security context handle for all further processing of tokens. -Martin From mrex@sap.com Thu Dec 16 15:43:09 2010 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 478443A6A34 for ; Thu, 16 Dec 2010 15:43:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.142 X-Spam-Level: X-Spam-Status: No, score=-10.142 tagged_above=-999 required=5 tests=[AWL=0.107, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eFIKXlAr1RRW for ; Thu, 16 Dec 2010 15:43:08 -0800 (PST) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by core3.amsl.com (Postfix) with ESMTP id D96B73A6A2C for ; Thu, 16 Dec 2010 15:43:07 -0800 (PST) Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id oBGNiqR7010317 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 17 Dec 2010 00:44:52 +0100 (MET) From: Martin Rex Message-Id: <201012162344.oBGNiorn027510@fs4113.wdf.sap.corp> To: Nicolas.Williams@oracle.com (Nicolas Williams) Date: Fri, 17 Dec 2010 00:44:50 +0100 (MET) In-Reply-To: <20101216231521.GJ1091@oracle.com> from "Nicolas Williams" at Dec 16, 10 05:15:22 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Scanner: Virus Scanner virwal08 X-SAP: out X-Mailman-Approved-At: Fri, 17 Dec 2010 05:44:08 -0800 Cc: abfab@ietf.org, mrex@sap.com Subject: Re: [abfab] Should gss-eap support empty target_name X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mrex@sap.com List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Dec 2010 23:43:09 -0000 Nicolas Williams wrote: > > On Fri, Dec 17, 2010 at 12:09:31AM +0100, Martin Rex wrote: > > Nicolas Williams wrote: > > > > > > On Thu, Dec 16, 2010 at 04:26:45PM -0500, Sam Hartman wrote: > > > > Any opinions on whether we always frame or never frame? > > > > Or should we just use an AVP structure for all tokens with a special AVP > > > > for EAP tokens? > > > > What's the behavior on receiving something unexpected? > > > > > > Good questions. AVP/TLV works for me. It can be optimized for the case > > > where the initiator sent an "empty" [*] initial context token, such that > > > in the case the reply is a naked initial EAP message. > > > > > > The GSS-API does not allow empty tokens. I'm not sure that a token > > > consisting only of the initial context token header is legal, so I > > > assume that you'll need at least a one-byte initial context token. > > > > The initial context token, per GSS-API standard, is the only token > > where the generic framing (including the mechanism OID) is _mandatory_. > > For standard mechanisms, yes, which this would be. But can there be no > bytes following that header? I'm not sure. Since this mechanism is > based on EAP, and EAP is initiated by the other party, in this case the > initial context token need not bear any data at all other than that > mechanism OID header. The contents of the token following the generic framing is defined by the mechanism identified by the mechanism OID in the generic framing. The currently existing prohibition of empty token exists only towards the gssapi-caller. The exact contents of the inner token is defined by the mechanism (specification) and could even be empty. (a zero-length inner token might incur additional code changes to some glue layers, but that area is not currently standardized. Using _very_few_ bytes for the initial inner token to avoid unexpected complexity for existing glue layers should be OK. -Martin From hartmans@painless-security.com Fri Dec 17 06:23:01 2010 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DF8E13A6B55 for ; Fri, 17 Dec 2010 06:23:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.367 X-Spam-Level: X-Spam-Status: No, score=-2.367 tagged_above=-999 required=5 tests=[AWL=-0.102, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BGnlM8NBT6aj for ; Fri, 17 Dec 2010 06:23:01 -0800 (PST) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by core3.amsl.com (Postfix) with ESMTP id 261C43A6B3D for ; Fri, 17 Dec 2010 06:23:00 -0800 (PST) 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 27BA82013D; Fri, 17 Dec 2010 09:23:38 -0500 (EST) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 73C3C4060; Fri, 17 Dec 2010 09:24:26 -0500 (EST) From: Sam Hartman To: Eliot Lear References: <4D0A8258.9080501@sunet.se> <7EE86E89365CA94F8E7B8251F92607100227A9@CIO-KRC-D1MBX01.osuad.osu.edu> <4D0B3FE0.50507@cisco.com> <4D0B40FC.3060805@deployingradius.com> <55DC663C2F4F9F439F23543E0078E8B304412F@EXC001> <4D0B4377.5080001@cisco.com> Date: Fri, 17 Dec 2010 09:24:26 -0500 In-Reply-To: <4D0B4377.5080001@cisco.com> (Eliot Lear's message of "Fri, 17 Dec 2010 12:03:19 +0100") 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: Josh Howlett , "abfab@ietf.org" Subject: Re: [abfab] SAML attribute queries: AAA or SOAP X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 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, 17 Dec 2010 14:23:02 -0000 >>>>> "Eliot" == Eliot Lear writes: Eliot> I Eliot> On 12/17/10 11:57 AM, Josh Howlett wrote: >>> There have been discussions about updating the MTU limits, but >>> it will take time before it's standardized and deployed. >> Perhaps this is a naive question, but why would it need to take >> much time to standardise? It's just a matter of picking a number >> 4=<64kb, right? Eliot> I probably wouldn't screw around with UDP, and if we're doing Eliot> TCP, then we need to do it over TLS/SSL. I'm sure there's a Eliot> draft out there somewhere... We have a preliminary radsec (RADIUS over TLS) implementation we're using for Moonshot. However even that implementation has the 4k limit as an implementation artifact. Presumably it would not be hugely difficult to change in that implementation. --Sam From hartmans@painless-security.com Fri Dec 17 07:17:36 2010 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7B1243A6B00 for ; Fri, 17 Dec 2010 07:17:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.21 X-Spam-Level: X-Spam-Status: No, score=-2.21 tagged_above=-999 required=5 tests=[AWL=-0.245, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id StflM9-YplKz for ; Fri, 17 Dec 2010 07:17:35 -0800 (PST) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by core3.amsl.com (Postfix) with ESMTP id AFADD3A6850 for ; Fri, 17 Dec 2010 07:17:35 -0800 (PST) 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 4252720298; Fri, 17 Dec 2010 10:18:17 -0500 (EST) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 143374060; Fri, 17 Dec 2010 10:19:09 -0500 (EST) From: Sam Hartman To: Gabriel =?iso-8859-1?Q?L=F3pez?= References: <4D0A8258.9080501@sunet.se> <7EE86E89365CA94F8E7B8251F92607100227A9@CIO-KRC-D1MBX01.osuad.osu.edu> <4D0A8657.8080305@sunet.se> <7EE86E89365CA94F8E7B8251F9260710022813@CIO-KRC-D1MBX01.osuad.osu.edu> <55DC663C2F4F9F439F23543E0078E8B3043FF5@EXC001> <4D0B5C82.3000201@um.es> Date: Fri, 17 Dec 2010 10:19:09 -0500 In-Reply-To: <4D0B5C82.3000201@um.es> ("Gabriel =?iso-8859-1?Q?L=F3pez=22'?= =?iso-8859-1?Q?s?= message of "Fri, 17 Dec 2010 13:50:10 +0100") 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] SAML attribute queries: AAA or SOAP X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 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, 17 Dec 2010 15:17:36 -0000 >>>>> "Gabriel" == Gabriel López writes: Gabriel> Hi, Gabriel> If you suppose AAA will provide the trust Gabriel> infrastructure (no PKI-like infrastructures) then you Gabriel> should make use of SAML/RADIUS. You should not sign or Gabriel> cypher SAML assertions, so you can encapsulate SAML over Gabriel> RADIUS (fragmentation/RadSec/Diameter). But if you suppose Gabriel> there also could be a underlaying PKI-like infrastructure Gabriel> to manage trust (what I think is the most realistic Gabriel> scenario) then you should provide both alternatives: to Gabriel> encapsulate SAML assertions over RADIUS and to allow Gabriel> service providers to request end user attributes latter by Gabriel> means of SOAP bindings. Gabriel> The question is why do not provide both alternatives? At one level, it would be difficult for us to take away the option of using SOAP. We'd have to go out of our way to tell people not to do it, everyone would disagree with the proposal because there's no point in prohibiting SOAP, etc. However, at another level, there is a serious question of whether it makes sense to spend effort on both alternatives. For example, if you are going to transition from AAA to SOAP, you want to have a mechanism where the AAA server can issue an initial assertion with a subject that the IDP can consume. For pseudunomymous operation, that requires standardization. Also, if SOAP is going to be in the mix, then focusing on making SAML metadata scale is important. --Sam From Josh.Howlett@ja.net Fri Dec 17 08:05:15 2010 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BDCB43A6B7C for ; Fri, 17 Dec 2010 08:05:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.24 X-Spam-Level: X-Spam-Status: No, score=-102.24 tagged_above=-999 required=5 tests=[AWL=0.059, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Iez7CRlyfcce for ; Fri, 17 Dec 2010 08:05:15 -0800 (PST) Received: from har003676.ukerna.ac.uk (har003676.ukerna.ac.uk [194.82.140.75]) by core3.amsl.com (Postfix) with ESMTP id BB9653A6B4D for ; Fri, 17 Dec 2010 08:05:14 -0800 (PST) Received: from har003676.ukerna.ac.uk (localhost.localdomain [127.0.0.1]) by localhost (Email Security Appliance) with SMTP id 3E63E4A6BA9_D0B8AA3B; Fri, 17 Dec 2010 16:06: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 3169F4A6B9E_D0B8AA2F; Fri, 17 Dec 2010 16:06:58 +0000 (GMT) Received: from EXC001.atlas.ukerna.ac.uk ([193.62.83.37]) by EXC001 ([193.62.83.37]) with mapi; Fri, 17 Dec 2010 16:07:15 +0000 From: Josh Howlett To: =?iso-8859-1?Q?Gabriel_L=F3pez?= , "abfab@ietf.org" Thread-Topic: [abfab] SAML attribute queries: AAA or SOAP Thread-Index: AQHLnVozOCF8kWHMY0a/0yJ15QM6Z5OjkxkAgAAB9ICAAALQgIAAAJIAgADCfPCAADxBAIAAMs9A Date: Fri, 17 Dec 2010 16:06:56 +0000 Message-ID: <55DC663C2F4F9F439F23543E0078E8B304593C@EXC001> References: <4D0A8258.9080501@sunet.se> <7EE86E89365CA94F8E7B8251F92607100227A9@CIO-KRC-D1MBX01.osuad.osu.edu> <4D0A8657.8080305@sunet.se> <7EE86E89365CA94F8E7B8251F9260710022813@CIO-KRC-D1MBX01.osuad.osu.edu> <55DC663C2F4F9F439F23543E0078E8B3043FF5@EXC001> <4D0B5C82.3000201@um.es> In-Reply-To: <4D0B5C82.3000201@um.es> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Josh Howlett Subject: Re: [abfab] SAML attribute queries: AAA or SOAP X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 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, 17 Dec 2010 16:05:16 -0000 Hi Gabi, > But if you suppose there also could be a underlaying PKI-like > infrastructure to manage trust (what I think is the most realistic > scenario) then you should provide both alternatives: to encapsulate > SAML > assertions over RADIUS and to allow service providers to request end > user attributes latter by means of SOAP bindings. >=20 > The question is why do not provide both alternatives? "PKI-like" is a complex set of possibilities. I'd rather not deal with that= , if we don't have to. (Although, as Sam says, this doesn't preclude Abfab entities from also usin= g SOAP if they also want to do that). Josh. JANET(UK) is a trading name of The JNT Association, a company limited by guarantee which is registered in England under No. 2881024=20 and whose Registered Office is at Lumen House, Library Avenue, Harwell Science and Innovation Campus, Didcot, Oxfordshire. OX11 0SG From diego.lopez@rediris.es Sun Dec 19 14:36:09 2010 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9FDF03A6936 for ; Sun, 19 Dec 2010 14:36:09 -0800 (PST) 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=[BAYES_50=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I2HgIqXXYZN4 for ; Sun, 19 Dec 2010 14:36:08 -0800 (PST) Received: from irisout1.rediris.es (irisout1.rediris.es [130.206.24.3]) by core3.amsl.com (Postfix) with ESMTP id 898933A692E for ; Sun, 19 Dec 2010 14:36:07 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.60,198,1291590000"; d="scan'208";a="36476219" Received: from 85.136.72.82.dyn.user.ono.com (HELO incal.lan) ([85.136.72.82]) by abel.rediris.es with ESMTP/TLS/AES128-SHA; 19 Dec 2010 23:37:57 +0100 Message-Id: <0EBEE073-8887-4B71-AD8C-1A9B7929A55A@rediris.es> From: "Diego R. Lopez" To: Josh Howlett In-Reply-To: <55DC663C2F4F9F439F23543E0078E8B3043FF5@EXC001> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Sun, 19 Dec 2010 23:37:57 +0100 References: <4D0A8258.9080501@sunet.se> <7EE86E89365CA94F8E7B8251F92607100227A9@CIO-KRC-D1MBX01.osuad.osu.edu> <4D0A8657.8080305@sunet.se> <7EE86E89365CA94F8E7B8251F9260710022813@CIO-KRC-D1MBX01.osuad.osu.edu> <55DC663C2F4F9F439F23543E0078E8B3043FF5@EXC001> X-Mailer: Apple Mail (2.936) Cc: "abfab@ietf.org" Subject: Re: [abfab] SAML attribute queries: AAA or SOAP X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 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, 19 Dec 2010 22:36:09 -0000 On 17 Dec 2010, at 11:04, Josh Howlett wrote: > So, should SOAP be in this base set? As Sam suggests, I think that > depends on whether we find a compelling answer to the AAA MTU issue. > One possible answer is Diameter. Another possible answer is to seek > to increase the RADIUS MTU. Another possibility it to learn to live > with it, which is grim but not untenable: if we're not signing the > SAML PDUs (relying on AAA integrity protection), 4kb of compressed > XML is a still a handy amount of data. > Has anyone thought on the possibility of a different, more compact, coding for security assertions, much in the same spirit of the different RDF coding schemas? Not sure if such a coding could be called SAML anyway... Be goode, -- "Esta vez no fallaremos, Doctor Infierno" Dr Diego R. Lopez Red.es - RedIRIS The Spanish NREN e-mail: diego.lopez@rediris.es jid: diego.lopez@rediris.es Tel: +34 955 056 621 Mobile: +34 669 898 094 ----------------------------------------- From lear@cisco.com Tue Dec 21 10:29:16 2010 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 493A83A6AA3 for ; Tue, 21 Dec 2010 10:29:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.169 X-Spam-Level: X-Spam-Status: No, score=-110.169 tagged_above=-999 required=5 tests=[AWL=0.429, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZuRNTCVcQDWK for ; Tue, 21 Dec 2010 10:29:15 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id BF3023A6A84 for ; Tue, 21 Dec 2010 10:29:14 -0800 (PST) Authentication-Results: ams-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-Files: None : None X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Aq0EALuAEE2Q/khNgWdsb2JhbACDY5tEhGIWARYiJKVbik2RMIRVdASLAg X-IronPort-AV: E=Sophos;i="4.60,208,1291593600"; d="scan'208,217";a="72175702" Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-1.cisco.com with ESMTP; 21 Dec 2010 18:31:10 +0000 Received: from dhcp-10-61-107-168.cisco.com (dhcp-10-61-107-168.cisco.com [10.61.107.168]) by ams-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id oBLIVAZJ002897; Tue, 21 Dec 2010 18:31:10 GMT Message-ID: <4D10F279.3030601@cisco.com> Date: Tue, 21 Dec 2010 19:31:21 +0100 From: Eliot Lear User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Lightning/1.0b2 Thunderbird/3.1.7 MIME-Version: 1.0 To: "abfab@ietf.org" X-Enigmail-Version: 1.1.1 Content-Type: multipart/mixed; boundary="------------070700020707060602060109" Cc: abfab-chairs@tools.ietf.org Subject: [abfab] draft-lear-abfab-arch-01 posted X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 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, 21 Dec 2010 18:29:16 -0000 This is a multi-part message in MIME format. --------------070700020707060602060109 Content-Type: multipart/alternative; boundary="------------030607040507060301010806" --------------030607040507060301010806 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Hi everyone, We give to you the holiday present of reading ;-) The authors have updated The ABFAB Architecture Draft. It contains a number of changes since -00: * A high level step by step description of the process. * A "swimming lane" diagram visually demonstrating that process. * A discussion about channel binding and appropriate EAP methods. * A discussion about discovery. This document is not complete, and will need to be a "living document" as decisions are made in this working group. There are still a number of XXXs in it, that indicate where at least some work is needed. It would not be fair to say that the authors agree on everything that the document contains, but rather we agree that it's important to show at least one view and receive comment on direction at this point. As to this author, please do not be alarmed if I don't respond quickly. I will be off from tomorrow until the 4th, and I wish you happy holidays if you also are taking time off (and even if you are not). Eliot --------------030607040507060301010806 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit Hi everyone,

We give to you the holiday present of reading ;-)  The authors have updated The ABFAB Architecture Draft.  It contains a number of changes since -00:
  • A high level step by step description of the process.
  • A "swimming lane" diagram visually demonstrating that process.
  • A discussion about channel binding and appropriate EAP methods.
  • A discussion about discovery.
This document is not complete, and will need to be a "living document" as decisions are made in this working group.  There are still a number of XXXs in it, that indicate where at least some work is needed.  It would not be fair to say that the authors agree on everything that the document contains, but rather we agree that it's important to show at least one view and receive comment on direction at this point.

As to this author, please do not be alarmed if I don't respond quickly.  I will be off from tomorrow until the 4th, and I wish you happy holidays if you also are taking time off (and even if you are not).

Eliot
--------------030607040507060301010806-- --------------070700020707060602060109 Content-Type: message/rfc822; name="Attached Message" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="Attached Message" Received: from xbh-ams-101.cisco.com ([144.254.74.71]) by xmb-ams-105.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 21 Dec 2010 19:24:37 +0100 Received: from xbh-rcd-202.cisco.com ([72.163.62.201]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 21 Dec 2010 19:24:37 +0100 Received: from sj-iport-1.cisco.com ([171.71.176.70]) by xbh-rcd-202.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 21 Dec 2010 12:24:31 -0600 Authentication-Results: sj-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-1.cisco.com with ESMTP; 21 Dec 2010 18:24:30 +0000 Received: from sj-inbound-f.cisco.com (sj-inbound-f.cisco.com [128.107.234.207]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id oBLIOTCf010195 for ; Tue, 21 Dec 2010 18:24:30 GMT X-from-outside-Cisco: 64.170.98.32 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvUAAEOAEE1AqmIgimdsb2JhbACDY5ILAQGOGRYBAQoJDAcPBx+lWopNkTCBIIM1dASEZYYd X-IronPort-AV: E=Sophos;i="4.60,208,1291593600"; d="scan'208";a="247563764" Received: from mail.ietf.org ([64.170.98.32]) by sj-inbound-f.cisco.com with ESMTP; 21 Dec 2010 18:24:16 +0000 Received: by core3.amsl.com (Postfix, from userid 30) id E76F73A6A77; Tue, 21 Dec 2010 10:22:19 -0800 (PST) From: IETF I-D Submission Tool To: lear@cisco.com Cc: Josh.Howlett@ja.net, hartmans-ietf@mit.edu, Hannes.Tschofenig@gmx.net Subject: New Version Notification for draft-lear-abfab-arch-01 Content-Type: text/plain; charset="utf-8" Mime-Version: 1.0 Message-Id: <20101221182219.E76F73A6A77@core3.amsl.com> Date: Tue, 21 Dec 2010 10:22:19 -0800 (PST) Return-Path: wwwrun@core3.amsl.com X-OriginalArrivalTime: 21 Dec 2010 18:24:31.0851 (UTC) FILETIME=[4FC373B0:01CBA13C] A new version of I-D, draft-lear-abfab-arch-01.txt has been successfully submitted by Eliot Lear and posted to the IETF repository. Filename: draft-lear-abfab-arch Revision: 01 Title: Application Bridging for Federated Access Beyond Web (ABFAB) Architecture Creation_date: 2010-12-21 WG ID: Independent Submission Number_of_pages: 29 Abstract: Over the last decade a substantial amount of work has occurred in the space of federated authentication and authorization. Most of this effort has focused on two common use cases: network and web-based access, with few common building blocks within the architecture. This memo describes an architecture that makes use of extensions to the commonly used mechanisms for both federated and non-federated authentication and authorization, including Radius/Diameter, GSS/GS2, and SAML, to primarily address non-web based authentication, in a that will scale to large numbers of federations. The IETF Secretariat. --------------070700020707060602060109--