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, 11 Feb 2010 21:39:55 -0000 MIME-Version: 1.0 Message-Id: <200305122255.h4CMt1U02501@example.com> To: abfab@ietf.org Content-Type: text/plain; charset="us-ascii" > Josh> I'm not concerned about the authenticity of the=20 > artifact; let > Josh> us assume that we have satisfied that. I'm=20 > concerned about the > Josh> authenticity of the SAML message that we obtain when we > Josh> resolve the artifact. If the acceptor does not authenticate > Josh> the IdP, it could be obtaining an assertion from an=20 > issuer who > Josh> is not who they claim to be. >=20 > Ah! My terminology failure. Can we include a hash of the=20 > SAML message in the artifact or along side the artifact to=20 > get authenticity of the SAML message? Probably. I've discovered an issue in the specification which might prevent this (there is a requirement to "authenticate" the issuer, which to me implies a demonstration of authority to wield a name; whereas in this instance we only need to demonstrate authority to wield a SAML message). I've emailed the SSTC list for clarification. 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 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, 11 Feb 2010 21:01:53 -0000 MIME-Version: 1.0 Message-Id: <200305122255.h4CMt1U02501@example.com> To: abfab@ietf.org Content-Type: text/plain; charset="us-ascii" > I think we should reject a moonshot architecture that=20 > requires routing logic in servers for the same reason. Agreed (as discussed on the phone earlier today). > As an aside, I remain unconvinced that treating TAS and TAC=20 > as special architectural entities doesn't simplify the model=20 > in important ways. I definitely agree that we should support=20 > a case where TAS gets close to S--definitely on the same=20 > machine, possibly in the same process. I'm not sure though=20 > that we want to lose the model distinction. Right. While we're on the subject, it's probably worth making sure our conceptions about these actors' roles are still in sync. Towards the end it turns into a brain dump, and some of those ideas we have not properly discussed yet. There is one class of actor that is the subject, and a second class of actor that is the consumer of that subject's claimed identity (C and S respectively). At a protocol level these are the EAP peer and authenticator and GSS initiator and acceptor. Let's keep calling these Client and Server because it is generally intuitive to think about them in that way. These actors are almost always AAA stubs, having a single AAA trust relationship with a third class of actor that is trusted by other actors in the system to make claims about the identities of the first two types of actor. This is what we've been refering to as a trust authority (TA). Trust authorities themselves may be trusted by other trust authorities to make claims about clients and servers using a long-lived AAA trust relationship. If two trust authorities share such a relationship with a common trust authority, they can bootstrap a short-lived trust relationship between themselves using what we've been calling the "key negotiation protocol". I think name is a bit misleading, and so I propose renaming this to the "Trust Negotiation Protocol". The Trust Negotiation Protocol is invoked when a Trust Authority wants to send a message that it has received from a trusted Client, Service or Trust Authority towards a destination that it does not share a direct AAA trust relationship with. Once a short-lived trust AAA relationship has been established, AAA messages can be routed directly via this relationship towards their destination. These short-lived trust relationships are short-lived because neither actor wants to be caught short for long if the common trust authority decides that one is no longer trustworthy. A short-lived trust relationship therefore expires after a period of time that was negotiated using the Trust Negotiation Protocol. If another AAA message appears that needs similar routing, the Trust Negotiation Protocol is invoked again. This pattern can be recursed any number of times, in principal, by leveraging a short-term trust AAA relationship to establish another short-term trust AAA relationship with any of the Trust Authorities with which it shares a AAA trust relationships (long-lived or short-lived). This allows a TA to discover, by recursing through the graph described by these AAA trust relationships, other TAs which it does not share a long-lived AAA trust relationship with. Each TA advertises its short and long-lived AAA trust relationships using the Trust Mark-up Language. The Trust Markup Languages enumerates each short and long-lived AAA trust relationship held by the Trust Authority, and their properties. Pertinent properties include: - a AAA URI identifying the network location of the trust authority - a tag identifying whether this is long-lived or short-lived (and time to expiry) - URIs naming the NAI realms and trust communities that this TA knows about directly - URIs naming the policies associated with this trust relationship - the peer trust authority's own AAA trust relationships, and its AAA trust relationships and properties, etc. A trust community is conceptually similar to a BGP community. It's a way of aggregating TAs (for example, all European research and education TAs), rather than advertising each individually. This information allows TAs to optimise their path through the trust graph when searching for another TA. The trust graph will consist of two layers: the first being composed of the long-lived AAA trust relationships; the second being composed of a much larger number of short-lived AAA trust relationships. The former is relatively static, evolving slowly, reflecting the pace of real-life business trust relationships. The latter is highly dynamic, a means of (1) optimising the transit of AAA messages between TAs in the graph and (2) allowing TAs that are widely separated on the former layer to find each other. 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 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, 11 Feb 2010 09:55:46 -0000 MIME-Version: 1.0 Message-Id: <200305122255.h4CMt1U02501@example.com> To: abfab@ietf.org Content-Type: text/plain; charset="us-ascii" Sam wrote: > Josh> That's where I started from. But I think that it is cleanest > Josh> to fold TAS into S, and then use recursive discovery to walk > Josh> the trust graph from the start. For example, if necessary S > Josh> can walk to a local TA (for name authorisation) before > Josh> exploring the trust graph outside of the local=20 > trust domain to > Josh> find TAC. >=20 > Ah, looks like we'll both be sleeping on something. Making S=20 > be something more than a stub RADIUS client--actually having=20 > it interact with RADIUS entities other than TAC seems=20 > esthetically bad to me. > I'll think on this. I think we need to move away from the idea of TAS or TAC as having a special role to play, and just consider them as a potential first discovery hop from the S and C respectively. To use a routing analogy, we would consider an IP architecture that required the use of a particular first hop router to be broken. A host might have a default router for unknown prefixes, but it should also be able to pick between alternative routers for prefixes it does know about. Consequently, I think it is reasonabe to think about TAS and TAC as being the default trust path for S and C respectively, but that if S or C know a better path they should use that instead. > Certainly if S talks to more than TAS, things get=20 > complicated. For example the club really isn't in a position=20 > to kno whether S is allowed to speak for a particular name. Not quite. S is allowed to talk to things other than TAS by virtue of C's trust discovery path, which must involve some TA (perhaps TAS) that is authoritative to assert S's right to claim a particular name. Therefore, it is entirely possible for the club to exert this type of policy. The short-lived credentials that the trust authorities obtain as a result of path path discovery do mean that there is a window in which these entities might communicate, while one has been expelled from the club, but this can be managed by each actor deciding how long it is willing to cache the short-lived credential, before invoking trust path discovery again (and discovering if that actor is still in the club, or not). In summary I would like to move away from the proxy model of the club enforcing policy by applying policy on AAA packets in-flight, to a model where the club enforces policy by applying policy on the key negotiation that is used to obtain the AAA credentials for the end-to-end transport of AAA packets. best regards, 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 leifj@sunet.se Tue Jan 4 12:15:57 2011 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 DC1663A6C1A for ; Tue, 4 Jan 2011 12:15:57 -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 yo7uk4cFHgef for ; Tue, 4 Jan 2011 12:15:57 -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 2F1493A6BA7 for ; Tue, 4 Jan 2011 12:15:55 -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 p04KHuAH003503 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 4 Jan 2011 21:17:59 +0100 (CET) Message-ID: <4D238074.9040109@sunet.se> Date: Tue, 04 Jan 2011 21:17:56 +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" X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Andy Adamson Subject: [abfab] session in Prague 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, 04 Jan 2011 20:15:57 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Lacking sufficient data to say otherwize, I'm leaning towards requesting a 2.5h session for Prague with the same conflict- avoidance as for Beijing. I know we ended early in Beijing but we hope to have Andy from netapp come and talk about the federated-NFSv4 usecase. Does anyone have another opinion? Cheers Leif -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk0jgHAACgkQ8Jx8FtbMZndwbgCfUSJes9jLyuG+pe4/XmDlgIFk yGAAn1Uee5reOjfaO6OeIy2hclGZuRyl =xhbm -----END PGP SIGNATURE----- From Josh.Howlett@ja.net Tue Jan 4 12:42:33 2011 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 198663A6AC4 for ; Tue, 4 Jan 2011 12:42:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.409 X-Spam-Level: X-Spam-Status: No, score=-102.409 tagged_above=-999 required=5 tests=[AWL=0.190, 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 eBoJ+xY+Odec for ; Tue, 4 Jan 2011 12:42:32 -0800 (PST) Received: from har003676.ukerna.ac.uk (har003676.ukerna.ac.uk [194.82.140.75]) by core3.amsl.com (Postfix) with ESMTP id 4892B3A6A17 for ; Tue, 4 Jan 2011 12:42:32 -0800 (PST) Received: from har003676.ukerna.ac.uk (localhost.localdomain [127.0.0.1]) by localhost (Email Security Appliance) with SMTP id 311764A6B4E_D2386B6B; Tue, 4 Jan 2011 20:44:38 +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 16AE44A6B3C_D2386B4F; Tue, 4 Jan 2011 20:44:36 +0000 (GMT) Received: from EXC001.atlas.ukerna.ac.uk ([193.62.83.37]) by EXC001 ([193.62.83.37]) with mapi; Tue, 4 Jan 2011 20:44:54 +0000 From: Josh Howlett To: Leif Johansson , "abfab@ietf.org" Thread-Topic: [abfab] session in Prague Thread-Index: AQHLrEyUZSvmhmoBZEem1Ttx3NX2cpPBQeoA Date: Tue, 4 Jan 2011 20:44:32 +0000 Message-ID: <55DC663C2F4F9F439F23543E0078E8B304C5D9@EXC001> References: <4D238074.9040109@sunet.se> In-Reply-To: <4D238074.9040109@sunet.se> 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 , Andy Adamson Subject: Re: [abfab] session in Prague 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, 04 Jan 2011 20:42:33 -0000 > I know we ended early in Beijing=20 I thought we finished precisely on time thanks to some expert chairing :-) > Does anyone have another opinion? I think the Architecture draft could /potentially/ eat a lot of time. Not b= ecause it says anything contentious, but because it necessarily covers a lo= t of ground at speed; it might take time to fine-tune the content, technica= l depth and dovetailing of concepts. I think 2.5 hours sounds about right, = but it would be interesting to hear opinions from folks who have read the e= xisting Architecture draft (draft-lear-abfab-arch-01), and how confused or = educated that experience has left them. Josh. JANET(UK) is a trading name of The JNT Association, a company limited by guarantee which is registered in England under No. 2881024=20 and whose Registered Office is at Lumen House, Library Avenue, Harwell Oxford, Didcot, Oxfordshire. OX11 0SG From hartmans@painless-security.com Tue Jan 4 12:54:06 2011 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 961613A6B6A for ; Tue, 4 Jan 2011 12:54:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.332 X-Spam-Level: X-Spam-Status: No, score=-2.332 tagged_above=-999 required=5 tests=[AWL=-0.067, 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 SgU+FGhQB1o2 for ; Tue, 4 Jan 2011 12:54:06 -0800 (PST) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by core3.amsl.com (Postfix) with ESMTP id E579F3A69A9 for ; Tue, 4 Jan 2011 12:54:05 -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 7D770203A2; Tue, 4 Jan 2011 15:54:45 -0500 (EST) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 74C2F426B; Tue, 4 Jan 2011 15:55:21 -0500 (EST) From: Sam Hartman To: Josh Howlett References: <4D238074.9040109@sunet.se> <55DC663C2F4F9F439F23543E0078E8B304C5D9@EXC001> Date: Tue, 04 Jan 2011 15:55:21 -0500 In-Reply-To: <55DC663C2F4F9F439F23543E0078E8B304C5D9@EXC001> (Josh Howlett's message of "Tue, 4 Jan 2011 20:44:32 +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: Andy Adamson , "abfab@ietf.org" Subject: Re: [abfab] session in Prague 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, 04 Jan 2011 20:54:06 -0000 Yeah, I'm sort of wondering whether we want two sessions, not whether we want a shorter session. I don't think I have a sufficient case to argue for two sessions though, so going with the chairs' 2.5 hour request seems good. I suspect there will be a number of technical details that will eat up time and I suspect we could definitely have a long discussion of the architecture draft. Speaking of which, please read and comment on the new architecture draft! From leifj@sunet.se Tue Jan 4 13:04:38 2011 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 7C28C3A6B6A for ; Tue, 4 Jan 2011 13:04:38 -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 h+aHWK7q2u4f for ; Tue, 4 Jan 2011 13:04:37 -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 EF74E3A6AFE for ; Tue, 4 Jan 2011 13:04:36 -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 p04L6doH007237 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 4 Jan 2011 22:06:42 +0100 (CET) Message-ID: <4D238BDF.9090503@sunet.se> Date: Tue, 04 Jan 2011 22:06:39 +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: Sam Hartman References: <4D238074.9040109@sunet.se> <55DC663C2F4F9F439F23543E0078E8B304C5D9@EXC001> In-Reply-To: X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Josh Howlett , Andy Adamson , "abfab@ietf.org" Subject: Re: [abfab] session in Prague 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, 04 Jan 2011 21:04:38 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 01/04/2011 09:55 PM, Sam Hartman wrote: > Yeah, I'm sort of wondering whether we want two sessions, not whether we > want a shorter session. > I don't think I have a sufficient case to argue for two sessions though, > so going with the chairs' 2.5 hour request seems good. It is so requested. I'm not sure if the scheduling has an early bird special but at least we won't be last :) > > I suspect there will be a number of technical details that will eat up > time and I suspect we could definitely have a long discussion of the > architecture draft. > Speaking of which, please read and comment on the new architecture > draft! Indeed. We the chairs want those reviews and document updates to start coming in now! Cheers Leif -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk0ji98ACgkQ8Jx8FtbMZnf99ACfTK0Un7SiFl5xcXtw9z7YM8Bm dqsAoKPWMDPQZR2hCoy2uzzzsJuQsDca =G2ju -----END PGP SIGNATURE----- From leifj@sunet.se Thu Jan 6 15:22:08 2011 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 A4E963A6E2D for ; Thu, 6 Jan 2011 15:22:08 -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 4DBjoCHuQ6UB for ; Thu, 6 Jan 2011 15:22:07 -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 1C0DF3A6D23 for ; Thu, 6 Jan 2011 15:22:06 -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 p06NO98A028776 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 7 Jan 2011 00:24:12 +0100 (CET) Message-ID: <4D264F19.9010502@sunet.se> Date: Fri, 07 Jan 2011 00:24:09 +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" X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [abfab] tracker? 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, 06 Jan 2011 23:22:08 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 We have a tracker (http://trac.tools.ietf.org/wg/abfab/trac/report). Is it worth the effort to create issues for some of the stuff that we've been discussing on the list? Cheers Leif -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk0mTxkACgkQ8Jx8FtbMZncjyQCfbJy5DkVsGzf9HWh8TK933I+z iCMAnRRUS2ur9tm4bJYJZFiulpvUf6co =SD+H -----END PGP SIGNATURE----- From klaas@cisco.com Mon Jan 10 03:29:43 2011 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 75CC828C157 for ; Mon, 10 Jan 2011 03:29:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 VoJfUDGTmLNP for ; Mon, 10 Jan 2011 03:29:42 -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 9731828C134 for ; Mon, 10 Jan 2011 03:29:41 -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: ArMEAHZ9Kk2Q/khMgWdsb2JhbACEB6A3FQEBFiIkpAqKU40JgSGBVIFjdASLCg Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-2.cisco.com with ESMTP; 10 Jan 2011 11:31:54 +0000 Received: from macmini.wierenga.net (ams-kwiereng-8712.cisco.com [10.55.220.243]) by ams-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p0ABVsUj007329 for ; Mon, 10 Jan 2011 11:31:54 GMT Message-ID: <4D2AEE2A.1080808@cisco.com> Date: Mon, 10 Jan 2011 12:31:54 +0100 From: Klaas Wierenga User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-GB; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: abfab@ietf.org References: <4D10F279.3030601@cisco.com> In-Reply-To: <4D10F279.3030601@cisco.com> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [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: Mon, 10 Jan 2011 11:29:43 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 12/21/10 7:31 PM, Eliot Lear wrote: Hi Eliot, all, Thanks for this great stab at an architecture document! I have read the document and have a bunch of remarks, questions etc. Some of those are a matter of taste I guess, so feel free to ignore (with arguments ;-) I looked at the document from different angles: overall organization, addressing of the key issues and specific content. In general I have assumed that readers of this document are probably intimately familiar with only part of the used components, so it is better to err at the more explanation rather than less side. Overall organization - -------------------- I see roughly an organization along the lines of: - - introduction - - problem description - - design goals - - component choices - - architecture description - - deployment considerations However, in the text the various parts are not always well separated. As an example, in the introduction (p6) the steps in the AuthN/AuthZ exchange are very much focused on the particular component choices that have been made, whereas those have not been introduced yet. And also, 1.3 is about the use of RADIUS, whereas in my mind there is no reason to specifically address RADIUS in the introduction and not SAML, GSS-API etc. I would like to have the separation between problem, design goals, implementation choices etc. much more clear because that allows us to have a 'cleaner' discussion. In particular, I would prefer to see an abstract description of the paragraphs of chapter 3 (which I think do an excellent job of stating the components) and have them instantiated in Chapter 3. Adressing of the key issues - --------------------------- The one issue that is imo only very limited addressed is that of multiple federations. Will the NAI also serve for federation selection? Does the principal need to be made aware of what federations are vaialble for a particular service? Does the IdP get to choose what federation a users is 'wielding'? depending on the answer to these questions, can we implement that in the current frameworks? Are we going to address the multiple federation problem? If not, how can that bite us later? 3.1 states that statements about the subject by the IdP are transported through AAA, is this meant to state that they will be transported *only* through AAA, or can they also be transported outside AAA (f.e. using SOAP) Detailed comments - ----------------- 1, p4 capitalize RADIUS (and throughout the doc) 1, p4: should "different roles" and "various authentication mechanisms" be bullit points too? 1, p4 "but particulary acute for the latter ans": ans -> as 1, p4: the paragraph starting with "Similarly" starts with talking about IdP selection and switches to federation selection. Which one (or both) is intended? 1, p5: the paragraph starting with "Figure 1 also shows...", I don't believe a policy is agreed upon by "some sort of administrative management", I think the adminstartive processes are rather to implement the policies that have been agreed upon oob. 1, p5: "real world entity", is this in this example not just a "natural person" instead? The "often" leaves imo enough space to also include non-human. 1, p6: so we assume different adminstrative domains but the same federation? 1, p6: steps are too implementation specific 1, p7 step 10: does the IdP authenticate or authorize the principal to the RP? How about "Once the IdP made a decision of whether and how to authorize the principal to use the service offered by the RP it will assert this to the RP" 1.2 p8: how does the no sharing of long term private keys follow from the need for multiple authentication protocols? 1.2 p8: "large number of IdPs, RPs, users" ... and federations? 1.2 p9: "The system will build upon.." -> "The system will build as much as possible build upon..." 1.3 p9: This paragraph here makes only sense for those of us entrenched in SAML federations, people coming from the AAA side may equally be interested in a paragraph about SAML here. I propose moving this to chapter 3. 3.1 p12 2nd paragraph: "is authorized to make assertions" -> "is authorized to make assertions about the principal and to that particular RP" 3.1 p12 2nd paragraph: "any old provider" -> "any RP" 3.1 p12 Federation Dynamic Referral: the identity of the principal is unknown, but the realm, isn't it? Is that not sufficient for authorizing an IdP? 3.1 p12 Federation Dynamic Referral: What is the difference between the proxy mentioned here and the one in Federation Proxy (next paragraph)? 3.1 p12 "The astute reader...", do you want to say something about RadSec here? 3.1 p13 last paragraph: So does this mean that all statements are transported through AAA, i.e. no room for SOAP interactions? 3.2 p13 "Experience has taught us...." -> "Experience has taught ...." 3.2 p13 "Experience has taught....": The authentication framework must also allow for the selection of authentication mechanisms per application, i.e. for certain applications u/p may be enough while for others hardware tokens are needed. I don't want to be forced to wield a cumbersome authentication method for low value transactions. 3.3 p14 "GSS-API is specified...": What is the relevance of mentioning the sub-operations of the initial context exchange? 3.5 p16: I don't immediately see how to improve figure 2, but I think it is not easy to understand 4 p17 It seems that part of this discussion belongs higher up in the document (design goals?) and part is implementation choices 4.1 p17: explain better what is confusing about the mutual authentication terminology 4.1 p17 "If a target name is supplied...": can the initiator only supply a target name if "the appropriate cryptographic exchanges took place"? Is it not possible that the initiator just states the target name as supplied by the acceptor and uses information from the IdP to validate this name? 4.2 p18 first paragraph: the sentence starting with "Even when it is checked" is not a well-formed sentence, and I don't understand what it should read. 4.2 p19: I don't really understand the whiteboard example, how is the user able to validate the content that is being displayed? What if some users get (slightly) different content than others? 4.2 p19 last paragraph: i think if you explain GSS-API CB you also need to explain EAP CB 4.3 p19 "Using host based service...": Why does ABFAB need to adopt this approach? 4.3 p19 "Host-based service names...": I think a few more sentences of explanation would help. Hope this is of use, Klaas > 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 > > > > _______________________________________________ > abfab mailing list > abfab@ietf.org > https://www.ietf.org/mailman/listinfo/abfab -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.14 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk0q7ioACgkQH2Wy/p4XeFLOewCeOOXh5dftA/wySbURIuTdKmaz SjEAoJ6RVpFPTmlQSPFfUq2zmtAG0T2+ =Kcm8 -----END PGP SIGNATURE----- From hartmans@painless-security.com Mon Jan 10 10:25:43 2011 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 AFC793A69CB for ; Mon, 10 Jan 2011 10:25:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.729 X-Spam-Level: X-Spam-Status: No, score=-1.729 tagged_above=-999 required=5 tests=[AWL=-0.664, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_12=0.6, J_CHICKENPOX_53=0.6] 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 VMFZTCjR1SZJ for ; Mon, 10 Jan 2011 10:25:42 -0800 (PST) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by core3.amsl.com (Postfix) with ESMTP id 2339E3A6B08 for ; Mon, 10 Jan 2011 10:25:41 -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 27101200CC; Mon, 10 Jan 2011 13:26:18 -0500 (EST) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id A7A2B4228; Mon, 10 Jan 2011 13:27:50 -0500 (EST) From: Sam Hartman To: Klaas Wierenga References: <4D10F279.3030601@cisco.com> <4D2AEE2A.1080808@cisco.com> Date: Mon, 10 Jan 2011 13:27:50 -0500 In-Reply-To: <4D2AEE2A.1080808@cisco.com> (Klaas Wierenga's message of "Mon, 10 Jan 2011 12:31:54 +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] 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: Mon, 10 Jan 2011 18:25:43 -0000 Klaas, thanks so much for your comments. I'm responding as an individual not on behalf of the authors as a group. I agree that we need to do a better job of discussing federation selection; the current text does not do much about that. This is definitely a good comment and something for us to work on. You ask whether we intend to preclude SOAP. I think that's for you to tell us: we've had a WG discussion on this topic and I think we have enough of a discussion to approach a consensus. My reading is that we are going to focus on AAA transport but nothing will preclude soap. However it would be useful to get a consensus call from the chairs on this. I agree that the specific protocol flows could be moved later in the document and that would improve things. I think it's a little complicated where you want this information: there is some value in having the diagrams fairly early. You propose introducing more abstraction: having an abstract discussion of the aspects of the system and then discussing specific technology choices. Definitely for the application integration, where we've acknowledged in our charter that other options are possible, we should do this. Also, we should separate the abstract discussion of AAA from RADIUS and Diameter. However, the use of AAA, EAP, and to some extent SAML is baked in at a fairly deep level. So, we're not obligated to treat things abstractly. We can if it makes the document flow better. However sometimes it is easier to understand one concrete system than a bunch of abstractions. So, can we explore how valuable that will actually be? 3.3 p14 "GSS-API is specified...": What is the relevance of mentioning the sub-operations of the initial context exchange? No, not really. I thought it might, but it didn't end up being useful. 4 p17 It seems that part of this discussion belongs higher up in the document (design goals?) and part is implementation choices It's hard to discuss this abstractly. I don't think we have enough community experience for that discussion nor do I think we understand what this would mean abstractly well enough to have this discussion before the discussions of concrete technologies. So, I'm sympathetic to the concern, but I'm not sure I know how to do what you ask. If you want to throw something together or have a chat, we could do that. 4.1 p17: explain better what is confusing about the mutual authentication terminology It's that to some people mutual authentication implies that the client's identity is being released. In GSS, that's not true. 4.2 p18 first paragraph: the sentence starting with "Even when it is checked" is not a well-formed sentence, and I don't understand what it should read. Ah, a typeo. s:if the trust:the trust 4.2 p19: I don't really understand the whiteboard example, how is the user able to validate the content that is being displayed? What if some users get (slightly) different content than others? Note here we're talking about a physical electronic LCD whiteboard in a room, not some shared conference whiteboard software.Typically a presenter can validate the content of their own presentation. How do we deal with attacks that give different users different content? I claim that an attack that presents different content to people in the same physical room looking at the same LCD is outside of the scope of ABFAB:-) If we make the context clear--that we're talking about a networked LCD--is this example more clear? 4.2 p19 last paragraph: i think if you explain GSS-API CB you also need to explain EAP CB I agree that this document needs to discuss EAP channel binding. We propose to do that in the unwritten section 6.1 as part of the deployment discussion. I guess we could briefly discuss in section 3 as well. 4.3 p19 "Using host based service...": Why does ABFAB need to adopt this approach? We need to adopt this approach if we want ABFAB to work with IMAP, SMTP, LDAP, SSH, NFS or a variety of other protocols that use this naming approach. We could alternatively update all those specifications and update all the implementations that use generic frameworks such as SSPI or Cyrus SASL. This is a case where following the existing standards makes deploymentand implementation easier. Can you suggest additional text for the last paragraph of this section to better clarify? From hartmans@painless-security.com Mon Jan 10 11:15:36 2011 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 007E73A6946; Mon, 10 Jan 2011 11:15:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.297 X-Spam-Level: X-Spam-Status: No, score=-2.297 tagged_above=-999 required=5 tests=[AWL=-0.032, 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 ZYcTEGKCxHV0; Mon, 10 Jan 2011 11:15:35 -0800 (PST) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by core3.amsl.com (Postfix) with ESMTP id DD4C03A683C; Mon, 10 Jan 2011 11:15: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 252752028C; Mon, 10 Jan 2011 14:16:15 -0500 (EST) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 433D14228; Mon, 10 Jan 2011 14:17:48 -0500 (EST) From: Sam Hartman To: abfab@ietf.org,kitten@ietf.org Date: Mon, 10 Jan 2011 14:17:48 -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] Multiple attribute providers in an authentication 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, 10 Jan 2011 19:15:36 -0000 Background: there was a discussion between authors of the abfab architecture proposal about multiple attribute providers. The idea is that you have an identity provider that is producing a set of attributes about a subject. In the case of ABFAB we're mostly thinking of a SAML IDP for this particular example. The IDP has some attributes it may be in a position to assert. But the IDP may also want to gather attributes from other sources and pass those along. One option it has is to simply pass the attributes along as if it issued them itself. That option isn't really interesting from a protocol standpoint because it is indistinguishable from the IDP actually issuing the attribute itself. That is probably a fine thing to do in certain deployments but we don't need to spend a lot of time on it. Another option is that the IDP can go actually get a SAML assertion (or attribute certificate or the like) and include that in what is sent to the RP. At first glance, the protocol implications of doing this look simple. You just stick the assertion in the existing bag of bits and move on. however, it's not that simple because of semantics. Today in ABFAB, we haven't done a great job of describing what the trust semantics of the attribute in draft-ietf-abfab-aaa-saml are. However what has been going through at least Josh and my mind is that the RP SHOULD assume that the AAA framework provides an integrity protected channel for that SAML message. The message is actually issued by the IDP corresponding to the NAI used to make the access request. In addition, for the SAML assertions sent from the IDP to the RP, the RP SHOULD assume that the IDP is asserting those attributes about the subject. That is, the RP need not perform any validation of the SAML assertion. The RP still needs to validate whether the IDP is permitted to make the claims it does. There's no requirement that these SAML assertions be signed. The IDP MAY sign the assertion; the RP MAY consider any signatures that are present. However in the interoperable case, any signatures that are present are ignored. If there are multiple assertions from the same IDP it seems reasonable to treat them all the same. Things get a lot more messy when assertions from multiple IDPs are included. What does it mean to include them in the AAA transport? I can think of several trust models that are appropriate depending on deployment: * The IDP corresponding to the subject's NAI has validated these additional assertions and wishes to assert that the attributes can be trusted. "If you trust me then you should trust these." Here, the assertions are being included either for convenience of packaging the attributes into some form the RP can process or because it is possible that the RP may be able to validate some signature and trust the attribute source more than the IDP. * The subject IDP has performed SAML validation on the assertions. However the IDP is making no claims about how trusted the attributes included in the additional assertions are. Even if the IDP would be permitted to make a claim made in an additional assertion, the RP needs to make an independent policy decision about whether the actual issuer should be permitted to make that claim. * Here are some assertions for the RP's convenience. The IDP makes no claims about them; not even the implied claim that they have not been modified in transit. They better be signed, the RP better have metadata for their issuer, and the RP is more or less on its own. Another source of complexity surrounds how an IDP links an assertion to a subject. What confidence is the RP asserting that the additional assertion describes the same principal as the access-accept message. Another potential source of complexity is how does the IDP know what information to gather? Does the IDP just know somehow? Does the RP pass information back? How does the RP make the policy decisions it needs to make? How does it get metadata that is needed? I think this sort of issue will also have impacts for kitten, because we'll need to describe it in the naming extensions interface. It seems like ABFAB is not going to be the only group facing these sorts of discussions; Kerberos is in the middle of a similar discussion right now. From lear@cisco.com Mon Jan 10 11:53:40 2011 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 07E8328C0E4; Mon, 10 Jan 2011 11:53:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.2 X-Spam-Level: X-Spam-Status: No, score=-110.2 tagged_above=-999 required=5 tests=[AWL=0.398, 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 Lh3K7Wt4TrbR; Mon, 10 Jan 2011 11:53:38 -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 A94D028C0FF; Mon, 10 Jan 2011 11:53:37 -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: ArkEAFrzKk2Q/khNgWdsb2JhbACECJtkhF4VAQEWIiSieopTjXWCdYFjdASLCg Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-1.cisco.com with ESMTP; 10 Jan 2011 19:55:51 +0000 Received: from ams3-vpn-dhcp5297.cisco.com (ams3-vpn-dhcp5297.cisco.com [10.61.84.176]) by ams-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p0AJtpDW014723; Mon, 10 Jan 2011 19:55:51 GMT Message-ID: <4D2B644D.9090201@cisco.com> Date: Mon, 10 Jan 2011 20:55:57 +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: In-Reply-To: X-Enigmail-Version: 1.1.1 Content-Type: multipart/alternative; boundary="------------080403070403000002060300" Cc: kitten@ietf.org, abfab@ietf.org Subject: Re: [abfab] Multiple attribute providers in an authentication 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, 10 Jan 2011 19:53:40 -0000 This is a multi-part message in MIME format. --------------080403070403000002060300 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Sam, Thanks for taking the time to describe the problem. On 1/10/11 8:17 PM, Sam Hartman wrote: > Background: there was a discussion between authors of the abfab > architecture proposal about multiple attribute providers. > The idea is that you have an identity provider that is producing a set > of attributes about a subject. In the case of ABFAB we're mostly > thinking of a SAML IDP for this particular example. > > The IDP has some attributes it may be in a position to assert. > But the IDP may also want to gather attributes from other sources and > pass those along. > > One option it has is to simply pass the attributes along as if it issued > them itself. That option isn't really interesting from a protocol > standpoint because it is indistinguishable from the IDP actually issuing > the attribute itself. That is probably a fine thing to do in certain > deployments but we don't need to spend a lot of time on it. > > Another option is that the IDP can go actually get a SAML assertion (or > attribute certificate or the like) and include that in what is sent to > the RP. > > At first glance, the protocol implications of doing this look > simple. You just stick the assertion in the existing bag of bits and > move on. > > however, it's not that simple because of semantics. > > Today in ABFAB, we haven't done a great job of describing what the trust > semantics of the attribute in draft-ietf-abfab-aaa-saml are. However > what has been going through at least Josh and my mind is that the RP > SHOULD assume that the AAA framework provides an integrity protected > channel for that SAML message. The message is actually issued by the IDP > corresponding to the NAI used to make the access request. In addition, > for the SAML assertions sent from the IDP to the RP, the RP SHOULD > assume that the IDP is asserting those attributes about the subject. > That is, the RP need not perform any validation of the SAML > assertion. The RP still needs to validate whether the IDP is permitted > to make the claims it does. > There's no requirement that these SAML assertions be signed. > The IDP MAY sign the assertion; the RP MAY consider any signatures that > are present. However in the interoperable case, any signatures that are > present are ignored. You mean is that the security model you have in mind does not require that SAML assertions be signed? We may have an additional software layering problem- specifically, if they are present, and you're using a SAML library to parse the messages, from a practical standpoint, an error may be returned. However, I think what you're alluding to is that the lack of a signature itself is *part* of the problem of returning attributes from 3rd parties, since the associated connectivity of the AAA transport is providing authenticity and *not *the signature. > [snip] > Another source of complexity surrounds how an IDP links an assertion to > a subject. What confidence is the RP asserting that the additional > assertion describes the same principal as the access-accept message. On this point - the IdP either is or is not authoritative for knowing at the very least where the information is going to come from. The only question here is whether or not it is willing to vouch for the information itself. > Another potential source of complexity is how does the IDP know what > information to gather? Does the IDP just know somehow? Does the RP pass > information back? And this is a generic problem with attribute providers. The general answer is either that the principal provides a pointer, or it finds the information through external means. Again, the only issues in this case are whether the IdP is providing some sort of surety, and whether it can be assumed that there is a trust relationship between the RP and the attribute provider. That latter one is a much bigger deal, IMHO! Regards, Eliot --------------080403070403000002060300 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit Sam,

Thanks for taking the time to describe the problem. 

On 1/10/11 8:17 PM, Sam Hartman wrote: 
Background: there was a discussion between authors of the abfab
architecture proposal about multiple attribute providers.
The idea is that you have an identity provider that is producing a set
of attributes about a subject. In the case of ABFAB we're mostly
thinking of a SAML IDP for this particular example.

The IDP  has some attributes it may be in a position to assert.
But the IDP may also want to gather attributes from other  sources and
pass those along.

One option it has is to simply pass the attributes along as if it issued
them itself.  That option isn't really interesting from a protocol
standpoint because it is indistinguishable from the IDP actually issuing
the attribute itself.  That is probably a fine thing to do in certain
deployments but we don't need to spend a lot of time on it.

Another option is that the IDP can go actually get a SAML assertion (or
attribute certificate or the like) and include that in what is sent to
the RP.

At first glance, the protocol implications of doing this look
simple. You just stick the assertion in the existing bag of bits and
move on.

however, it's not that simple because of semantics.

Today in ABFAB, we haven't done a great job of describing what the trust
semantics of the attribute in draft-ietf-abfab-aaa-saml are. However
what has been going through at least Josh and my mind is that the RP
SHOULD assume that the AAA framework provides an integrity protected
channel for that SAML message. The message is actually issued by the IDP
corresponding to the NAI used to make the access request. In addition,
for the SAML assertions sent from the IDP to the RP, the RP SHOULD
assume that the IDP is asserting those attributes about the subject.
That is, the RP need not perform any validation of the SAML
assertion. The RP still needs to validate whether the IDP is permitted
to make the claims it does.
There's no requirement that these SAML assertions be signed.
The IDP MAY sign the assertion; the RP MAY consider any signatures that
are present. However in the interoperable case, any signatures that are
present are ignored.

You mean is that the security model you have in mind does not require that SAML assertions be signed?  We may have an additional software layering problem- specifically, if they are present, and you're using a SAML library to parse the messages, from a practical standpoint, an error may be returned.

However, I think what you're alluding to is that the lack of a signature itself is part of the problem of returning attributes from 3rd parties, since the associated connectivity of the AAA transport is providing authenticity and not the signature.


[snip]


Another source of complexity surrounds how an IDP links an assertion to
a subject. What confidence is the RP asserting that the additional
assertion describes the same principal as the access-accept message.

On this point - the IdP either is or is not authoritative for knowing at the very least where the information is going to come from.  The only question here is whether or not it is willing to vouch for the information itself.
Another potential source of complexity is how does the IDP know what
information to gather? Does the IDP just know somehow? Does the RP pass
information back?
And this is a generic problem with attribute providers.  The general answer is either that the principal provides a pointer, or it finds the information through external means.  Again, the only issues in this case are whether the IdP is providing some sort of surety, and whether it can be assumed that there is a trust relationship between the RP and the attribute provider.  That latter one is a much bigger deal, IMHO!

Regards,

Eliot
--------------080403070403000002060300-- From cantor.2@osu.edu Mon Jan 10 12:16:54 2011 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 8555E28C136; Mon, 10 Jan 2011 12:16:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.563 X-Spam-Level: X-Spam-Status: No, score=-3.563 tagged_above=-999 required=5 tests=[AWL=0.036, 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 vjzBEqbn8eSu; Mon, 10 Jan 2011 12:16:53 -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 8CE9128C12F; Mon, 10 Jan 2011 12:16:53 -0800 (PST) Received: from CIO-TNC-HT06.osuad.osu.edu ([164.107.81.172]) by defang16.it.ohio-state.edu (8.13.7/8.13.1) with ESMTP id p0AKIjWR017425; Mon, 10 Jan 2011 15:18:45 -0500 Received: from CIO-KRC-D1MBX01.osuad.osu.edu ([fe80::450b:35e6:80f4:f3e0]) by CIO-TNC-HT06.osuad.osu.edu ([fe80::8c6c:9f26:5aa2:4458%25]) with mapi; Mon, 10 Jan 2011 15:15:45 -0500 From: "Cantor, Scott E." To: Eliot Lear , Sam Hartman Thread-Topic: [abfab] Multiple attribute providers in an authentication Thread-Index: AQHLsPqpupjdQ+ISDUWABPRpdmimLpPK8qeA//+xKoA= Date: Mon, 10 Jan 2011 20:18:46 +0000 Message-ID: <7EE86E89365CA94F8E7B8251F92607100320BB@CIO-KRC-D1MBX01.osuad.osu.edu> References: <4D2B644D.9090201@cisco.com> In-Reply-To: <4D2B644D.9090201@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CanIt-Geo: ip=164.107.81.172; 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 Cc: "kitten@ietf.org" , "abfab@ietf.org" Subject: Re: [abfab] Multiple attribute providers in an authentication 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, 10 Jan 2011 20:16:54 -0000 PiBZb3UgbWVhbiBpcyB0aGF0IHRoZSBzZWN1cml0eSBtb2RlbCB5b3UgaGF2ZSBpbiBtaW5kIGRv ZXMgbm90IHJlcXVpcmUgdGhhdA0KPiBTQU1MIGFzc2VydGlvbnMgYmUgc2lnbmVkPyAgV2UgbWF5 IGhhdmUgYW4gYWRkaXRpb25hbCBzb2Z0d2FyZSBsYXllcmluZw0KPiBwcm9ibGVtLSBzcGVjaWZp Y2FsbHksIGlmIHRoZXkgYXJlIHByZXNlbnQsIGFuZCB5b3UncmUgdXNpbmcgYSBTQU1MIGxpYnJh cnkgdG8NCj4gcGFyc2UgdGhlIG1lc3NhZ2VzLCBmcm9tIGEgcHJhY3RpY2FsIHN0YW5kcG9pbnQs IGFuIGVycm9yIG1heSBiZSByZXR1cm5lZC4NCg0KVGhhdCBzaG91bGRuJ3QgYmUgYSBjb25jZXJu LCBvciBpZiBpdCBpcyB5b3UndmUgZ290IG11Y2ggYmlnZ2VyIHByb2JsZW1zIGJlY2F1c2UgdGhl IGFzc3VtcHRpb25zIGFib3V0IHRydXN0IGFuZCBrZXkgbWFuYWdlbWVudCB0aGF0IHN1Y2ggYnJv a2VuIGNvZGUgd291bGQgbWFrZSB3aWxsIGJlIGEgcHJvYmxlbSBpbiB0aGVpciBvd24gcmlnaHQu DQoNCj4gSG93ZXZlciwgSSB0aGluayB3aGF0IHlvdSdyZSBhbGx1ZGluZyB0byBpcyB0aGF0IHRo ZSBsYWNrIG9mIGEgc2lnbmF0dXJlIGl0c2VsZiBpcw0KPiBwYXJ0IG9mIHRoZSBwcm9ibGVtIG9m IHJldHVybmluZyBhdHRyaWJ1dGVzIGZyb20gM3JkIHBhcnRpZXMsIHNpbmNlIHRoZQ0KPiBhc3Nv Y2lhdGVkIGNvbm5lY3Rpdml0eSBvZiB0aGUgQUFBIHRyYW5zcG9ydCBpcyBwcm92aWRpbmcgYXV0 aGVudGljaXR5IGFuZCBub3QNCj4gdGhlIHNpZ25hdHVyZS4NCg0KSSB0aGluayBpdCdzIG1vcmUg dGhhdCBpZiB5b3Ugc3RpY2sgd2l0aCB0aGUgc2ltcGxlIGNhc2UsIHlvdSBkb24ndCBuZWVkIHRo ZW0sIGFuZCBpZiB5b3UgZG8gbmVlZCB0aGVtLCAgYSBob3N0IG9mIG1vcmUgY29tcGxleCBjb25j ZXJucyBiZWNvbWUgaW1wb3J0YW50Lg0KDQo+IAlBbm90aGVyIHNvdXJjZSBvZiBjb21wbGV4aXR5 IHN1cnJvdW5kcyBob3cgYW4gSURQIGxpbmtzIGFuIGFzc2VydGlvbiB0bw0KPiAJYSBzdWJqZWN0 LiBXaGF0IGNvbmZpZGVuY2UgaXMgdGhlIFJQIGFzc2VydGluZyB0aGF0IHRoZSBhZGRpdGlvbmFs DQo+IAlhc3NlcnRpb24gZGVzY3JpYmVzIHRoZSBzYW1lIHByaW5jaXBhbCBhcyB0aGUgYWNjZXNz LWFjY2VwdCBtZXNzYWdlLg0KPiANCj4gT24gdGhpcyBwb2ludCAtIHRoZSBJZFAgZWl0aGVyIGlz IG9yIGlzIG5vdCBhdXRob3JpdGF0aXZlIGZvciBrbm93aW5nIGF0IHRoZSB2ZXJ5DQo+IGxlYXN0 IHdoZXJlIHRoZSBpbmZvcm1hdGlvbiBpcyBnb2luZyB0byBjb21lIGZyb20uICBUaGUgb25seSBx dWVzdGlvbiBoZXJlIGlzDQo+IHdoZXRoZXIgb3Igbm90IGl0IGlzIHdpbGxpbmcgdG8gdm91Y2gg Zm9yIHRoZSBpbmZvcm1hdGlvbiBpdHNlbGYuDQoNClNvbWUgcGVvcGxlIChJIHNob3VsZCBiZSBj bGVhciBJJ20gbm90IG9uZSBvZiB0aGVtKSBiZWxpZXZlIHRoYXQgd2l0aG91dCBhIHVuaWZvcm0g c3ViamVjdCBpZGVudGlmaWVyIGFjcm9zcyBhbGwgc3VjaCBhc3NlcnRpb25zLCB5b3UgbG9zZSBh bnkgaG9wZSBvZiBhdWRpdGluZyB0aGUgbGlua2FiaWxpdHkgb2YgdGhlIGlkZW50aWVzIGxhdGVy LiBBbmQgYWNoaWV2aW5nIHRoYXQgdW5pZm9ybWl0eSBkb2VzIHNvbWUgdG9ydHVvdXMgdGhpbmdz IHRvIHRoZSBTQU1MIGZsb3dzIG5lZWRlZCB0byBnZXQgdGhlIGFzc2VydGlvbnMgYnVpbHQuDQoN CkkgYWdyZWUgd2l0aCBFbGlvdCB0aGF0IHRoZSBpc3N1ZXMgYXNzb2NpYXRlZCB3aXRoIGtub3dp bmcgd2hhdCBhdHRyaWJ1dGVzIHRvIGdldCwgd2hhdCBzb3VyY2VzIHRvIHVzZSwgZXRjLiwgYXJl IGdlbmVyYWwgcHJvYmxlbXMsIG5vdCBjb25maW5lZCB0byB0aGlzIHVzZSBvZiBTQU1MLCBvciB0 byBTQU1MIGl0c2VsZi4NCg0KQnV0IHVzdWFsbHkgd2hlbiBhZ2dyZWdhdGlvbiBpcyBpbnZvbHZl ZCwgdGhlcmUgaXMgbGVzcyBuZWVkIGZvciBhIGZ1bGx5IGR5bmFtaWMgc3lzdGVtIHdpdGhvdXQg YWRtaW5pc3RyYXRpdmUgaW50ZXJ2ZW50aW9uLCBpbiBteSBleHBlcmllbmNlLg0KDQotLSBTY290 dA0KDQo= From hartmans@painless-security.com Mon Jan 10 12:20:58 2011 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 C1AA528C12D; Mon, 10 Jan 2011 12:20:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.296 X-Spam-Level: X-Spam-Status: No, score=-2.296 tagged_above=-999 required=5 tests=[AWL=-0.031, 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 ZtQ+QUY74Vml; Mon, 10 Jan 2011 12:20:57 -0800 (PST) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by core3.amsl.com (Postfix) with ESMTP id 9A55428C115; Mon, 10 Jan 2011 12:20: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 D394620220; Mon, 10 Jan 2011 15:21:37 -0500 (EST) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id E94A84228; Mon, 10 Jan 2011 15:23:10 -0500 (EST) From: Sam Hartman To: Eliot Lear References: <4D2B644D.9090201@cisco.com> Date: Mon, 10 Jan 2011 15:23:10 -0500 In-Reply-To: <4D2B644D.9090201@cisco.com> (Eliot Lear's message of "Mon, 10 Jan 2011 20:55:57 +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: kitten@ietf.org, abfab@ietf.org Subject: Re: [abfab] Multiple attribute providers in an authentication 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, 10 Jan 2011 20:20:58 -0000 >>>>> "Eliot" == Eliot Lear writes: Eliot> Sam, Thanks for taking the time to describe the problem. You are welcome. I realized that I did not explicitly say it, but I think all these complexities are tractable. We will have to do work in order to support this use case. I think that work is not in scope for what we're signed up to do now, although if someone stepped forward and wanted to do the work, it could happen sooner. I think that some of this may require some work in kitten. > Today in ABFAB, we haven't done a great job of describing > what the trust semantics of the attribute in > draft-ietf-abfab-aaa-saml are. However what has been going > through at least Josh and my mind is that the RP SHOULD > assume that the AAA framework provides an integrity protected > channel for that SAML message. The message is actually issued > by the IDP corresponding to the NAI used to make the access > request. In addition, for the SAML assertions sent from the > IDP to the RP, the RP SHOULD assume that the IDP is asserting > those attributes about the subject. That is, the RP need not > perform any validation of the SAML assertion. The RP still > needs to validate whether the IDP is permitted to make the > claims it does. There's no requirement that these SAML > assertions be signed. The IDP MAY sign the assertion; the RP > MAY consider any signatures that are present. However in the > interoperable case, any signatures that are present are > ignored. Eliot> You mean is that the security model you have in mind does not Eliot> require that SAML assertions be signed? We may have an Eliot> additional software layering problem- specifically, if they Eliot> are present, and you're using a SAML library to parse the Eliot> messages, from a practical standpoint, an error may be Eliot> returned. Perhaps. With Shibboleth we certainly are no longer having issues with this. I'd be interested in hearing from other SAML implementeors. Note that you are equally likely to have trouble if the message is signed and you don't have metadata. So, you're going to have a better user experience if your SAML library does not require signatures. Eliot> However, I think what you're alluding to is that the lack of Eliot> a signature itself is part of the problem of returning Eliot> attributes from 3rd parties, since the associated Eliot> connectivity of the AAA transport is providing authenticity Eliot> and not the signature. No; you can always (as the issuer at least) add signatures. Supporting a case where the third party attributes are just carried and the RP is responsible for validation is fairly easy at the protocol level. It probably requires a different AAA attribute that doesn't imply the contents should be trusted. That is, the RP is free to ignore signatures on assertions in the current attribute, but would need to validate assertions from third parties. However that's one new AAA attribute, which is fairly simple. My personal opinion is that it's also fairly useless. We're assuming that the RP and IDP don't have any requirement for a trust relationship other than through the AAA fabric. Why is it more reasonable to assume a trust relationship with a third party. There are some situations where this model is exactly what you need. Complexity comes in if you want to offload more trust to the IDP. Eliot> [snip] > Another source of complexity surrounds how an IDP links > an assertion to a subject. What confidence is the RP > asserting that the additional assertion describes the same > principal as the access-accept message. Eliot> On this point - the IdP either is or is not authoritative for Eliot> knowing at the very least where the information is going to Eliot> come from. I agree with this sentence. I don't understand how it fits into the quoted paragraph above. Eliot> The only question here is whether or not it is Eliot> willing to vouch for the information itself. I agree that's a question. I'm again not sure that it fits into the question of subject linkage, except that one hopes the subject linkage is fairly good if the IDP does vouch for the information. > Another potential source of complexity is how does the > IDP know what information to gather? Does the IDP just know > somehow? Does the RP pass information back? Eliot> And this is a generic problem with attribute providers. The Eliot> general answer is either that the principal provides a Eliot> pointer, or it finds the information through external means. Sure. But we need to provide protocols and APIs to actually convey that throughout the system. It's real engineering that needs doing for things to work, but again is certainly something we can do. Eliot> Eliot> Again, the only issues in this case are whether the IdP is Eliot> providing some sort of surety, and whether it can be assumed Eliot> that there is a trust relationship between the RP and the Eliot> attribute provider. That latter one is a much bigger deal, Eliot> IMHO! I'm definitely missing how these relate to what information the RP wants. From lear@cisco.com Mon Jan 10 13:25:40 2011 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 391E03A6801; Mon, 10 Jan 2011 13:25:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.21 X-Spam-Level: X-Spam-Status: No, score=-110.21 tagged_above=-999 required=5 tests=[AWL=0.389, 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 kK1GSsuBqhAt; Mon, 10 Jan 2011 13:25:39 -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 00C5F3A6812; Mon, 10 Jan 2011 13:25:37 -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: AqsEAOwIK02Q/khMgWdsb2JhbACECKBDFQEBFiIkonuKU44BgSGDN3QEiwo Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-2.cisco.com with ESMTP; 10 Jan 2011 21:27:52 +0000 Received: from ams3-vpn-dhcp5297.cisco.com (ams3-vpn-dhcp5297.cisco.com [10.61.84.176]) by ams-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p0ALRpts029677; Mon, 10 Jan 2011 21:27:51 GMT Message-ID: <4D2B79DE.6080009@cisco.com> Date: Mon, 10 Jan 2011 22:27:58 +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: <4D2B644D.9090201@cisco.com> In-Reply-To: X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: kitten@ietf.org, abfab@ietf.org Subject: Re: [abfab] Multiple attribute providers in an authentication 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, 10 Jan 2011 21:25:40 -0000 Hi Sam, Thanks for your response. Let me add that this is really not a big issue with me for now. I see some very interesting use cases that relate to liability concerns around certain attributes, and I consider this conversation useful just to the point of knowing whether we are able to accomplish the task of having attribute providers later, if and when demand warrants. Just on one point: >> Another source of complexity surrounds how an IDP links >> an assertion to a subject. What confidence is the RP >> asserting that the additional assertion describes the same >> principal as the access-accept message. > > Eliot> On this point - the IdP either is or is not authoritative for > Eliot> knowing at the very least where the information is going to > Eliot> come from. > > I agree with this sentence. I don't understand how it fits into the > quoted paragraph above. I may have misunderstood what you originally wrote. Perhaps what you are saying is that if there is absolutely no requirement that the IdP trust the attribute provider at all, that it simply passes bits, then there is a risk that the information returned might not be related to the principal. I would suggest that it is incumbent on the attribute provider to at least make an assurance that it won't happen, because you're right- the RP cannot be assured otherwise because it may not have sufficient information or even authorization to reference the principal to the RP. One other challenge here would be to consider whether it is permissible that the unique index or name of the principal in the context of the attribute provider could leak to the RP. If that name is covered by a signature, it cannot easily be removed. Eliot From klaas@cisco.com Mon Jan 10 13:35:10 2011 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 2238B3A67DA for ; Mon, 10 Jan 2011 13:35:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.999 X-Spam-Level: X-Spam-Status: No, score=-9.999 tagged_above=-999 required=5 tests=[AWL=-0.600, BAYES_00=-2.599, J_CHICKENPOX_12=0.6, J_CHICKENPOX_53=0.6, 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 jO1yhSBfFwDu for ; Mon, 10 Jan 2011 13:35:04 -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 F40413A680C for ; Mon, 10 Jan 2011 13:35:03 -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: AqoEAE0LK02Q/khMgWdsb2JhbACkSxUBARYiJKJ/mFiCdYJXBIsK Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-2.cisco.com with ESMTP; 10 Jan 2011 21:37:18 +0000 Received: from macmini.wierenga.net (ams-kwiereng-8712.cisco.com [10.55.220.243]) by ams-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p0ALbHGM031854; Mon, 10 Jan 2011 21:37:18 GMT Message-ID: <4D2B7C0D.4070200@cisco.com> Date: Mon, 10 Jan 2011 22:37:17 +0100 From: Klaas Wierenga User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-GB; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Sam Hartman References: <4D10F279.3030601@cisco.com> <4D2AEE2A.1080808@cisco.com> In-Reply-To: X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: abfab@ietf.org Subject: Re: [abfab] 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: Mon, 10 Jan 2011 21:35:10 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 1/10/11 7:27 PM, Sam Hartman wrote: Hi Sam, > Klaas, thanks so much for your comments. > I'm responding as an individual not on behalf of the authors as a group. > > I agree that we need to do a better job of discussing federation > selection; the current text does not do much about that. This is > definitely a good comment and something for us to work on. > > You ask whether we intend to preclude SOAP. I think that's for you to > tell us: we've had a WG discussion on this topic and I think we have > enough of a discussion to approach a consensus. My reading is that we > are going to focus on AAA transport but nothing will preclude soap. > However it would be useful to get a consensus call from the chairs on > this. sure, I was wondering if it was your intent to put a stake in the ground in this doc or not. > > I agree that the specific protocol flows could be moved later in the > document and that would improve things. > I think it's a little complicated where you want this information: there > is some value in having the diagrams fairly early. true... perhaps kick of 3 with it and then start explaining it as you go in 3? > > You propose introducing more abstraction: having an abstract discussion > of the aspects of the system and then discussing specific technology > choices. Definitely for the application integration, where we've > acknowledged in our charter that other options are possible, we should > do this. Also, we should separate the abstract discussion of AAA from > RADIUS and Diameter. > However, the use of AAA, EAP, and to some extent SAML is baked in at a > fairly deep level. > So, we're not obligated to treat things abstractly. No, I understand what you say, I was pondering the same before I typed my comment. But I think it would be good for the reader to understand what *functionality* we need to provide versus *how* we provide that functionality. I like the separation of concerns in 3, perhaps good to state them in the introduction and link them to the technology choice we made without further explanation in this chapter? > We can if it makes the document flow better. However sometimes it is > easier to understand one concrete system than a bunch of abstractions. > So, can we explore how valuable that will actually be? sure, this was really a discussion topic. > > > 3.3 p14 "GSS-API is specified...": What is the relevance of mentioning > the sub-operations of the initial context exchange? > > > No, not really. > I thought it might, but it didn't end up being useful. > > > 4 p17 It seems that part of this discussion belongs higher up in the > document (design goals?) and part is implementation choices > > It's hard to discuss this abstractly. I don't think we have enough > community experience for that discussion nor do I think we understand > what this would mean abstractly well enough to have this discussion > before the discussions of concrete technologies. > So, I'm sympathetic to the concern, but I'm not sure I know how to do > what you ask. > If you want to throw something together or have a chat, we could do > that. hmm yes, I'll have a look and see if I can come up with a proposal > > 4.1 p17: explain better what is confusing about the mutual > authentication terminology > > It's that to some people mutual authentication implies that the client's > identity is being released. > In GSS, that's not true. ok, I think it is fine to just say that then. > > > 4.2 p18 first paragraph: the sentence starting with "Even when it is > checked" is not a well-formed sentence, and I don't understand what it > should read. > > Ah, a typeo. s:if the trust:the trust > 4.2 p19: I don't really understand the whiteboard example, how is the > user able to validate the content that is being displayed? What if some > users get (slightly) different content than others? > > Note here we're talking about a physical electronic LCD whiteboard in a > room, not some shared conference whiteboard software.Typically a > presenter can validate the content of their own presentation. How do we > deal with attacks that give different users different content? I claim > that an attack that presents different content to people in the same > physical room looking at the same LCD is outside of the scope of > ABFAB:-) > If we make the context clear--that we're talking about a networked > LCD--is this example more clear? absolutely! I was indeed thinking of a conference WB > 4.2 p19 last paragraph: i think if you explain GSS-API CB you also need > to explain EAP CB > > I agree that this document needs to discuss EAP channel binding. We > propose to do that in the unwritten section 6.1 as part of the > deployment discussion. > I guess we could briefly discuss in section 3 as well. > 4.3 p19 "Using host based service...": Why does ABFAB need to adopt this > approach? > > > We need to adopt this approach if we want ABFAB to work with IMAP, SMTP, > LDAP, SSH, NFS or a variety of other protocols that use this naming > approach. We could alternatively update all those specifications and > update all the implementations that use generic frameworks such as SSPI > or Cyrus SASL. This is a case where following the existing standards > makes deploymentand implementation easier. right, that makes sense, and should be stated > Can you suggest additional text for the last paragraph of this section > to better clarify? I'll try Klaas -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.14 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk0rfA0ACgkQH2Wy/p4XeFKmfQCfd+rw+BGXoYsbRlf+qN60nUb/ aaUAmwT3f0mbrQgXmevyYk1rQhFziK/o =etSd -----END PGP SIGNATURE----- From hartmans@painless-security.com Mon Jan 10 15:51:50 2011 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 52AEB3A680E; Mon, 10 Jan 2011 15:51:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.294 X-Spam-Level: X-Spam-Status: No, score=-2.294 tagged_above=-999 required=5 tests=[AWL=-0.029, 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 zSuqRouy9CS8; Mon, 10 Jan 2011 15:51:49 -0800 (PST) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by core3.amsl.com (Postfix) with ESMTP id 988013A680B; Mon, 10 Jan 2011 15:51: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 92F312028C; Mon, 10 Jan 2011 18:52:29 -0500 (EST) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 0E7074228; Mon, 10 Jan 2011 18:54:03 -0500 (EST) From: Sam Hartman To: Eliot Lear References: <4D2B644D.9090201@cisco.com> <4D2B79DE.6080009@cisco.com> Date: Mon, 10 Jan 2011 18:54:03 -0500 In-Reply-To: <4D2B79DE.6080009@cisco.com> (Eliot Lear's message of "Mon, 10 Jan 2011 22:27:58 +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: kitten@ietf.org, abfab@ietf.org Subject: Re: [abfab] Multiple attribute providers in an authentication 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, 10 Jan 2011 23:51:50 -0000 >>>>> "Eliot" == Eliot Lear writes: Eliot> Perhaps what you are saying is that if there is absolutely no Eliot> requirement that the IdP trust the attribute provider at all, Eliot> that it simply passes bits, then there is a risk that the Eliot> information returned might not be related to the principal. Eliot> I would suggest that it is incumbent on the attribute Eliot> provider to at least make an assurance that it won't happen, Eliot> because you're right- the RP cannot be assured otherwise Eliot> because it may not have sufficient information or even Eliot> authorization to reference the principal to the RP. That's one case. Another case is where say you are linking principals based on names and you have two principals with the same name. E.G. I want to provide an assertion about credit availability. My credit score attribute provider can linke based on SSN (in the US) or name. The IDP doesn't have the SSN, so it has to ask about the name. What happens if the linking is off. Eliot> One other challenge here would be to consider whether it is Eliot> permissible that the unique index or name of the principal in Eliot> the context of the attribute provider could leak to the RP. Eliot> If that name is covered by a signature, it cannot easily be Eliot> removed. O, thanks for enumerating this one! From gabilm@um.es Mon Jan 10 23:59:15 2011 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 E49FB3A6941; Mon, 10 Jan 2011 23:59:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 tlveay-QxLX0; Mon, 10 Jan 2011 23:59:15 -0800 (PST) Received: from xenon13.um.es (xenon13.um.es [155.54.212.167]) by core3.amsl.com (Postfix) with ESMTP id ACBB83A69DC; Mon, 10 Jan 2011 23:59:14 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by xenon13.um.es (Postfix) with ESMTP id 5400E5D482; Tue, 11 Jan 2011 09:01:28 +0100 (CET) X-Virus-Scanned: by antispam in UMU at xenon13.um.es Received: from xenon13.um.es ([127.0.0.1]) by localhost (xenon13.um.es [127.0.0.1]) (amavisd-new, port 10024) with LMTP id g0bzr4X2woAY; Tue, 11 Jan 2011 09:01:27 +0100 (CET) Received: from inf-205-128.inf.um.es (inf-205-128.inf.um.es [155.54.205.128]) (Authenticated sender: gabilm) by xenon13.um.es (Postfix) with ESMTPA id 0E5B45D465; Tue, 11 Jan 2011 09:01:23 +0100 (CET) Message-ID: <4D2C0E57.2010302@um.es> Date: Tue, 11 Jan 2011 09:01:27 +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: Sam Hartman References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: kitten@ietf.org, abfab@ietf.org Subject: Re: [abfab] Multiple attribute providers in an authentication 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, 11 Jan 2011 07:59:16 -0000 El 10/01/11 20:17, Sam Hartman escribió: > > Things get a lot more messy when assertions from multiple IDPs are > included. > What does it mean to include them in the AAA transport? I can think of > several trust models that are appropriate depending on deployment: > > * The IDP corresponding to the subject's NAI has validated these > additional assertions and wishes to assert that the attributes can be > trusted. "If you trust me then you should trust these." Here, the > assertions are being included either for convenience of packaging the > attributes into some form the RP can process or because it is possible > that the RP may be able to validate some signature and trust the > attribute source more than the IDP. It should require a trust relationship between attribute providers and idp, in order to validate attribute assertions before to sent them all together to the RP. I just want to remark the requirement of this trust relationship. > * The subject IDP has performed SAML validation on the > assertions. However the IDP is making no claims about how trusted the > attributes included in the additional assertions are. Even if the IDP > would be permitted to make a claim made in an additional assertion, > the RP needs to make an independent policy decision about whether the > actual issuer should be permitted to make that claim. > you could include here XACML > * Here are some assertions for the RP's convenience. The IDP makes no > claims about them; not even the implied claim that they have not been > modified in transit. They better be signed, the RP better have > metadata for their issuer, and the RP is more or less on its own. I'm not sure to understand this point. Do you need the trust relationship between RP and idP? > Another source of complexity surrounds how an IDP links an assertion to > a subject. What confidence is the RP asserting that the additional > assertion describes the same principal as the access-accept message. > > Another potential source of complexity is how does the IDP know what > information to gather? Does the IDP just know somehow? Does the RP pass > information back? The RP could request specific attributes in a SAML Attribute Query. Beside, idP/attribute provider could decide what attributes be disclosed to the RP, by means of attribute release policies (XACML?) regards, Gabi. > How does the RP make the policy decisions it needs to make? How does it > get metadata that is needed? > > I think this sort of issue will also have impacts for kitten, because > we'll need to describe it in the naming extensions interface. It seems > like ABFAB is not going to be the only group facing these sorts of > discussions; Kerberos is in the middle of a similar discussion right > now. > > _______________________________________________ > 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 hartmans@painless-security.com Wed Jan 12 07:15:19 2011 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 6971328C13D for ; Wed, 12 Jan 2011 07:15:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.293 X-Spam-Level: X-Spam-Status: No, score=-2.293 tagged_above=-999 required=5 tests=[AWL=-0.028, 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 u3COUYYR0QBj for ; Wed, 12 Jan 2011 07:15:18 -0800 (PST) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by core3.amsl.com (Postfix) with ESMTP id B520128C146 for ; Wed, 12 Jan 2011 07:15: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 40817202B2 for ; Wed, 12 Jan 2011 10:15:57 -0500 (EST) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 8DBCB432C; Wed, 12 Jan 2011 10:17:27 -0500 (EST) From: Sam Hartman To: abfab@ietf.org Date: Wed, 12 Jan 2011 10:17:27 -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] We might want two sessions 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, 12 Jan 2011 15:15:19 -0000 I think we have a lot of things on the agenda next time: * Architecture doc * I just sat in on a call and I believe there will be a proposed use * case doc * gss main spec * Gss naming spec * The AAA SAML doc * Discussion of where our dependencies are ** naming exts from kitten ** channel binding from EMU We didn't even get to the gss naming document last time, and we had more SAML discussion than we really had time for. It's also fairly likely that we're going to have some implementation meetings shortly before the IETF, so we will hopefully have a lot of progress and thus issues to bring up at IETF. I wonder whether 3 or 4 hours might make more sense. I think we could find easy points for session breaks. From Josh.Howlett@ja.net Wed Jan 12 07:29:33 2011 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 EACB328C123 for ; Wed, 12 Jan 2011 07:29:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.677 X-Spam-Level: X-Spam-Status: No, score=-101.677 tagged_above=-999 required=5 tests=[AWL=-0.567, BAYES_05=-1.11, 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 3puj4e5UFRoq for ; Wed, 12 Jan 2011 07:29:33 -0800 (PST) Received: from har003676.ukerna.ac.uk (har003676.ukerna.ac.uk [194.82.140.75]) by core3.amsl.com (Postfix) with ESMTP id 1385A3A6841 for ; Wed, 12 Jan 2011 07:29:33 -0800 (PST) Received: from har003676.ukerna.ac.uk (localhost.localdomain [127.0.0.1]) by localhost (Email Security Appliance) with SMTP id 9CB174A6BA2_D2DC967B for ; Wed, 12 Jan 2011 15:31:51 +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 9331D4A6BA6_D2DC967F for ; Wed, 12 Jan 2011 15:31:51 +0000 (GMT) Received: from EXC001.atlas.ukerna.ac.uk ([193.62.83.37]) by EXC001 ([193.62.83.37]) with mapi; Wed, 12 Jan 2011 15:31:51 +0000 From: Josh Howlett To: "abfab@ietf.org" Thread-Topic: FYI: Project Moonshot meeting, 24-25 March, Prague Thread-Index: Acuybc97e9f77F4IQ5qWjw4ryf0sqg== Date: Wed, 12 Jan 2011 15:31:43 +0000 Message-ID: <55DC663C2F4F9F439F23543E0078E8B30579C0@EXC001> 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 Subject: [abfab] FYI: Project Moonshot meeting, 24-25 March, Prague 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, 12 Jan 2011 15:29:34 -0000 Project Moonshot, which is building an Abfab implementation, is planning to= have its second meeting on 24-25 March in Prague, immediately preceding IE= TF 80. We will be discussing our implementation on Thursday, and testing it= on Friday. There will not be any Abfab standardisation-related discussion, although we= will bring any issues that arise during our discussions to the Abfab WG me= eting where they are relevant. This is an open meeting. However, space is limited and so please let me kno= w if you would like to attend. Josh. JANET(UK) is a trading name of The JNT Association, a company limited by guarantee which is registered in England under No. 2881024=20 and whose Registered Office is at Lumen House, Library Avenue, Harwell Oxford, Didcot, Oxfordshire. OX11 0SG From leifj@sunet.se Thu Jan 13 00:01:41 2011 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 4A4D73A6ABE for ; Thu, 13 Jan 2011 00:01: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 bZDKmjk1Rl0i for ; Thu, 13 Jan 2011 00:01: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 0F4B33A6AB3 for ; Thu, 13 Jan 2011 00:01:39 -0800 (PST) Received: from [192.36.125.230] (dhcp.pilsnet.sunet.se [192.36.125.230]) (authenticated bits=0) by backup-server.nordu.net (8.14.3/8.14.3) with ESMTP id p0D83vSA015652 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 13 Jan 2011 09:04:00 +0100 (CET) Message-ID: <4D2EB1ED.9060007@sunet.se> Date: Thu, 13 Jan 2011 09:03:57 +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] We might want two sessions 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, 13 Jan 2011 08:01:41 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 01/12/2011 04:17 PM, Sam Hartman wrote: > > > I think we have a lot of things on the agenda next time: > > * Architecture doc > * I just sat in on a call and I believe there will be a proposed use > * case doc > * gss main spec > * Gss naming spec > * The AAA SAML doc > * Discussion of where our dependencies are > ** naming exts from kitten > ** channel binding from EMU Less urgent but still worth considering: - - diameter spec (we will probably have a candidate) - - presentation on the nfsv4/pnfs use case > > We didn't even get to the gss naming document last time, and we had more > SAML discussion than we really had time for. > > It's also fairly likely that we're going to have some implementation > meetings shortly before the IETF, so we will hopefully have a lot of > progress and thus issues to bring up at IETF. > > > I wonder whether 3 or 4 hours might make more sense. I think we could > find easy points for session breaks. We could try to go for 2 x 2 hours but I need to know that people will show up even if this means one of the sessions is on Friday! The yang group had good experience with having 2 sessions with the more generally accessible topics on the first "mid-week" session and a Friday session with topics that required more deep insight and active participation. How does that sound? Cheers Leif -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk0use0ACgkQ8Jx8FtbMZnchpQCfQdbLA1z8grT2bh0wjSRBDfBs D4cAmwQKUlvn7X52/mYTaqNtriN2vDMq =Htn9 -----END PGP SIGNATURE----- From hartmans@painless-security.com Thu Jan 13 07:09:36 2011 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 6B1EF3A67EC for ; Thu, 13 Jan 2011 07:09:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.292 X-Spam-Level: X-Spam-Status: No, score=-2.292 tagged_above=-999 required=5 tests=[AWL=-0.027, 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 37FeO6BQKvn1 for ; Thu, 13 Jan 2011 07:09:35 -0800 (PST) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by core3.amsl.com (Postfix) with ESMTP id BB2B13A67B4 for ; Thu, 13 Jan 2011 07:09: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 778D62016A; Thu, 13 Jan 2011 10:10:20 -0500 (EST) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 2DE80432C; Thu, 13 Jan 2011 10:11:50 -0500 (EST) From: Sam Hartman To: Leif Johansson References: <4D2EB1ED.9060007@sunet.se> Date: Thu, 13 Jan 2011 10:11:50 -0500 In-Reply-To: <4D2EB1ED.9060007@sunet.se> (Leif Johansson's message of "Thu, 13 Jan 2011 09:03:57 +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] We might want two sessions 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, 13 Jan 2011 15:09:36 -0000 I would not explicitly ask for a Friday session, but yes you might well get it. It is going to be a lot for people who fly in the week before for the project moonshot meeting. However, I'll certainly be there on Friday. From leifj@mnt.se Fri Jan 14 04:11:37 2011 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 8D2003A6C16 for ; Fri, 14 Jan 2011 04:11:37 -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 ap3I2LmY4a+G for ; Fri, 14 Jan 2011 04:11:36 -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 4F06B3A6BFF for ; Fri, 14 Jan 2011 04:11:35 -0800 (PST) Received: from [192.36.125.230] (dhcp.pilsnet.sunet.se [192.36.125.230]) (authenticated bits=0) by backup-server.nordu.net (8.14.3/8.14.3) with ESMTP id p0ECDvaV029072 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 14 Jan 2011 13:14:00 +0100 (CET) Message-ID: <4D303E05.4030700@mnt.se> Date: Fri, 14 Jan 2011 13:13:57 +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: <4D2EB1ED.9060007@sunet.se> In-Reply-To: X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [abfab] We might want two sessions 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, 14 Jan 2011 12:11:37 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 01/13/2011 04:11 PM, Sam Hartman wrote: > I would not explicitly ask for a Friday session, but yes you might well > get it. It is going to be a lot for people who fly in the week before > for the project moonshot meeting. However, I'll certainly be there on > Friday. Yeah you can't ask for session-times, only request conflict avoidance but I was thinking that we should _assume_ that a second session winds up on the Friday. MVH leifj -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk0wPgUACgkQ8Jx8FtbMZne93gCfd1GOZm7qSwIs31c49Hh80Igy bu8AoLyQpziVbuWfGVwQ68z0bsUhl6Zl =Gyq6 -----END PGP SIGNATURE----- From leifj@sunet.se Fri Jan 14 06:05:03 2011 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 66D2E28C0EA for ; Fri, 14 Jan 2011 06:05:03 -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 IpaDerxjkGIA for ; Fri, 14 Jan 2011 06:05:00 -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 29A9628C0FE for ; Fri, 14 Jan 2011 06:04:58 -0800 (PST) Received: from [192.36.125.230] (dhcp.pilsnet.sunet.se [192.36.125.230]) (authenticated bits=0) by backup-server.nordu.net (8.14.3/8.14.3) with ESMTP id p0EE7LL4025001 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 14 Jan 2011 15:07:23 +0100 (CET) Message-ID: <4D305899.7000506@sunet.se> Date: Fri, 14 Jan 2011 15:07:21 +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: <4D2EB1ED.9060007@sunet.se> <4D303E05.4030700@mnt.se> In-Reply-To: <4D303E05.4030700@mnt.se> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [abfab] We might want two sessions 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, 14 Jan 2011 14:05:03 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 01/14/2011 01:13 PM, Leif Johansson wrote: > On 01/13/2011 04:11 PM, Sam Hartman wrote: >> I would not explicitly ask for a Friday session, but yes you might well >> get it. It is going to be a lot for people who fly in the week before >> for the project moonshot meeting. However, I'll certainly be there on >> Friday. > > Yeah you can't ask for session-times, only request conflict avoidance > but I was thinking that we should _assume_ that a second session winds > up on the Friday. Since I've not heard any protests I've changed our request to 2 x 2h Cheers Leif -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk0wWJkACgkQ8Jx8FtbMZndBcACeMhgj9lYChjkDYrc5Ogz44KVX eVcAn2pcOC1DYDEeoVOC6DHgMu5l+S80 =7Tws -----END PGP SIGNATURE----- From klaas@cisco.com Fri Jan 14 06:23:34 2011 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 09D9B3A6C64 for ; Fri, 14 Jan 2011 06:23:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.513 X-Spam-Level: X-Spam-Status: No, score=-10.513 tagged_above=-999 required=5 tests=[AWL=0.086, BAYES_00=-2.599, 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 mwUzzi6cbx96 for ; Fri, 14 Jan 2011 06:23:33 -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 ACD3C3A6B26 for ; Fri, 14 Jan 2011 06:23:32 -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: AroFAD/sL02Q/khMgWdsb2JhbACWQI4WFQEBFiIkonGYR4VPBIsW Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-1.cisco.com with ESMTP; 14 Jan 2011 14:25:53 +0000 Received: from macmini.wierenga.net (ams-kwiereng-8712.cisco.com [10.55.220.243]) by ams-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p0EEPqgM026005 for ; Fri, 14 Jan 2011 14:25:52 GMT Message-ID: <4D305CF0.2000207@cisco.com> Date: Fri, 14 Jan 2011 15:25:52 +0100 From: Klaas Wierenga User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-GB; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: abfab@ietf.org References: <4D2EB1ED.9060007@sunet.se> <4D303E05.4030700@mnt.se> <4D305899.7000506@sunet.se> In-Reply-To: <4D305899.7000506@sunet.se> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [abfab] We might want two sessions 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, 14 Jan 2011 14:23:34 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 1/14/11 3:07 PM, Leif Johansson wrote: > On 01/14/2011 01:13 PM, Leif Johansson wrote: >> On 01/13/2011 04:11 PM, Sam Hartman wrote: >>> I would not explicitly ask for a Friday session, but yes you might well >>> get it. It is going to be a lot for people who fly in the week before >>> for the project moonshot meeting. However, I'll certainly be there on >>> Friday. > >> Yeah you can't ask for session-times, only request conflict avoidance >> but I was thinking that we should _assume_ that a second session winds >> up on the Friday. > > Since I've not heard any protests I've changed our request to 2 x 2h and in case we get a Friday slot, those that don't show up have to buy cookies for the next meeting ;-) Klaas -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.14 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk0wXPAACgkQH2Wy/p4XeFKXqACfVau/eXThbPFxGw99SvB+Q4Q+ dNcAoKQdYX5FMERLDRl2RhQ7t1GjSBvM =vA9J -----END PGP SIGNATURE----- From leifj@sunet.se Fri Jan 14 06:27:57 2011 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 621E128C0F5 for ; Fri, 14 Jan 2011 06:27:57 -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 u1U-79Um1Tnh for ; Fri, 14 Jan 2011 06:27:55 -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 9B93F3A6B26 for ; Fri, 14 Jan 2011 06:27:55 -0800 (PST) Received: from [192.36.125.230] (dhcp.pilsnet.sunet.se [192.36.125.230]) (authenticated bits=0) by backup-server.nordu.net (8.14.3/8.14.3) with ESMTP id p0EEUHiX009386 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 14 Jan 2011 15:30:20 +0100 (CET) Message-ID: <4D305DF9.5020704@sunet.se> Date: Fri, 14 Jan 2011 15:30: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: <4D2EB1ED.9060007@sunet.se> <4D303E05.4030700@mnt.se> <4D305899.7000506@sunet.se> <4D305CF0.2000207@cisco.com> In-Reply-To: <4D305CF0.2000207@cisco.com> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [abfab] We might want two sessions 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, 14 Jan 2011 14:27:57 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 01/14/2011 03:25 PM, Klaas Wierenga wrote: > On 1/14/11 3:07 PM, Leif Johansson wrote: >> On 01/14/2011 01:13 PM, Leif Johansson wrote: >>> On 01/13/2011 04:11 PM, Sam Hartman wrote: >>>> I would not explicitly ask for a Friday session, but yes you might well >>>> get it. It is going to be a lot for people who fly in the week before >>>> for the project moonshot meeting. However, I'll certainly be there on >>>> Friday. > >>> Yeah you can't ask for session-times, only request conflict avoidance >>> but I was thinking that we should _assume_ that a second session winds >>> up on the Friday. > >> Since I've not heard any protests I've changed our request to 2 x 2h > > and in case we get a Friday slot, those that don't show up have to buy > cookies for the next meeting ;-) and we will make sure ekr is there to eat them! -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk0wXfkACgkQ8Jx8FtbMZndxRwCff9frpfvRq+rETSkyd/PTLw5o 3iUAn2KUWXIzWTBKvMybmE4d8mTTUPjy =wlZN -----END PGP SIGNATURE----- From Josh.Howlett@ja.net Fri Jan 14 06:49:24 2011 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 C7B883A6B89 for ; Fri, 14 Jan 2011 06:49:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.386 X-Spam-Level: X-Spam-Status: No, score=-102.386 tagged_above=-999 required=5 tests=[AWL=0.213, 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 GVnndrPWDffa for ; Fri, 14 Jan 2011 06:49:24 -0800 (PST) Received: from har003676.ukerna.ac.uk (har003676.ukerna.ac.uk [194.82.140.75]) by core3.amsl.com (Postfix) with ESMTP id EA0E23A6B7B for ; Fri, 14 Jan 2011 06:49:23 -0800 (PST) Received: from har003676.ukerna.ac.uk (localhost.localdomain [127.0.0.1]) by localhost (Email Security Appliance) with SMTP id 801B44A6BAE_D306304B for ; Fri, 14 Jan 2011 14:51:48 +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 70CF74A6B76_D306304F for ; Fri, 14 Jan 2011 14:51:48 +0000 (GMT) Received: from EXC001.atlas.ukerna.ac.uk ([193.62.83.37]) by EXC001 ([193.62.83.37]) with mapi; Fri, 14 Jan 2011 14:51:48 +0000 From: Josh Howlett To: "abfab@ietf.org" Thread-Topic: Proposed changes to draft-ieft-abfab-aaa-saml Thread-Index: Acuz+pDcD6cZVuZbTB2nOWDtn9TYJw== Date: Fri, 14 Jan 2011 14:51:46 +0000 Message-ID: <55DC663C2F4F9F439F23543E0078E8B305A4C9@EXC001> 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 Subject: [abfab] Proposed changes to draft-ieft-abfab-aaa-saml 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, 14 Jan 2011 14:49:24 -0000 Discussions at IETF79 and on this list have indicated some agreement around= the following: - that the attribute should be scoped explicitly for SAML Request/Response= messages, rather than SAML constructs in general. I'm not unhappy about th= is, as it makes the attribute's internal format (even) simpler and avoids t= he need for an IANA registry of message types. I've also been unable to fin= d any compelling reason why a RADIUS server might want care about the type = of SAML construct contained within the attribute, particularly if it's eith= er going to be a Request or Response message. - the document needs to discuss how the attribute can be used with RADIUS = transport for exchanges that are not necessarily associated with an EAP aut= hentication exchange; for example, to support SAML attribute requests at so= me arbitrary time after authentication; or attribute requests to an attribu= te authority that is not the Identity Provider. (This may turn the document= into more of a 'binding' specification (in SAML sense), than simply an att= ribute specification, but I'm not sure if that matters or not). Comments welcome. I hope to crank out an 01 sometime next week. Josh. JANET(UK) is a trading name of The JNT Association, a company limited by guarantee which is registered in England under No. 2881024=20 and whose Registered Office is at Lumen House, Library Avenue, Harwell Oxford, Didcot, Oxfordshire. OX11 0SG From Josh.Howlett@ja.net Fri Jan 14 06:58:13 2011 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 1DDEF3A6C64 for ; Fri, 14 Jan 2011 06:58:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.399 X-Spam-Level: X-Spam-Status: No, score=-102.399 tagged_above=-999 required=5 tests=[AWL=0.200, 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 Rp-XSpLMzccf for ; Fri, 14 Jan 2011 06:58:12 -0800 (PST) Received: from har003676.ukerna.ac.uk (har003676.ukerna.ac.uk [194.82.140.75]) by core3.amsl.com (Postfix) with ESMTP id 332843A6C6C for ; Fri, 14 Jan 2011 06:58:11 -0800 (PST) Received: from har003676.ukerna.ac.uk (localhost.localdomain [127.0.0.1]) by localhost (Email Security Appliance) with SMTP id 3E1604A6BA3_D306515B for ; Fri, 14 Jan 2011 15:00:37 +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 33F784A6B70_D306515F for ; Fri, 14 Jan 2011 15:00:37 +0000 (GMT) Received: from EXC001.atlas.ukerna.ac.uk ([193.62.83.37]) by EXC001 ([193.62.83.37]) with mapi; Fri, 14 Jan 2011 15:00:37 +0000 From: Josh Howlett To: "abfab@ietf.org" Thread-Topic: Proposed changes to draft-ieft-abfab-aaa-saml Thread-Index: Acuz+pDcD6cZVuZbTB2nOWDtn9TYJwAARdzA Date: Fri, 14 Jan 2011 15:00:33 +0000 Message-ID: <55DC663C2F4F9F439F23543E0078E8B305A51C@EXC001> References: <55DC663C2F4F9F439F23543E0078E8B305A4C9@EXC001> In-Reply-To: <55DC663C2F4F9F439F23543E0078E8B305A4C9@EXC001> 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 Subject: Re: [abfab] Proposed changes to draft-ieft-abfab-aaa-saml 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, 14 Jan 2011 14:58:13 -0000 > Discussions at IETF79 and on this list have indicated some agreement > around the following: I forgot to mention that we were also going to constrain the attribute for = RDAIUS-based transport, and have a second document dealing with Diameter. Josh. JANET(UK) is a trading name of The JNT Association, a company limited by guarantee which is registered in England under No. 2881024=20 and whose Registered Office is at Lumen House, Library Avenue, Harwell Oxford, Didcot, Oxfordshire. OX11 0SG From hartmans@painless-security.com Fri Jan 14 07:13:28 2011 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 CB2D528C0EB for ; Fri, 14 Jan 2011 07:13:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.291 X-Spam-Level: X-Spam-Status: No, score=-2.291 tagged_above=-999 required=5 tests=[AWL=-0.026, 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 mDFJYEA-z-7D for ; Fri, 14 Jan 2011 07:13:28 -0800 (PST) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by core3.amsl.com (Postfix) with ESMTP id 0C49328C0EA for ; Fri, 14 Jan 2011 07:13:27 -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 CD8852028C; Fri, 14 Jan 2011 10:14:10 -0500 (EST) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id CDECD432C; Fri, 14 Jan 2011 10:15:39 -0500 (EST) From: Sam Hartman To: Josh Howlett References: <55DC663C2F4F9F439F23543E0078E8B305A4C9@EXC001> Date: Fri, 14 Jan 2011 10:15:39 -0500 In-Reply-To: <55DC663C2F4F9F439F23543E0078E8B305A4C9@EXC001> (Josh Howlett's message of "Fri, 14 Jan 2011 14:51:46 +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] Proposed changes to draft-ieft-abfab-aaa-saml 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, 14 Jan 2011 15:13:29 -0000 >>>>> "Josh" == Josh Howlett writes: Josh> - the document needs to discuss how the attribute can be used Josh> with RADIUS transport for exchanges that are not necessarily Josh> associated with an EAP authentication exchange; for example, Josh> to support SAML attribute requests at some arbitrary time Josh> after authentication; Sounds good Josh> or attribute requests to an attribute Josh> authority that is not the Identity Provider. I'm nervous about this for the trust model issues I brought up. I could see using the same attribute in the cases where the trust model is going to be the same. However I definitely think we want a different attribute if we want different processing semantics in the RP. One particularly thorny issue will be what the IDP should do with a request for an attribute from a different provider that it could satisfy but not under the trust model the RP was hoping for. Josh> (This may turn Josh> the document into more of a 'binding' specification (in SAML Josh> sense), than simply an attribute specification, but I'm not Josh> sure if that matters or not). I think ending up with a binding is very good. Josh> Comments welcome. I hope to crank out an 01 sometime next Josh> week. Josh> Josh. Josh> JANET(UK) is a trading name of The JNT Association, a company Josh> limited by guarantee which is registered in England under Josh> No. 2881024 and whose Registered Office is at Lumen House, Josh> Library Avenue, Harwell Oxford, Didcot, Oxfordshire. OX11 0SG Josh> _______________________________________________ abfab mailing Josh> list abfab@ietf.org Josh> https://www.ietf.org/mailman/listinfo/abfab From Josh.Howlett@ja.net Fri Jan 14 08:25:21 2011 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 C91213A6BB8 for ; Fri, 14 Jan 2011 08:25:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.41 X-Spam-Level: X-Spam-Status: No, score=-102.41 tagged_above=-999 required=5 tests=[AWL=0.189, 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 WEMIVLW5zplp for ; Fri, 14 Jan 2011 08:25:20 -0800 (PST) Received: from har003676.ukerna.ac.uk (har003676.ukerna.ac.uk [194.82.140.75]) by core3.amsl.com (Postfix) with ESMTP id 831543A68D0 for ; Fri, 14 Jan 2011 08:25:20 -0800 (PST) Received: from har003676.ukerna.ac.uk (localhost.localdomain [127.0.0.1]) by localhost (Email Security Appliance) with SMTP id 440054A6BAE_D307981B; Fri, 14 Jan 2011 16:27:45 +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 2F1EA4A6BAD_D307980F; Fri, 14 Jan 2011 16:27:44 +0000 (GMT) Received: from EXC001.atlas.ukerna.ac.uk ([193.62.83.37]) by EXC001 ([193.62.83.37]) with mapi; Fri, 14 Jan 2011 16:27:44 +0000 From: Josh Howlett To: Sam Hartman Thread-Topic: [abfab] Proposed changes to draft-ieft-abfab-aaa-saml Thread-Index: AQHLs/3yIyHwctNWOUmE/oDJ1svZrpPQpe6g Date: Fri, 14 Jan 2011 16:27:42 +0000 Message-ID: <55DC663C2F4F9F439F23543E0078E8B305A7B8@EXC001> References: <55DC663C2F4F9F439F23543E0078E8B305A4C9@EXC001> 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] Proposed changes to draft-ieft-abfab-aaa-saml 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, 14 Jan 2011 16:25:21 -0000 > Josh> or attribute requests to an attribute > Josh> authority that is not the Identity Provider. >=20 > I'm nervous about this for the trust model issues I brought up. > I could see using the same attribute in the cases where the trust model > is going to be the same. > However I definitely think we want a different attribute if we want > different processing semantics in the RP. I don't follow this. Why can't we put these semantics to the SAML layer? > One particularly thorny issue will be what the IDP should do with a > request for an attribute from a different provider that it could > satisfy > but not under the trust model the RP was hoping for. I agree its thorny, but is this actually a use-case that we care about? I w= ould prefer to punt it to the business layer. =20 Josh. JANET(UK) is a trading name of The JNT Association, a company limited by guarantee which is registered in England under No. 2881024=20 and whose Registered Office is at Lumen House, Library Avenue, Harwell Oxford, Didcot, Oxfordshire. OX11 0SG From hartmans@painless-security.com Fri Jan 14 08:30:34 2011 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 4E57E3A6BCE for ; Fri, 14 Jan 2011 08:30:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.29 X-Spam-Level: X-Spam-Status: No, score=-2.29 tagged_above=-999 required=5 tests=[AWL=-0.025, 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 6EH4EYhPoLBB for ; Fri, 14 Jan 2011 08:30:33 -0800 (PST) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by core3.amsl.com (Postfix) with ESMTP id 78ECE3A6B9A for ; Fri, 14 Jan 2011 08:30:33 -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 9D3E02028C; Fri, 14 Jan 2011 11:31:18 -0500 (EST) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 69FE9432C; Fri, 14 Jan 2011 11:32:48 -0500 (EST) From: Sam Hartman To: Josh Howlett References: <55DC663C2F4F9F439F23543E0078E8B305A4C9@EXC001> <55DC663C2F4F9F439F23543E0078E8B305A7B8@EXC001> Date: Fri, 14 Jan 2011 11:32:48 -0500 In-Reply-To: <55DC663C2F4F9F439F23543E0078E8B305A7B8@EXC001> (Josh Howlett's message of "Fri, 14 Jan 2011 16:27:42 +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] Proposed changes to draft-ieft-abfab-aaa-saml 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, 14 Jan 2011 16:30:34 -0000 >>>>> "Josh" == Josh Howlett writes: Josh> or attribute requests to an attribute authority that is not Josh> the Identity Provider. >> >> I'm nervous about this for the trust model issues I brought up. >> I could see using the same attribute in the cases where the trust >> model is going to be the same. However I definitely think we >> want a different attribute if we want different processing >> semantics in the RP. Josh> I don't follow this. Why can't we put these semantics to the Josh> SAML layer? I think that both the RP and intermediates need to understand what trust model the IDP is using--at least to the extent that they need to understand what claims about the attributes the IDP is making. See the three trust models in my last mail. I want this document to either have a single trust model or to explain how an RP and intermediate determines the trust model. I guess that could be SAML layer if there is a good mechanism for that. >> One particularly thorny issue will be what the IDP should do with >> a request for an attribute from a different provider that it >> could satisfy but not under the trust model the RP was hoping >> for. Josh> I agree its thorny, but is this actually a use-case that we Josh> care about? I would prefer to punt it to the business layer. Josh> Josh. Explain what it would mean to punt on this; I'm confused as to how we could do that if multiple trust models are in play. From cantor.2@osu.edu Fri Jan 14 08:54:58 2011 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 289613A6BBA for ; Fri, 14 Jan 2011 08:54:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.566 X-Spam-Level: X-Spam-Status: No, score=-3.566 tagged_above=-999 required=5 tests=[AWL=0.033, 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 Wxd5mokOUDIQ for ; Fri, 14 Jan 2011 08:54:57 -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 1271D3A6BA4 for ; Fri, 14 Jan 2011 08:54:56 -0800 (PST) Received: from CIO-KRC-HT02.osuad.osu.edu ([164.107.81.41]) by defang14.it.ohio-state.edu (8.13.7/8.13.1) with ESMTP id p0EGvMY5031260; Fri, 14 Jan 2011 11:57:22 -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; Fri, 14 Jan 2011 11:54:07 -0500 From: "Cantor, Scott E." To: Sam Hartman , Josh Howlett Thread-Topic: [abfab] Proposed changes to draft-ieft-abfab-aaa-saml Thread-Index: AQHLs/2Cbbv3dYPD7k+t0sTuHDW2HJPQ+8UAgAABbQD//7IrIA== Date: Fri, 14 Jan 2011 16:57:24 +0000 Message-ID: <7EE86E89365CA94F8E7B8251F9260710035160@CIO-KRC-D1MBX01.osuad.osu.edu> References: <55DC663C2F4F9F439F23543E0078E8B305A4C9@EXC001> <55DC663C2F4F9F439F23543E0078E8B305A7B8@EXC001> 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-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.128 Cc: "abfab@ietf.org" Subject: Re: [abfab] Proposed changes to draft-ieft-abfab-aaa-saml 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, 14 Jan 2011 16:54:58 -0000 > I want this document to either have a single trust model or to explain > how an RP and intermediate determines the trust model. > I guess that could be SAML layer if there is a good mechanism for that. There are no standards I'm aware of in any domain for addressing attribute-= related trust distinctions. That's left to applications at the moment. > Explain what it would mean to punt on this; I'm confused as to how we > could do that if multiple trust models are in play. It's assumed that deployers are making decisions about how to use attribute= s based on their OOB information about where they come from and what's been= guaranteed about them. That extends to using them as input to other attrib= ute sources. The filtering process, for example, imposes whatever rules might exist abou= t who can assert particular attributes based on the assumptions the applica= tion wants to make about them. -- Scott From hartmans@painless-security.com Fri Jan 14 09:43:35 2011 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 E84B63A6BBE for ; Fri, 14 Jan 2011 09:43:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.289 X-Spam-Level: X-Spam-Status: No, score=-2.289 tagged_above=-999 required=5 tests=[AWL=-0.024, 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 EdtqDdRZ2b1a for ; Fri, 14 Jan 2011 09:43:35 -0800 (PST) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by core3.amsl.com (Postfix) with ESMTP id 3AE693A6B3D for ; Fri, 14 Jan 2011 09:43: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 0994520220; Fri, 14 Jan 2011 12:44:22 -0500 (EST) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id B855E432C; Fri, 14 Jan 2011 12:45:50 -0500 (EST) From: Sam Hartman To: "Cantor\, Scott E." References: <55DC663C2F4F9F439F23543E0078E8B305A4C9@EXC001> <55DC663C2F4F9F439F23543E0078E8B305A7B8@EXC001> <7EE86E89365CA94F8E7B8251F9260710035160@CIO-KRC-D1MBX01.osuad.osu.edu> Date: Fri, 14 Jan 2011 12:45:50 -0500 In-Reply-To: <7EE86E89365CA94F8E7B8251F9260710035160@CIO-KRC-D1MBX01.osuad.osu.edu> (Scott E. Cantor's message of "Fri, 14 Jan 2011 16:57:24 +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: Josh Howlett , "abfab@ietf.org" Subject: Re: [abfab] Proposed changes to draft-ieft-abfab-aaa-saml 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, 14 Jan 2011 17:43:36 -0000 >>>>> "Cantor," == Cantor, Scott E writes: >> Explain what it would mean to punt on this; I'm confused as to >> how we could do that if multiple trust models are in play. Cantor,> It's assumed that deployers are making decisions about how Cantor,> to use attributes based on their OOB information about Cantor,> where they come from and what's been guaranteed about Cantor,> them. That extends to using them as input to other Cantor,> attribute sources. Right. I don't think we can do this and build an interoperable secure standard. I think that the question about whether an RP that trusts the IDP should rely on the attribute or not needs to be answered in-band. --Sam From cantor.2@osu.edu Fri Jan 14 10:38:53 2011 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 C2C193A6BAB for ; Fri, 14 Jan 2011 10:38:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.568 X-Spam-Level: X-Spam-Status: No, score=-3.568 tagged_above=-999 required=5 tests=[AWL=0.031, 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 jnWwzduwmEVY for ; Fri, 14 Jan 2011 10:38:53 -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 047B93A6803 for ; Fri, 14 Jan 2011 10:38:50 -0800 (PST) Received: from CIO-TNC-HT06.osuad.osu.edu ([164.107.81.172]) by defang16.it.ohio-state.edu (8.13.7/8.13.1) with ESMTP id p0EIfE1v031785; Fri, 14 Jan 2011 13:41:15 -0500 Received: from CIO-KRC-D1MBX01.osuad.osu.edu ([fe80::450b:35e6:80f4:f3e0]) by CIO-TNC-HT06.osuad.osu.edu ([fe80::8c6c:9f26:5aa2:4458%25]) with mapi; Fri, 14 Jan 2011 13:37:59 -0500 From: "Cantor, Scott E." To: Sam Hartman Thread-Topic: [abfab] Proposed changes to draft-ieft-abfab-aaa-saml Thread-Index: AQHLs/2Cbbv3dYPD7k+t0sTuHDW2HJPQ+8UAgAABbQD//7IrIIAAYj0A//+7UzA= Date: Fri, 14 Jan 2011 18:41:16 +0000 Message-ID: <7EE86E89365CA94F8E7B8251F92607100351DE@CIO-KRC-D1MBX01.osuad.osu.edu> References: <55DC663C2F4F9F439F23543E0078E8B305A4C9@EXC001> <55DC663C2F4F9F439F23543E0078E8B305A7B8@EXC001> <7EE86E89365CA94F8E7B8251F9260710035160@CIO-KRC-D1MBX01.osuad.osu.edu> 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-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CanIt-Geo: ip=164.107.81.172; 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 Cc: Josh Howlett , "abfab@ietf.org" Subject: Re: [abfab] Proposed changes to draft-ieft-abfab-aaa-saml 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, 14 Jan 2011 18:38:53 -0000 > Right. I don't think we can do this and build an interoperable secure > standard. I think that the question about whether an RP that trusts the > IDP should rely on the attribute or not needs to be answered in-band. But by that measure, LDAP isn't an interoperable secure standard either. =20 -- Scott From hartmans@painless-security.com Fri Jan 14 12:10:44 2011 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 A5FE43A6BC6 for ; Fri, 14 Jan 2011 12:10:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.288 X-Spam-Level: X-Spam-Status: No, score=-2.288 tagged_above=-999 required=5 tests=[AWL=-0.023, 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 4LxfSvoUl5lm for ; Fri, 14 Jan 2011 12:10:41 -0800 (PST) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by core3.amsl.com (Postfix) with ESMTP id 6680B3A6BC5 for ; Fri, 14 Jan 2011 12:10:41 -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 EF99620246; Fri, 14 Jan 2011 15:11:27 -0500 (EST) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id D830A432C; Fri, 14 Jan 2011 15:12:55 -0500 (EST) From: Sam Hartman To: "Cantor\, Scott E." References: <55DC663C2F4F9F439F23543E0078E8B305A4C9@EXC001> <55DC663C2F4F9F439F23543E0078E8B305A7B8@EXC001> <7EE86E89365CA94F8E7B8251F9260710035160@CIO-KRC-D1MBX01.osuad.osu.edu> <7EE86E89365CA94F8E7B8251F92607100351DE@CIO-KRC-D1MBX01.osuad.osu.edu> Date: Fri, 14 Jan 2011 15:12:55 -0500 In-Reply-To: <7EE86E89365CA94F8E7B8251F92607100351DE@CIO-KRC-D1MBX01.osuad.osu.edu> (Scott E. Cantor's message of "Fri, 14 Jan 2011 18:41:16 +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: Josh Howlett , "abfab@ietf.org" Subject: Re: [abfab] Proposed changes to draft-ieft-abfab-aaa-saml 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, 14 Jan 2011 20:10:44 -0000 >>>>> "Cantor," == Cantor, Scott E writes: >> Right. I don't think we can do this and build an interoperable >> secure standard. I think that the question about whether an RP >> that trusts the IDP should rely on the attribute or not needs to >> be answered in-band. Cantor,> But by that measure, LDAP isn't an interoperable secure Cantor,> standard either. I'm not sure I see what you're getting at. I'd certainly expect a schema or derictory organization to indicate if information was being stored in the directory that the directory itself was not vouching for. Actually we have been somewhat explicit about some of this. For example, in the case of NSS (ldap nis etc) we've at least implicitly said that a client can trust account information from a directory. However in the case of PKI-related attributes we've not made this trust assumption. If I find a certificate in a directory I'm still expected to perform cert validation according to the PKIX specs. We're explicitly saying with draft-ietf-saml-aaa that a RP SHOULD trust the information and not perform validation for the authentication response. We need to do that in order to get interoperability. Once we've done that, we need to make it clear when that doesn't hold. --Sam From cantor.2@osu.edu Fri Jan 14 12:24:28 2011 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 353413A6BD9 for ; Fri, 14 Jan 2011 12:24:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.57 X-Spam-Level: X-Spam-Status: No, score=-3.57 tagged_above=-999 required=5 tests=[AWL=0.029, 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 UbOoWXwqfn2N for ; Fri, 14 Jan 2011 12:24:27 -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 2160B3A6BCE for ; Fri, 14 Jan 2011 12:24:24 -0800 (PST) Received: from CIO-KRC-HT02.osuad.osu.edu ([164.107.81.41]) by defang14.it.ohio-state.edu (8.13.7/8.13.1) with ESMTP id p0EKQnGf024598; Fri, 14 Jan 2011 15:26:50 -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; Fri, 14 Jan 2011 15:23:34 -0500 From: "Cantor, Scott E." To: Sam Hartman Thread-Topic: [abfab] Proposed changes to draft-ieft-abfab-aaa-saml Thread-Index: AQHLs/2Cbbv3dYPD7k+t0sTuHDW2HJPQ+8UAgAABbQD//7IrIIAAYj0A//+7UzCAAG3FgP//rQ0w Date: Fri, 14 Jan 2011 20:26:51 +0000 Message-ID: <7EE86E89365CA94F8E7B8251F9260710035299@CIO-KRC-D1MBX01.osuad.osu.edu> References: <55DC663C2F4F9F439F23543E0078E8B305A4C9@EXC001> <55DC663C2F4F9F439F23543E0078E8B305A7B8@EXC001> <7EE86E89365CA94F8E7B8251F9260710035160@CIO-KRC-D1MBX01.osuad.osu.edu> <7EE86E89365CA94F8E7B8251F92607100351DE@CIO-KRC-D1MBX01.osuad.osu.edu> 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-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.128 Cc: Josh Howlett , "abfab@ietf.org" Subject: Re: [abfab] Proposed changes to draft-ieft-abfab-aaa-saml 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, 14 Jan 2011 20:24:28 -0000 > I'd certainly expect a schema or derictory organization to indicate if > information was being stored in the directory that the directory > itself was not vouching for. How would that indication be done? That doesn't match the reality. Many directory attributes contain a lot of = ambiguity about who is actually in control of the values. This doesn't beco= me in issue because you switch the encoding from ASN.1 to XML. > Actually we have been somewhat explicit about some of this. > For example, in the case of NSS (ldap nis etc) we've at least implicitly > said that a client can trust account information from a directory. That's an application choice, then, I guess by assuming away the possibilit= y of referrals and multiple domains of authority. Federated applications ca= n't ignore these issues, though, and currently they don't get this for free= from the infrastructure. If you want to go there, this all gets much harde= r. > However in the case of PKI-related attributes we've not made this trust > assumption. If I find a certificate in a directory I'm still expected > to perform cert validation according to the PKIX specs. Validating the certificate often results in an implicit acceptance of the i= nformation in it as being vouched for by the issuer, though. That's no diff= erent than authenticating the LDAP server or the IdP. But it isn't really e= xplicit in the standards, any more than it is with LDAP or SAML. In PKI, it= 's the CPS and what not that are supposed to address it (and that's not mac= hine-level). > We're explicitly saying with draft-ietf-saml-aaa that a RP SHOULD trust > the information and not perform validation for the authentication > response. We need to do that in order to get interoperability. Once > we've done that, we need to make it clear when that doesn't hold. I think you're talking about two different kinds of trust here. The SHOULD = in the draft AFAIK is referring to the technical trust that it was duly iss= ued by the issuer and hasn't been tampered with. It wasn't AFAIK meant to say anything about the "truth" of the contents. One point that does come up in SAML is that you can have conditions that li= mit the validity. I'm not sure if that aspect of validation has been assume= d away or not, but it's not critical to this particular thread right now. -- Scott From cantor.2@osu.edu Fri Jan 14 12:33:34 2011 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 F02893A6C66 for ; Fri, 14 Jan 2011 12:33:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.571 X-Spam-Level: X-Spam-Status: No, score=-3.571 tagged_above=-999 required=5 tests=[AWL=0.028, 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 V9iv3RtM19N4 for ; Fri, 14 Jan 2011 12:33:33 -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 13D803A6C18 for ; Fri, 14 Jan 2011 12:33:32 -0800 (PST) Received: from CIO-KRC-HT01.osuad.osu.edu ([164.107.81.38]) by defang8.it.ohio-state.edu (8.13.7/8.13.1) with ESMTP id p0EKZwaQ002528; Fri, 14 Jan 2011 15:35:58 -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; Fri, 14 Jan 2011 15:32:43 -0500 From: "Cantor, Scott E." To: Sam Hartman Thread-Topic: [abfab] Proposed changes to draft-ieft-abfab-aaa-saml Thread-Index: AQHLs/2Cbbv3dYPD7k+t0sTuHDW2HJPQ+8UAgAABbQD//7IrIIAAYj0A//+7UzCAAG3FgP//rQ0wAAB5vXA= Date: Fri, 14 Jan 2011 20:36:00 +0000 Message-ID: <7EE86E89365CA94F8E7B8251F92607100352B9@CIO-KRC-D1MBX01.osuad.osu.edu> References: <55DC663C2F4F9F439F23543E0078E8B305A4C9@EXC001> <55DC663C2F4F9F439F23543E0078E8B305A7B8@EXC001> <7EE86E89365CA94F8E7B8251F9260710035160@CIO-KRC-D1MBX01.osuad.osu.edu> <7EE86E89365CA94F8E7B8251F92607100351DE@CIO-KRC-D1MBX01.osuad.osu.edu> <7EE86E89365CA94F8E7B8251F9260710035299@CIO-KRC-D1MBX01.osuad.osu.edu> In-Reply-To: <7EE86E89365CA94F8E7B8251F9260710035299@CIO-KRC-D1MBX01.osuad.osu.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-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.89 Cc: Josh Howlett , "abfab@ietf.org" Subject: Re: [abfab] Proposed changes to draft-ieft-abfab-aaa-saml 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, 14 Jan 2011 20:33:34 -0000 BTW, I don't want to make it sound like the standard attitude in an SP is "= I have no idea if the IdP is actually right about this information". Obviou= sly that's nonsensical. Just the opposite, people writing apps assume that = if the IdP is "trusted", it's trusted to say what it's saying, and you (hop= efully) have filters at your disposal to implement exceptions to that. Impl= ementations without such filtering support obviously are leaving that probl= em to the app. -- Scott From hartmans@painless-security.com Fri Jan 14 12:45:29 2011 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 6A3733A6C85 for ; Fri, 14 Jan 2011 12:45:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.287 X-Spam-Level: X-Spam-Status: No, score=-2.287 tagged_above=-999 required=5 tests=[AWL=-0.022, 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 xtEk5Lln-BIY for ; Fri, 14 Jan 2011 12:45:28 -0800 (PST) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by core3.amsl.com (Postfix) with ESMTP id 9D5803A6C73 for ; Fri, 14 Jan 2011 12:45:28 -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 270CC2028C; Fri, 14 Jan 2011 15:46:16 -0500 (EST) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 9C8F4432C; Fri, 14 Jan 2011 15:47:44 -0500 (EST) From: Sam Hartman To: "Cantor\, Scott E." References: <55DC663C2F4F9F439F23543E0078E8B305A4C9@EXC001> <55DC663C2F4F9F439F23543E0078E8B305A7B8@EXC001> <7EE86E89365CA94F8E7B8251F9260710035160@CIO-KRC-D1MBX01.osuad.osu.edu> <7EE86E89365CA94F8E7B8251F92607100351DE@CIO-KRC-D1MBX01.osuad.osu.edu> <7EE86E89365CA94F8E7B8251F9260710035299@CIO-KRC-D1MBX01.osuad.osu.edu> <7EE86E89365CA94F8E7B8251F92607100352B9@CIO-KRC-D1MBX01.osuad.osu.edu> Date: Fri, 14 Jan 2011 15:47:44 -0500 In-Reply-To: <7EE86E89365CA94F8E7B8251F92607100352B9@CIO-KRC-D1MBX01.osuad.osu.edu> (Scott E. Cantor's message of "Fri, 14 Jan 2011 20:36:00 +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: Josh Howlett , "abfab@ietf.org" Subject: Re: [abfab] Proposed changes to draft-ieft-abfab-aaa-saml 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, 14 Jan 2011 20:45:29 -0000 Let me try and be explicit about what I'm wanting. We're saying that when you receive a SAML authentication response from this AAA attribute you SHOULD NOT call a saml validation routine. You MUST still decide what statements you will allow the IDP to make, but AAA is handling the technical trust. I pointed to a couple of trust model earlier in the week. They effect two decisions the SP needs to make: 1) does it call SAML validation and if so, what does it do with a failure result 2) When evaluating whether the issuer is permitted to make the statement being claimed, does it use its rules for the IDP or for the actual issuer. I.E. does it assume that the IDP has vouched for the statement or simply passed it along. These are both technical decisions that affect interoperability and security. My claim is that to produce a technical specification that meets the requirements of RFC 2026 without known technical omissions we need to tell implementations what to do in these cases. I agree with you that various levels of ambiguity have been used with regard to these sorts of issues in other standards, and we have not been perfect. However I do think we have considered these sorts of issues. Often, the answer we've given is "that decision belongs at the next layer." I don't think we can do that here, although I'd be interested in evaluating a proposal to do so if someone made one. I would not support a proposal that required per-IDP configuration. --Sam From cantor.2@osu.edu Fri Jan 14 12:58:27 2011 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 089443A6C7A for ; Fri, 14 Jan 2011 12:58:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.573 X-Spam-Level: X-Spam-Status: No, score=-3.573 tagged_above=-999 required=5 tests=[AWL=0.026, 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 ECc6PYitIOVk for ; Fri, 14 Jan 2011 12:58:26 -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 EA6BC3A6C6B for ; Fri, 14 Jan 2011 12:58:25 -0800 (PST) Received: from CIO-KRC-HT01.osuad.osu.edu ([164.107.81.38]) by defang11.it.ohio-state.edu (8.13.7/8.13.1) with ESMTP id p0EL0oCt031282; Fri, 14 Jan 2011 16:00:51 -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; Fri, 14 Jan 2011 15:57:35 -0500 From: "Cantor, Scott E." To: Sam Hartman Thread-Topic: [abfab] Proposed changes to draft-ieft-abfab-aaa-saml Thread-Index: AQHLs/2Cbbv3dYPD7k+t0sTuHDW2HJPQ+8UAgAABbQD//7IrIIAAYj0A//+7UzCAAG3FgP//rQ0wAAB5vXAACxv3AAAKYffg Date: Fri, 14 Jan 2011 21:00:52 +0000 Message-ID: <7EE86E89365CA94F8E7B8251F926071003532C@CIO-KRC-D1MBX01.osuad.osu.edu> References: <55DC663C2F4F9F439F23543E0078E8B305A4C9@EXC001> <55DC663C2F4F9F439F23543E0078E8B305A7B8@EXC001> <7EE86E89365CA94F8E7B8251F9260710035160@CIO-KRC-D1MBX01.osuad.osu.edu> <7EE86E89365CA94F8E7B8251F92607100351DE@CIO-KRC-D1MBX01.osuad.osu.edu> <7EE86E89365CA94F8E7B8251F9260710035299@CIO-KRC-D1MBX01.osuad.osu.edu> <7EE86E89365CA94F8E7B8251F92607100352B9@CIO-KRC-D1MBX01.osuad.osu.edu> 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-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.18 Cc: Josh Howlett , "abfab@ietf.org" Subject: Re: [abfab] Proposed changes to draft-ieft-abfab-aaa-saml 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, 14 Jan 2011 20:58:27 -0000 > 2) When evaluating whether the issuer is permitted to make the > statement being claimed, does it use its rules for the IDP or for the > actual issuer. I.E. does it assume that the IDP has vouched for the > statement or simply passed it along. Well, if by IdP you mean the identity intrinsically associated with the AAA= server, then I guess I would have to say that it's reasonable to say that = you get that technical trust from the AAA layer, but that any other asserti= ons from other issuers should be signed and verified independently (meaning= the rules would be based on the actual issuer). In practice, I don't think IdP-side aggregation works all that well and the= most common SAML profiles basically preclude it unless the IdP reissues th= e data itself, so I tend to focus on doing it at the SP. But then I write = SPs, so that's a bias. I think when we do things like re-issue data at the = IdP end, there's not usually any kind of indicator to the SP that this was = done, because the whole point is often to hide it. > These are both technical decisions that affect interoperability and > security. My claim is that to produce a technical specification that > meets the requirements of RFC 2026 without known technical omissions we > need to tell implementations what to do in these cases. I agree with you that there should be a clear statement about the validity = assumptions one should make about any additional assertions, because normal= ly there is no such assumption...you always validate any assertions you get= . Trying to dodge that requirement (or optimize it out) introduces the need= to be explicit. > I agree with you that various levels of ambiguity have been used with > regard to these sorts of issues in other standards, and we have not been > perfect. However I do think we have considered these sorts of > issues. Often, the answer we've given is "that decision belongs at the > next layer." I don't think we can do that here, although I'd be > interested in evaluating a proposal to do so if someone made one. I > would not support a proposal that required per-IDP configuration. I think I understand you to be saying that you're solely concerned about th= e technical trust component, and not the business level aspect of the truth= of the data or the right of the issuer to speak on what it says. If that's= the case, I agree with you, and it should not require explicit configurati= on per source to control whether validation is done. We do, as I mentioned briefly, need to discuss SAML conditions, though, eve= n in the case of the assertions from the single IdP. *Something* has to eva= luate them, or they have to be precluded by profile from appearing. -- Scott From leifj@sunet.se Mon Jan 17 01:05:15 2011 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 45D823A6ECD for ; Mon, 17 Jan 2011 01:05:15 -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 2zHUwK5qGUys for ; Mon, 17 Jan 2011 01:05:14 -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 2F4E43A6EC8 for ; Mon, 17 Jan 2011 01:05:13 -0800 (PST) Received: from [192.36.125.230] (dhcp.pilsnet.sunet.se [192.36.125.230]) (authenticated bits=0) by backup-server.nordu.net (8.14.3/8.14.3) with ESMTP id p0H97hG8021065 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 17 Jan 2011 10:07:46 +0100 (CET) Message-ID: <4D3406DF.2050106@sunet.se> Date: Mon, 17 Jan 2011 10:07:43 +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: <55DC663C2F4F9F439F23543E0078E8B305A4C9@EXC001> <55DC663C2F4F9F439F23543E0078E8B305A7B8@EXC001> <7EE86E89365CA94F8E7B8251F9260710035160@CIO-KRC-D1MBX01.osuad.osu.edu> <7EE86E89365CA94F8E7B8251F92607100351DE@CIO-KRC-D1MBX01.osuad.osu.edu> <7EE86E89365CA94F8E7B8251F9260710035299@CIO-KRC-D1MBX01.osuad.osu.edu> <7EE86E89365CA94F8E7B8251F92607100352B9@CIO-KRC-D1MBX01.osuad.osu.edu> <7EE86E89365CA94F8E7B8251F926071003532C@CIO-KRC-D1MBX01.osuad.osu.edu> In-Reply-To: <7EE86E89365CA94F8E7B8251F926071003532C@CIO-KRC-D1MBX01.osuad.osu.edu> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [abfab] Proposed changes to draft-ieft-abfab-aaa-saml 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, 17 Jan 2011 09:05:15 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 (no chair hat on for this) > In practice, I don't think IdP-side aggregation works all that well and the most common SAML profiles basically preclude it unless the IdP reissues the data itself, so I tend to focus on doing it at the SP. But then I write SPs, so that's a bias. I think when we do things like re-issue data at the IdP end, there's not usually any kind of indicator to the SP that this was done, because the whole point is often to hide it. > There is a bit of operational experience from so call hub-and-spoke federations to support this. In the federation operators community we've seen example of, ahem, inventiveness at the SAML layer to work around problems introduced by IdP aggregation. Control question for Sam and Scott: is it possible (and reasonably easy) to do SP-centric attribute aggregation for abfab, by which I mean having the SP issue additional attribute queries to IdPs within the AAA-centric trust model proposed by Sam and Josh? Cheers Leif -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk00BtwACgkQ8Jx8FtbMZneYyACfVxN0Ow+wa9hsKRgkyEMCIZuR jusAoK8vAU+dkPQEAImU8/kZvPvv10W0 =pDQv -----END PGP SIGNATURE----- From Josh.Howlett@ja.net Mon Jan 17 06:09:19 2011 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 6367A28C0EB for ; Mon, 17 Jan 2011 06:09:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.42 X-Spam-Level: X-Spam-Status: No, score=-102.42 tagged_above=-999 required=5 tests=[AWL=0.179, 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 VMCHSrOQus55 for ; Mon, 17 Jan 2011 06:09:18 -0800 (PST) Received: from har003676.ukerna.ac.uk (har003676.ukerna.ac.uk [194.82.140.75]) by core3.amsl.com (Postfix) with ESMTP id 8D15528B797 for ; Mon, 17 Jan 2011 06:09:18 -0800 (PST) Received: from har003676.ukerna.ac.uk (localhost.localdomain [127.0.0.1]) by localhost (Email Security Appliance) with SMTP id 890AC4A6B60_D344E27B; Mon, 17 Jan 2011 14:11:51 +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 7C3844A6B6E_D344E26F; Mon, 17 Jan 2011 14:11:50 +0000 (GMT) Received: from EXC001.atlas.ukerna.ac.uk ([193.62.83.37]) by EXC001 ([193.62.83.37]) with mapi id 14.01.0218.012; Mon, 17 Jan 2011 14:12:10 +0000 From: Josh Howlett To: Leif Johansson , "abfab@ietf.org" Thread-Topic: [abfab] Proposed changes to draft-ieft-abfab-aaa-saml Thread-Index: AQHLtCxKIyHwctNWOUmE/oDJ1svZrpPQ8+gAgAPvvoCAAFSFgA== Date: Mon, 17 Jan 2011 14:12:09 +0000 Message-ID: <55DC663C2F4F9F439F23543E0078E8B30779F3@EXC001> References: <55DC663C2F4F9F439F23543E0078E8B305A4C9@EXC001> <55DC663C2F4F9F439F23543E0078E8B305A7B8@EXC001> <7EE86E89365CA94F8E7B8251F9260710035160@CIO-KRC-D1MBX01.osuad.osu.edu> <7EE86E89365CA94F8E7B8251F92607100351DE@CIO-KRC-D1MBX01.osuad.osu.edu> <7EE86E89365CA94F8E7B8251F9260710035299@CIO-KRC-D1MBX01.osuad.osu.edu> <7EE86E89365CA94F8E7B8251F92607100352B9@CIO-KRC-D1MBX01.osuad.osu.edu> <7EE86E89365CA94F8E7B8251F926071003532C@CIO-KRC-D1MBX01.osuad.osu.edu> <4D3406DF.2050106@sunet.se> In-Reply-To: <4D3406DF.2050106@sunet.se> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [194.82.140.76] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Josh Howlett Subject: Re: [abfab] Proposed changes to draft-ieft-abfab-aaa-saml 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, 17 Jan 2011 14:09:19 -0000 > Control question for Sam and Scott: is it possible (and reasonably > easy) to do SP-centric attribute aggregation for abfab, by which I > mean having the SP issue additional attribute queries to IdPs within > the AAA-centric trust model proposed by Sam and Josh? Yes, possible and easy (assuming, obviously, we can assume that the SPs and= IdP have a common identifier for the subject). Josh. JANET(UK) is a trading name of The JNT Association, a company limited by guarantee which is registered in England under No. 2881024=20 and whose Registered Office is at Lumen House, Library Avenue, Harwell Oxford, Didcot, Oxfordshire. OX11 0SG From leifj@sunet.se Mon Jan 17 06:22:32 2011 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 3ABE63A6F39 for ; Mon, 17 Jan 2011 06:22:32 -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 YP4zUPjVDPf4 for ; Mon, 17 Jan 2011 06:22:30 -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 14CD53A6F34 for ; Mon, 17 Jan 2011 06:22:29 -0800 (PST) Received: from [192.36.125.230] (dhcp.pilsnet.sunet.se [192.36.125.230]) (authenticated bits=0) by backup-server.nordu.net (8.14.3/8.14.3) with ESMTP id p0HEP0HQ011613 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 17 Jan 2011 15:25:03 +0100 (CET) Message-ID: <4D34513C.1030706@sunet.se> Date: Mon, 17 Jan 2011 15:25:00 +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: Josh Howlett References: <55DC663C2F4F9F439F23543E0078E8B305A4C9@EXC001> <55DC663C2F4F9F439F23543E0078E8B305A7B8@EXC001> <7EE86E89365CA94F8E7B8251F9260710035160@CIO-KRC-D1MBX01.osuad.osu.edu> <7EE86E89365CA94F8E7B8251F92607100351DE@CIO-KRC-D1MBX01.osuad.osu.edu> <7EE86E89365CA94F8E7B8251F9260710035299@CIO-KRC-D1MBX01.osuad.osu.edu> <7EE86E89365CA94F8E7B8251F92607100352B9@CIO-KRC-D1MBX01.osuad.osu.edu> <7EE86E89365CA94F8E7B8251F926071003532C@CIO-KRC-D1MBX01.osuad.osu.edu> <4D3406DF.2050106@sunet.se> <55DC663C2F4F9F439F23543E0078E8B30779F3@EXC001> In-Reply-To: <55DC663C2F4F9F439F23543E0078E8B30779F3@EXC001> 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] Proposed changes to draft-ieft-abfab-aaa-saml 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, 17 Jan 2011 14:22:32 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 01/17/2011 03:12 PM, Josh Howlett wrote: >> Control question for Sam and Scott: is it possible (and reasonably >> easy) to do SP-centric attribute aggregation for abfab, by which I >> mean having the SP issue additional attribute queries to IdPs within >> the AAA-centric trust model proposed by Sam and Josh? > > Yes, possible and easy (assuming, obviously, we can assume that the SPs and IdP have a common identifier for the subject). Right, that is always an issue but it is one I'm (no chair again) ok to live with... Cheers Leif -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk00UTwACgkQ8Jx8FtbMZnceagCgu5+4g2V2Di+pEErcQVv2gGMQ E/UAn1Q1i3CczPCaO2SV8DDw1KUu5ZW3 =uCb6 -----END PGP SIGNATURE----- From Josh.Howlett@ja.net Mon Jan 17 06:55:32 2011 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 01FC13A6E62 for ; Mon, 17 Jan 2011 06:55:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.429 X-Spam-Level: X-Spam-Status: No, score=-102.429 tagged_above=-999 required=5 tests=[AWL=0.170, 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 gehy53SF9GD4 for ; Mon, 17 Jan 2011 06:55:31 -0800 (PST) Received: from har003676.ukerna.ac.uk (har003676.ukerna.ac.uk [194.82.140.75]) by core3.amsl.com (Postfix) with ESMTP id 288763A6E53 for ; Mon, 17 Jan 2011 06:55:31 -0800 (PST) Received: from har003676.ukerna.ac.uk (localhost.localdomain [127.0.0.1]) by localhost (Email Security Appliance) with SMTP id C87CB4A6B6B_D3458FCB; Mon, 17 Jan 2011 14:58: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 AFCFA4A6B63_D3458FAF; Mon, 17 Jan 2011 14:58:02 +0000 (GMT) Received: from EXC001.atlas.ukerna.ac.uk ([193.62.83.37]) by EXC001 ([193.62.83.37]) with mapi id 14.01.0218.012; Mon, 17 Jan 2011 14:58:22 +0000 From: Josh Howlett To: "Cantor, Scott E." , Sam Hartman Thread-Topic: [abfab] Proposed changes to draft-ieft-abfab-aaa-saml Thread-Index: AQHLtCxKIyHwctNWOUmE/oDJ1svZrpPQ8+gAgARE/YA= Date: Mon, 17 Jan 2011 14:58:21 +0000 Message-ID: <55DC663C2F4F9F439F23543E0078E8B3077A57@EXC001> References: <55DC663C2F4F9F439F23543E0078E8B305A4C9@EXC001> <55DC663C2F4F9F439F23543E0078E8B305A7B8@EXC001> <7EE86E89365CA94F8E7B8251F9260710035160@CIO-KRC-D1MBX01.osuad.osu.edu> <7EE86E89365CA94F8E7B8251F92607100351DE@CIO-KRC-D1MBX01.osuad.osu.edu> <7EE86E89365CA94F8E7B8251F9260710035299@CIO-KRC-D1MBX01.osuad.osu.edu> <7EE86E89365CA94F8E7B8251F92607100352B9@CIO-KRC-D1MBX01.osuad.osu.edu> <7EE86E89365CA94F8E7B8251F926071003532C@CIO-KRC-D1MBX01.osuad.osu.edu> In-Reply-To: <7EE86E89365CA94F8E7B8251F926071003532C@CIO-KRC-D1MBX01.osuad.osu.edu> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [194.82.140.76] 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] Proposed changes to draft-ieft-abfab-aaa-saml 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, 17 Jan 2011 14:55:32 -0000 Scott wrote:=20 > In practice, I don't think IdP-side aggregation works all that well and > the most common SAML profiles basically preclude it unless the IdP > reissues the data itself, so I tend to focus on doing it at the SP. But > then I write SPs, so that's a bias. I also prefer SP-side aggregation. I'm personally okay with IdP-side aggreg= ation within ABFAB scope, if we can do without authentication of aggregated= issuers (i.e. an aggregated issuer is analogous to an IdP-local LDAP direc= tory). Josh. JANET(UK) is a trading name of The JNT Association, a company limited by guarantee which is registered in England under No. 2881024=20 and whose Registered Office is at Lumen House, Library Avenue, Harwell Oxford, Didcot, Oxfordshire. OX11 0SG From klaas@cisco.com Mon Jan 17 07:22:20 2011 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 84E503A6F40 for ; Mon, 17 Jan 2011 07:22:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.524 X-Spam-Level: X-Spam-Status: No, score=-10.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, 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 hjFaTuWo0uc5 for ; Mon, 17 Jan 2011 07:22:19 -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 F021D3A6F3E for ; Mon, 17 Jan 2011 07:22:18 -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: ApwFAN7tM02Q/khNgWdsb2JhbACWO44YFQEBFiIkpzqZDIVQBIsf Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-1.cisco.com with ESMTP; 17 Jan 2011 15:24:52 +0000 Received: from macmini.wierenga.net (ams-kwiereng-8712.cisco.com [10.55.220.243]) by ams-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p0HFOqoD018482 for ; Mon, 17 Jan 2011 15:24:52 GMT Message-ID: <4D345F44.50404@cisco.com> Date: Mon, 17 Jan 2011 16:24:52 +0100 From: Klaas Wierenga User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-GB; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: abfab@ietf.org References: <55DC663C2F4F9F439F23543E0078E8B305A4C9@EXC001> <55DC663C2F4F9F439F23543E0078E8B305A7B8@EXC001> <7EE86E89365CA94F8E7B8251F9260710035160@CIO-KRC-D1MBX01.osuad.osu.edu> <7EE86E89365CA94F8E7B8251F92607100351DE@CIO-KRC-D1MBX01.osuad.osu.edu> <7EE86E89365CA94F8E7B8251F9260710035299@CIO-KRC-D1MBX01.osuad.osu.edu> <7EE86E89365CA94F8E7B8251F92607100352B9@CIO-KRC-D1MBX01.osuad.osu.edu> <7EE86E89365CA94F8E7B8251F926071003532C@CIO-KRC-D1MBX01.osuad.osu.edu> <4D3406DF.2050106@sunet.se> <55DC663C2F4F9F439F23543E0078E8B30779F3@EXC001> In-Reply-To: <55DC663C2F4F9F439F23543E0078E8B30779F3@EXC001> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [abfab] Proposed changes to draft-ieft-abfab-aaa-saml 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, 17 Jan 2011 15:22:20 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 1/17/11 3:12 PM, Josh Howlett wrote: >> Control question for Sam and Scott: is it possible (and reasonably >> easy) to do SP-centric attribute aggregation for abfab, by which I >> mean having the SP issue additional attribute queries to IdPs within >> the AAA-centric trust model proposed by Sam and Josh? > > Yes, possible and easy (assuming, obviously, we can assume that the SPs and IdP have a common identifier for the subject). can the SP only get attributes through the IdP? Klaas -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.14 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk00X0QACgkQH2Wy/p4XeFJI4wCgklByP6gjGHVOrEmkePOCL3cB 2SkAnjbU3LlC0GvrnC3WNoeVcICMadi8 =8Scp -----END PGP SIGNATURE----- From leifj@sunet.se Mon Jan 17 07:28:24 2011 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 71AE93A6F40 for ; Mon, 17 Jan 2011 07:28: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=[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 4bHrzvHHhPA0 for ; Mon, 17 Jan 2011 07:28:23 -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 376193A6F3E for ; Mon, 17 Jan 2011 07:28:22 -0800 (PST) Received: from [192.36.125.230] (dhcp.pilsnet.sunet.se [192.36.125.230]) (authenticated bits=0) by backup-server.nordu.net (8.14.3/8.14.3) with ESMTP id p0HFUsxH025805 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 17 Jan 2011 16:30:56 +0100 (CET) Message-ID: <4D3460AE.6010909@sunet.se> Date: Mon, 17 Jan 2011 16:30:54 +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: <55DC663C2F4F9F439F23543E0078E8B305A4C9@EXC001> <55DC663C2F4F9F439F23543E0078E8B305A7B8@EXC001> <7EE86E89365CA94F8E7B8251F9260710035160@CIO-KRC-D1MBX01.osuad.osu.edu> <7EE86E89365CA94F8E7B8251F92607100351DE@CIO-KRC-D1MBX01.osuad.osu.edu> <7EE86E89365CA94F8E7B8251F9260710035299@CIO-KRC-D1MBX01.osuad.osu.edu> <7EE86E89365CA94F8E7B8251F92607100352B9@CIO-KRC-D1MBX01.osuad.osu.edu> <7EE86E89365CA94F8E7B8251F926071003532C@CIO-KRC-D1MBX01.osuad.osu.edu> <4D3406DF.2050106@sunet.se> <55DC663C2F4F9F439F23543E0078E8B30779F3@EXC001> <4D345F44.50404@cisco.com> In-Reply-To: <4D345F44.50404@cisco.com> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [abfab] Proposed changes to draft-ieft-abfab-aaa-saml 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, 17 Jan 2011 15:28:24 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 01/17/2011 04:24 PM, Klaas Wierenga wrote: > On 1/17/11 3:12 PM, Josh Howlett wrote: >>> Control question for Sam and Scott: is it possible (and reasonably >>> easy) to do SP-centric attribute aggregation for abfab, by which I >>> mean having the SP issue additional attribute queries to IdPs within >>> the AAA-centric trust model proposed by Sam and Josh? > >> Yes, possible and easy (assuming, obviously, we can assume that the SPs and IdP have a common identifier for the subject). > > can the SP only get attributes through the IdP? An AA is an IdP too... -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk00YK0ACgkQ8Jx8FtbMZncWJQCfbA8k0V18x8236tS6C/u1LvqY aZcAoJu55aEVadBluTdVm30Hd1LXnsxM =7cxY -----END PGP SIGNATURE----- From Josh.Howlett@ja.net Mon Jan 17 07:34:19 2011 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 29DB93A6F3E for ; Mon, 17 Jan 2011 07:34:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.437 X-Spam-Level: X-Spam-Status: No, score=-102.437 tagged_above=-999 required=5 tests=[AWL=0.162, 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 2U0K84ANH7jQ for ; Mon, 17 Jan 2011 07:34:18 -0800 (PST) Received: from har003676.ukerna.ac.uk (har003676.ukerna.ac.uk [194.82.140.75]) by core3.amsl.com (Postfix) with ESMTP id 2F0F03A6BCD for ; Mon, 17 Jan 2011 07:34:18 -0800 (PST) Received: from har003676.ukerna.ac.uk (localhost.localdomain [127.0.0.1]) by localhost (Email Security Appliance) with SMTP id D3D974A6B58_D346213B; Mon, 17 Jan 2011 15:36:51 +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 C04C34A6B4E_D346212F; Mon, 17 Jan 2011 15:36:50 +0000 (GMT) Received: from EXC001.atlas.ukerna.ac.uk ([193.62.83.37]) by EXC001 ([193.62.83.37]) with mapi id 14.01.0218.012; Mon, 17 Jan 2011 15:37:10 +0000 From: Josh Howlett To: Klaas Wierenga , "abfab@ietf.org" Thread-Topic: [abfab] Proposed changes to draft-ieft-abfab-aaa-saml Thread-Index: AQHLtCxKIyHwctNWOUmE/oDJ1svZrpPQ8+gAgAPvvoCAAFSFgIAAFNsAgAADCeA= Date: Mon, 17 Jan 2011 15:37:09 +0000 Message-ID: <55DC663C2F4F9F439F23543E0078E8B3078AF3@EXC001> References: <55DC663C2F4F9F439F23543E0078E8B305A4C9@EXC001> <55DC663C2F4F9F439F23543E0078E8B305A7B8@EXC001> <7EE86E89365CA94F8E7B8251F9260710035160@CIO-KRC-D1MBX01.osuad.osu.edu> <7EE86E89365CA94F8E7B8251F92607100351DE@CIO-KRC-D1MBX01.osuad.osu.edu> <7EE86E89365CA94F8E7B8251F9260710035299@CIO-KRC-D1MBX01.osuad.osu.edu> <7EE86E89365CA94F8E7B8251F92607100352B9@CIO-KRC-D1MBX01.osuad.osu.edu> <7EE86E89365CA94F8E7B8251F926071003532C@CIO-KRC-D1MBX01.osuad.osu.edu> <4D3406DF.2050106@sunet.se> <55DC663C2F4F9F439F23543E0078E8B30779F3@EXC001> <4D345F44.50404@cisco.com> In-Reply-To: <4D345F44.50404@cisco.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [194.82.140.76] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Josh Howlett Subject: Re: [abfab] Proposed changes to draft-ieft-abfab-aaa-saml 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, 17 Jan 2011 15:34:19 -0000 > >> Control question for Sam and Scott: is it possible (and reasonably > >> easy) to do SP-centric attribute aggregation for abfab, by which I > >> mean having the SP issue additional attribute queries to IdPs within > >> the AAA-centric trust model proposed by Sam and Josh? > > > > Yes, possible and easy (assuming, obviously, we can assume that the > > SPs and IdP have a common identifier for the subject). >=20 > can the SP only get attributes through the IdP? Sorry, can you clarify the question? (I thought I answered that in my respo= nse) Josh. JANET(UK) is a trading name of The JNT Association, a company limited by guarantee which is registered in England under No. 2881024=20 and whose Registered Office is at Lumen House, Library Avenue, Harwell Oxford, Didcot, Oxfordshire. OX11 0SG From klaas@cisco.com Mon Jan 17 08:04:26 2011 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 BB7FA3A6D45 for ; Mon, 17 Jan 2011 08:04:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.532 X-Spam-Level: X-Spam-Status: No, score=-10.532 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599, 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 s2Yx3fvP0HdE for ; Mon, 17 Jan 2011 08:04:25 -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 874243A6BD8 for ; Mon, 17 Jan 2011 08:04:25 -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: Ar8EAD/3M02Q/khMgWdsb2JhbACkUxUBARYiJKdEmQ6FUASLHw Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-2.cisco.com with ESMTP; 17 Jan 2011 16:06:59 +0000 Received: from macmini.wierenga.net (ams-kwiereng-8712.cisco.com [10.55.220.243]) by ams-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p0HG6xKJ032158; Mon, 17 Jan 2011 16:06:59 GMT Message-ID: <4D346923.1060408@cisco.com> Date: Mon, 17 Jan 2011 17:06:59 +0100 From: Klaas Wierenga User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-GB; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Josh Howlett References: <55DC663C2F4F9F439F23543E0078E8B305A4C9@EXC001> <55DC663C2F4F9F439F23543E0078E8B305A7B8@EXC001> <7EE86E89365CA94F8E7B8251F9260710035160@CIO-KRC-D1MBX01.osuad.osu.edu> <7EE86E89365CA94F8E7B8251F92607100351DE@CIO-KRC-D1MBX01.osuad.osu.edu> <7EE86E89365CA94F8E7B8251F9260710035299@CIO-KRC-D1MBX01.osuad.osu.edu> <7EE86E89365CA94F8E7B8251F92607100352B9@CIO-KRC-D1MBX01.osuad.osu.edu> <7EE86E89365CA94F8E7B8251F926071003532C@CIO-KRC-D1MBX01.osuad.osu.edu> <4D3406DF.2050106@sunet.se> <55DC663C2F4F9F439F23543E0078E8B30779F3@EXC001> <4D345F44.50404@cisco.com> <55DC663C2F4F9F439F23543E0078E8B3078AF3@EXC001> In-Reply-To: <55DC663C2F4F9F439F23543E0078E8B3078AF3@EXC001> 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] Proposed changes to draft-ieft-abfab-aaa-saml 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, 17 Jan 2011 16:04:26 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 1/17/11 4:37 PM, Josh Howlett wrote: >>>> Control question for Sam and Scott: is it possible (and reasonably >>>> easy) to do SP-centric attribute aggregation for abfab, by which I >>>> mean having the SP issue additional attribute queries to IdPs within >>>> the AAA-centric trust model proposed by Sam and Josh? >>> >>> Yes, possible and easy (assuming, obviously, we can assume that the >>> SPs and IdP have a common identifier for the subject). >> >> can the SP only get attributes through the IdP? > > Sorry, can you clarify the question? (I thought I answered that in my response) well, you state that the IdP and the SP need to have an identifier in common for the subject. I was thinking about an attribute authority different from the "original" IdP. So let's say I authenticate to my school and the SP goes on and gets some aditional attributes from the ministry of education... That is covered by Leif's statement "An AA is an IdP too...", but I want to make sure that the trust model allows for that kind of scenario's. Klaas -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.14 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk00aSMACgkQH2Wy/p4XeFKHCgCgkhWNvGj9fy5gu+owbK+pLgru gUcAoIEyZDOXsh2Bv7XrpxJ8VcPjiX6i =aT9S -----END PGP SIGNATURE----- From Josh.Howlett@ja.net Mon Jan 17 10:10:32 2011 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 90BB728C136 for ; Mon, 17 Jan 2011 10:10:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.444 X-Spam-Level: X-Spam-Status: No, score=-102.444 tagged_above=-999 required=5 tests=[AWL=0.155, 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 FurUavLjbEok for ; Mon, 17 Jan 2011 10:10:31 -0800 (PST) Received: from har003676.ukerna.ac.uk (har003676.ukerna.ac.uk [194.82.140.75]) by core3.amsl.com (Postfix) with ESMTP id ACF1728C132 for ; Mon, 17 Jan 2011 10:10:31 -0800 (PST) Received: from har003676.ukerna.ac.uk (localhost.localdomain [127.0.0.1]) by localhost (Email Security Appliance) with SMTP id 6E3DF4A6B6B_D3486B1B; Mon, 17 Jan 2011 18:13:05 +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 5A29C4A6B65_D3486B0F; Mon, 17 Jan 2011 18:13:04 +0000 (GMT) Received: from EXC001.atlas.ukerna.ac.uk ([193.62.83.37]) by EXC001 ([193.62.83.37]) with mapi id 14.01.0218.012; Mon, 17 Jan 2011 18:13:24 +0000 From: Josh Howlett To: Klaas Wierenga Thread-Topic: [abfab] Proposed changes to draft-ieft-abfab-aaa-saml Thread-Index: AQHLtCxKIyHwctNWOUmE/oDJ1svZrpPQ8+gAgAPvvoCAAFSFgIAAFNsAgAADCeCAAAi8gIAAIe2g Date: Mon, 17 Jan 2011 18:13:22 +0000 Message-ID: <55DC663C2F4F9F439F23543E0078E8B3078C2A@EXC001> References: <55DC663C2F4F9F439F23543E0078E8B305A4C9@EXC001> <55DC663C2F4F9F439F23543E0078E8B305A7B8@EXC001> <7EE86E89365CA94F8E7B8251F9260710035160@CIO-KRC-D1MBX01.osuad.osu.edu> <7EE86E89365CA94F8E7B8251F92607100351DE@CIO-KRC-D1MBX01.osuad.osu.edu> <7EE86E89365CA94F8E7B8251F9260710035299@CIO-KRC-D1MBX01.osuad.osu.edu> <7EE86E89365CA94F8E7B8251F92607100352B9@CIO-KRC-D1MBX01.osuad.osu.edu> <7EE86E89365CA94F8E7B8251F926071003532C@CIO-KRC-D1MBX01.osuad.osu.edu> <4D3406DF.2050106@sunet.se> <55DC663C2F4F9F439F23543E0078E8B30779F3@EXC001> <4D345F44.50404@cisco.com> <55DC663C2F4F9F439F23543E0078E8B3078AF3@EXC001> <4D346923.1060408@cisco.com> In-Reply-To: <4D346923.1060408@cisco.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-cr-puzzleid: {138585D3-A008-4897-B9CC-A9A61FF44787} x-cr-hashedpuzzle: CBz3 D8/j Emzr GXJd IHlg JAcz Lzwy N0VX PNC3 QlvR RRPY SLPX SuhH TLWo Tj8n ULQK; 2; YQBiAGYAYQBiAEAAaQBlAHQAZgAuAG8AcgBnADsAawBsAGEAYQBzAEAAYwBpAHMAYwBvAC4AYwBvAG0A; Sosha1_v1; 7; {138585D3-A008-4897-B9CC-A9A61FF44787}; agBvAHMAaAAuAGgAbwB3AGwAZQB0AHQAQABqAGEALgBuAGUAdAA=; Mon, 17 Jan 2011 18:12:45 GMT; UgBFADoAIABbAGEAYgBmAGEAYgBdACAAUAByAG8AcABvAHMAZQBkACAAYwBoAGEAbgBnAGUAcwAgAHQAbwAgAGQAcgBhAGYAdAAtAGkAZQBmAHQALQBhAGIAZgBhAGIALQBhAGEAYQAtAHMAYQBtAGwA x-originating-ip: [194.82.140.76] 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] Proposed changes to draft-ieft-abfab-aaa-saml 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, 17 Jan 2011 18:10:32 -0000 > well, you state that the IdP and the SP need to have an identifier in > common for the subject. I was thinking about an attribute authority > different from the "original" IdP. So let's say I authenticate to my > school and the SP goes on and gets some aditional attributes from the > ministry of education... That is covered by Leif's statement "An AA is > an IdP too...", but I want to make sure that the trust model allows for > that kind of scenario's. Yes, it does. Josh. JANET(UK) is a trading name of The JNT Association, a company limited by guarantee which is registered in England under No. 2881024=20 and whose Registered Office is at Lumen House, Library Avenue, Harwell Oxford, Didcot, Oxfordshire. OX11 0SG From hartmans@painless-security.com Tue Jan 18 07:32:44 2011 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 1607B3A7025 for ; Tue, 18 Jan 2011 07:32:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.287 X-Spam-Level: X-Spam-Status: No, score=-2.287 tagged_above=-999 required=5 tests=[AWL=-0.022, 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 zS1E7ML8vMe2 for ; Tue, 18 Jan 2011 07:32:43 -0800 (PST) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by core3.amsl.com (Postfix) with ESMTP id 206AD3A7024 for ; Tue, 18 Jan 2011 07:32:42 -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 2A25120222; Tue, 18 Jan 2011 10:33:37 -0500 (EST) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 15A2B432C; Tue, 18 Jan 2011 10:35:18 -0500 (EST) From: Sam Hartman To: Josh Howlett References: <55DC663C2F4F9F439F23543E0078E8B305A4C9@EXC001> <55DC663C2F4F9F439F23543E0078E8B305A7B8@EXC001> <7EE86E89365CA94F8E7B8251F9260710035160@CIO-KRC-D1MBX01.osuad.osu.edu> <7EE86E89365CA94F8E7B8251F92607100351DE@CIO-KRC-D1MBX01.osuad.osu.edu> <7EE86E89365CA94F8E7B8251F9260710035299@CIO-KRC-D1MBX01.osuad.osu.edu> <7EE86E89365CA94F8E7B8251F92607100352B9@CIO-KRC-D1MBX01.osuad.osu.edu> <7EE86E89365CA94F8E7B8251F926071003532C@CIO-KRC-D1MBX01.osuad.osu.edu> <4D3406DF.2050106@sunet.se> <55DC663C2F4F9F439F23543E0078E8B30779F3@EXC001> Date: Tue, 18 Jan 2011 10:35:18 -0500 In-Reply-To: <55DC663C2F4F9F439F23543E0078E8B30779F3@EXC001> (Josh Howlett's message of "Mon, 17 Jan 2011 14:12:09 +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] Proposed changes to draft-ieft-abfab-aaa-saml 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, 18 Jan 2011 15:32:44 -0000 >>>>> "Josh" == Josh Howlett writes: >> Control question for Sam and Scott: is it possible (and >> reasonably easy) to do SP-centric attribute aggregation for >> abfab, by which I mean having the SP issue additional attribute >> queries to IdPs within the AAA-centric trust model proposed by >> Sam and Josh? Josh> Yes, possible and easy (assuming, obviously, we can assume Josh> that the SPs and IdP have a common identifier for the Josh> subject). Josh, I suspect you are right, but the details are not clear to me. How does the SP address the request to a particular AA? From Josh.Howlett@ja.net Tue Jan 18 08:06:04 2011 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 73E6028C102 for ; Tue, 18 Jan 2011 08:06:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.451 X-Spam-Level: X-Spam-Status: No, score=-102.451 tagged_above=-999 required=5 tests=[AWL=0.148, 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 NHjDug7hbsMx for ; Tue, 18 Jan 2011 08:06:03 -0800 (PST) Received: from har003676.ukerna.ac.uk (har003676.ukerna.ac.uk [194.82.140.75]) by core3.amsl.com (Postfix) with ESMTP id 780E628C0F3 for ; Tue, 18 Jan 2011 08:06:03 -0800 (PST) Received: from har003676.ukerna.ac.uk (localhost.localdomain [127.0.0.1]) by localhost (Email Security Appliance) with SMTP id 7F2274A6B67_D35BB07B; Tue, 18 Jan 2011 16:08: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 67BD04A6B63_D35BB05F; Tue, 18 Jan 2011 16:08:37 +0000 (GMT) Received: from EXC001.atlas.ukerna.ac.uk ([193.62.83.37]) by EXC001 ([193.62.83.37]) with mapi id 14.01.0218.012; Tue, 18 Jan 2011 16:08:57 +0000 From: Josh Howlett To: Sam Hartman Thread-Topic: [abfab] Proposed changes to draft-ieft-abfab-aaa-saml Thread-Index: AQHLtyVPIyHwctNWOUmE/oDJ1svZrpPW4XIg Date: Tue, 18 Jan 2011 16:08:56 +0000 Message-ID: <55DC663C2F4F9F439F23543E0078E8B307F21D@EXC001> References: <55DC663C2F4F9F439F23543E0078E8B305A4C9@EXC001> <55DC663C2F4F9F439F23543E0078E8B305A7B8@EXC001> <7EE86E89365CA94F8E7B8251F9260710035160@CIO-KRC-D1MBX01.osuad.osu.edu> <7EE86E89365CA94F8E7B8251F92607100351DE@CIO-KRC-D1MBX01.osuad.osu.edu> <7EE86E89365CA94F8E7B8251F9260710035299@CIO-KRC-D1MBX01.osuad.osu.edu> <7EE86E89365CA94F8E7B8251F92607100352B9@CIO-KRC-D1MBX01.osuad.osu.edu> <7EE86E89365CA94F8E7B8251F926071003532C@CIO-KRC-D1MBX01.osuad.osu.edu> <4D3406DF.2050106@sunet.se> <55DC663C2F4F9F439F23543E0078E8B30779F3@EXC001> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [194.82.140.76] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Howlett , "abfab@ietf.org" , Josh Subject: Re: [abfab] Proposed changes to draft-ieft-abfab-aaa-saml 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, 18 Jan 2011 16:06:04 -0000 > >> Control question for Sam and Scott: is it possible (and > >> reasonably easy) to do SP-centric attribute aggregation for > >> abfab, by which I mean having the SP issue additional attribute > >> queries to IdPs within the AAA-centric trust model proposed by > >> Sam and Josh? >=20 > Josh> Yes, possible and easy (assuming, obviously, we can assume > Josh> that the SPs and IdP have a common identifier for the > Josh> subject). >=20 > Josh, I suspect you are right, but the details are not clear to me. Nor me in truth; I suspect that I am about to discover it was inadvisable o= f me to claim 'easy' :-) > How does the SP address the request to a particular AA? The model that I have in mind is that we specify a set of standard endpoint= locator names for different type of Issuer roles. These can be used, in co= njunction with the NAI realm of the Issuer, to construct a complete NAI. e.g. say we specify the "saml-20-aa" name to mean a SAML 2.0 attribute auth= ority. An SP wanting to route a message to this actor to example.com prefix= es the realm of the intended Issuer with this, thus "saml-20-aa.example.com= ". The AAA SAML attribute within this request message contains a SAML Reque= st message containing the identifier for the subject.=20 Josh. JANET(UK) is a trading name of The JNT Association, a company limited by guarantee which is registered in England under No. 2881024=20 and whose Registered Office is at Lumen House, Library Avenue, Harwell Oxford, Didcot, Oxfordshire. OX11 0SG From klaas@cisco.com Tue Jan 18 08:15:20 2011 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 5726E3A7032 for ; Tue, 18 Jan 2011 08:15:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.539 X-Spam-Level: X-Spam-Status: No, score=-10.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, 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 wd2u+JYGsGso for ; Tue, 18 Jan 2011 08:15:19 -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 DA95B3A7034 for ; Tue, 18 Jan 2011 08:15:18 -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: AqsEAENMNU2Q/khLgWdsb2JhbACWQY4YFQEBFiIkqEGaBIVQBIse Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-1.cisco.com with ESMTP; 18 Jan 2011 16:17:55 +0000 Received: from macmini.wierenga.net (ams-kwiereng-8712.cisco.com [10.55.220.243]) by ams-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p0IGHtoJ021108 for ; Tue, 18 Jan 2011 16:17:55 GMT Message-ID: <4D35BD33.2050608@cisco.com> Date: Tue, 18 Jan 2011 17:17:55 +0100 From: Klaas Wierenga User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-GB; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: abfab@ietf.org References: <55DC663C2F4F9F439F23543E0078E8B305A4C9@EXC001> <55DC663C2F4F9F439F23543E0078E8B305A7B8@EXC001> <7EE86E89365CA94F8E7B8251F9260710035160@CIO-KRC-D1MBX01.osuad.osu.edu> <7EE86E89365CA94F8E7B8251F92607100351DE@CIO-KRC-D1MBX01.osuad.osu.edu> <7EE86E89365CA94F8E7B8251F9260710035299@CIO-KRC-D1MBX01.osuad.osu.edu> <7EE86E89365CA94F8E7B8251F92607100352B9@CIO-KRC-D1MBX01.osuad.osu.edu> <7EE86E89365CA94F8E7B8251F926071003532C@CIO-KRC-D1MBX01.osuad.osu.edu> <4D3406DF.2050106@sunet.se> <55DC663C2F4F9F439F23543E0078E8B30779F3@EXC001> <55DC663C2F4F9F439F23543E0078E8B307F21D@EXC001> In-Reply-To: <55DC663C2F4F9F439F23543E0078E8B307F21D@EXC001> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [abfab] Proposed changes to draft-ieft-abfab-aaa-saml 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, 18 Jan 2011 16:15:20 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 1/18/11 5:08 PM, Josh Howlett wrote: >> >> Control question for Sam and Scott: is it possible (and >> >> reasonably easy) to do SP-centric attribute aggregation for >> >> abfab, by which I mean having the SP issue additional attribute >> >> queries to IdPs within the AAA-centric trust model proposed by >> >> Sam and Josh? >> >> Josh> Yes, possible and easy (assuming, obviously, we can assume >> Josh> that the SPs and IdP have a common identifier for the >> Josh> subject). >> >> Josh, I suspect you are right, but the details are not clear to me. > > Nor me in truth; I suspect that I am about to discover it was inadvisable of me to claim 'easy' :-) > >> How does the SP address the request to a particular AA? > > The model that I have in mind is that we specify a set of standard endpoint locator names for different type of Issuer roles. These can be used, in conjunction with the NAI realm of the Issuer, to construct a complete NAI. > > e.g. say we specify the "saml-20-aa" name to mean a SAML 2.0 attribute authority. An SP wanting to route a message to this actor to example.com prefixes the realm of the intended Issuer with this, thus "saml-20-aa.example.com". The AAA SAML attribute within this request message contains a SAML Request message containing the identifier for the subject. ehrm, that means there can only be one AA per realm? Klaas > > 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 Oxford, Didcot, Oxfordshire. OX11 0SG > > _______________________________________________ > abfab mailing list > abfab@ietf.org > https://www.ietf.org/mailman/listinfo/abfab -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.14 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk01vTMACgkQH2Wy/p4XeFKrNwCgwHwYGbOoQzf2PZbrlESQrL+M 1qwAn18ifZoYdY4hObd8AebQVaeZD3lT =tNXp -----END PGP SIGNATURE----- From Josh.Howlett@ja.net Tue Jan 18 08:18:18 2011 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 4DA723A702C for ; Tue, 18 Jan 2011 08:18:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.457 X-Spam-Level: X-Spam-Status: No, score=-102.457 tagged_above=-999 required=5 tests=[AWL=0.142, 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 yqZ4yLABsO93 for ; Tue, 18 Jan 2011 08:18:17 -0800 (PST) Received: from har003676.ukerna.ac.uk (har003676.ukerna.ac.uk [194.82.140.75]) by core3.amsl.com (Postfix) with ESMTP id 6C7E83A7021 for ; Tue, 18 Jan 2011 08:18:17 -0800 (PST) Received: from har003676.ukerna.ac.uk (localhost.localdomain [127.0.0.1]) by localhost (Email Security Appliance) with SMTP id 96D704A6B78_D35BDE6B; Tue, 18 Jan 2011 16:20:54 +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 89A9A4A6B73_D35BDE5F; Tue, 18 Jan 2011 16:20:53 +0000 (GMT) Received: from EXC001.atlas.ukerna.ac.uk ([193.62.83.37]) by EXC001 ([193.62.83.37]) with mapi id 14.01.0218.012; Tue, 18 Jan 2011 16:21:13 +0000 From: Josh Howlett To: Klaas Wierenga , "abfab@ietf.org" Thread-Topic: [abfab] Proposed changes to draft-ieft-abfab-aaa-saml Thread-Index: AQHLtyVPIyHwctNWOUmE/oDJ1svZrpPW4XIggAAGyYCAAABboA== Date: Tue, 18 Jan 2011 16:21:12 +0000 Message-ID: <55DC663C2F4F9F439F23543E0078E8B307F26F@EXC001> References: <55DC663C2F4F9F439F23543E0078E8B305A4C9@EXC001> <55DC663C2F4F9F439F23543E0078E8B305A7B8@EXC001> <7EE86E89365CA94F8E7B8251F9260710035160@CIO-KRC-D1MBX01.osuad.osu.edu> <7EE86E89365CA94F8E7B8251F92607100351DE@CIO-KRC-D1MBX01.osuad.osu.edu> <7EE86E89365CA94F8E7B8251F9260710035299@CIO-KRC-D1MBX01.osuad.osu.edu> <7EE86E89365CA94F8E7B8251F92607100352B9@CIO-KRC-D1MBX01.osuad.osu.edu> <7EE86E89365CA94F8E7B8251F926071003532C@CIO-KRC-D1MBX01.osuad.osu.edu> <4D3406DF.2050106@sunet.se> <55DC663C2F4F9F439F23543E0078E8B30779F3@EXC001> <55DC663C2F4F9F439F23543E0078E8B307F21D@EXC001> <4D35BD33.2050608@cisco.com> In-Reply-To: <4D35BD33.2050608@cisco.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [194.82.140.76] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Josh Howlett Subject: Re: [abfab] Proposed changes to draft-ieft-abfab-aaa-saml 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, 18 Jan 2011 16:18:18 -0000 > > e.g. say we specify the "saml-20-aa" name to mean a SAML 2.0 > attribute authority. An SP wanting to route a message to this actor to > example.com prefixes the realm of the intended Issuer with this, thus > "saml-20-aa.example.com". The AAA SAML attribute within this request > message contains a SAML Request message containing the identifier for > the subject. >=20 > ehrm, that means there can only be one AA per realm? If that matters, I think you could have multiple AAs and disambiguate by ex= tending the naming semantics of the NAI. Josh. JANET(UK) is a trading name of The JNT Association, a company limited by guarantee which is registered in England under No. 2881024=20 and whose Registered Office is at Lumen House, Library Avenue, Harwell Oxford, Didcot, Oxfordshire. OX11 0SG From hartmans@painless-security.com Tue Jan 18 08:18:26 2011 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 A66313A7040 for ; Tue, 18 Jan 2011 08:18:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.286 X-Spam-Level: X-Spam-Status: No, score=-2.286 tagged_above=-999 required=5 tests=[AWL=-0.021, 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 PSUmIL25Js91 for ; Tue, 18 Jan 2011 08:18:26 -0800 (PST) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by core3.amsl.com (Postfix) with ESMTP id E90883A703F for ; Tue, 18 Jan 2011 08:18:25 -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 57AC9201FB; Tue, 18 Jan 2011 11:19:14 -0500 (EST) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 73E58432C; Tue, 18 Jan 2011 11:20:54 -0500 (EST) From: Sam Hartman To: Josh Howlett References: <55DC663C2F4F9F439F23543E0078E8B305A4C9@EXC001> <55DC663C2F4F9F439F23543E0078E8B305A7B8@EXC001> <7EE86E89365CA94F8E7B8251F9260710035160@CIO-KRC-D1MBX01.osuad.osu.edu> <7EE86E89365CA94F8E7B8251F92607100351DE@CIO-KRC-D1MBX01.osuad.osu.edu> <7EE86E89365CA94F8E7B8251F9260710035299@CIO-KRC-D1MBX01.osuad.osu.edu> <7EE86E89365CA94F8E7B8251F92607100352B9@CIO-KRC-D1MBX01.osuad.osu.edu> <7EE86E89365CA94F8E7B8251F926071003532C@CIO-KRC-D1MBX01.osuad.osu.edu> <4D3406DF.2050106@sunet.se> <55DC663C2F4F9F439F23543E0078E8B30779F3@EXC001> <55DC663C2F4F9F439F23543E0078E8B307F21D@EXC001> Date: Tue, 18 Jan 2011 11:20:54 -0500 In-Reply-To: <55DC663C2F4F9F439F23543E0078E8B307F21D@EXC001> (Josh Howlett's message of "Tue, 18 Jan 2011 16:08:56 +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] Proposed changes to draft-ieft-abfab-aaa-saml 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, 18 Jan 2011 16:18:26 -0000 Hmm. OK. This sounds like it is taking the authorization-only service a bit further than I thought it worked today. Interesting though. From trscavo@gmail.com Tue Jan 18 10:01:07 2011 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 484483A6FE2 for ; Tue, 18 Jan 2011 10:01:07 -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 FJR1MISapZLC for ; Tue, 18 Jan 2011 10:01:06 -0800 (PST) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by core3.amsl.com (Postfix) with ESMTP id 49BA33A7053 for ; Tue, 18 Jan 2011 10:01:06 -0800 (PST) Received: by gxk28 with SMTP id 28so2703208gxk.31 for ; Tue, 18 Jan 2011 10:03:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=+V92jJnzsIuze2ZoOcFRRMas3yud4LoZF2JFNQQFkhw=; b=jw2i7rk7a5JDR646cJwStzUGcgg+teBCtklkU54LvZDBDo0BIJmnd2JYepcUdI1B/f A0Ak5uA0miTbggTNWL4kdu4B756qnytYYsfuE6vZmoZoxQJb+qcx7/DkaTAGys2ci31Q 4YJBrcLL/rvBJieskCGx013ozQyi6CPURHQ6o= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=krprs9AYcquzHsrWXKc03jmBlOeHw80mto7RW1SnywMxHqxLaPln5KPgdZSlU0wyiw 8bVUSz7paloOe/wAixiw8+WaMnEwpLo/0mIN9oxqFHcyBDr+ZTVcOrKQZ2LfFTcOVFZV XrFuO+n1UjbNLtjaEtnNTqysg8Zx20hI/gzgI= MIME-Version: 1.0 Received: by 10.223.96.73 with SMTP id g9mr6691988fan.24.1295373823046; Tue, 18 Jan 2011 10:03:43 -0800 (PST) Received: by 10.223.87.6 with HTTP; Tue, 18 Jan 2011 10:03:42 -0800 (PST) In-Reply-To: <55DC663C2F4F9F439F23543E0078E8B307F21D@EXC001> References: <55DC663C2F4F9F439F23543E0078E8B305A4C9@EXC001> <55DC663C2F4F9F439F23543E0078E8B305A7B8@EXC001> <7EE86E89365CA94F8E7B8251F9260710035160@CIO-KRC-D1MBX01.osuad.osu.edu> <7EE86E89365CA94F8E7B8251F92607100351DE@CIO-KRC-D1MBX01.osuad.osu.edu> <7EE86E89365CA94F8E7B8251F9260710035299@CIO-KRC-D1MBX01.osuad.osu.edu> <7EE86E89365CA94F8E7B8251F92607100352B9@CIO-KRC-D1MBX01.osuad.osu.edu> <7EE86E89365CA94F8E7B8251F926071003532C@CIO-KRC-D1MBX01.osuad.osu.edu> <4D3406DF.2050106@sunet.se> <55DC663C2F4F9F439F23543E0078E8B30779F3@EXC001> <55DC663C2F4F9F439F23543E0078E8B307F21D@EXC001> Date: Tue, 18 Jan 2011 12:03:42 -0600 Message-ID: From: Tom Scavo To: Josh Howlett Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "abfab@ietf.org" , Josh@core3.amsl.com Subject: Re: [abfab] Proposed changes to draft-ieft-abfab-aaa-saml 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, 18 Jan 2011 18:01:07 -0000 On Tue, Jan 18, 2011 at 10:08 AM, Josh Howlett wrote: >> =A0 =A0 >> Control question for Sam and Scott: is it possible (and >> =A0 =A0 >> reasonably easy) to do SP-centric attribute aggregation for >> =A0 =A0 >> abfab, by which I mean having the SP issue additional attribu= te >> =A0 =A0 >> queries to IdPs within the AAA-centric trust model proposed b= y >> =A0 =A0 >> Sam and Josh? >> >> =A0 =A0 Josh> Yes, possible and easy (assuming, obviously, we can assume >> =A0 =A0 Josh> that the SPs and IdP have a common identifier for the >> =A0 =A0 Josh> subject). >> >> Josh, I suspect you are right, but the details are not clear to me. > > Nor me in truth; I suspect that I am about to discover it was inadvisable= of me to claim 'easy' :-) It depends on the trust relationship the SP has with the various AAs in question, but in general, this is a hard problem. How does the SP prove to the AA that the user is present and actively involved in the transaction? The AA would have to have a fairly liberal attribute release policy to hand out user attributes to the SP without some form of user consent. Tom From Josh.Howlett@ja.net Tue Jan 18 10:55:51 2011 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 F13A63A7059 for ; Tue, 18 Jan 2011 10:55:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.463 X-Spam-Level: X-Spam-Status: No, score=-102.463 tagged_above=-999 required=5 tests=[AWL=0.136, 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 PKte1z8+SRjV for ; Tue, 18 Jan 2011 10:55:50 -0800 (PST) Received: from har003676.ukerna.ac.uk (har003676.ukerna.ac.uk [194.82.140.75]) by core3.amsl.com (Postfix) with ESMTP id 1212B3A6FAA for ; Tue, 18 Jan 2011 10:55:50 -0800 (PST) Received: from har003676.ukerna.ac.uk (localhost.localdomain [127.0.0.1]) by localhost (Email Security Appliance) with SMTP id 0F7BC4A6B58_D35E2D3B; Tue, 18 Jan 2011 18:58:27 +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 E53FC4A6B4E_D35E2CFF; Tue, 18 Jan 2011 18:58:23 +0000 (GMT) Received: from EXC001.atlas.ukerna.ac.uk ([193.62.83.37]) by EXC001 ([193.62.83.37]) with mapi id 14.01.0218.012; Tue, 18 Jan 2011 18:58:43 +0000 From: Josh Howlett To: Tom Scavo Thread-Topic: [abfab] Proposed changes to draft-ieft-abfab-aaa-saml Thread-Index: AQHLtyVPIyHwctNWOUmE/oDJ1svZrpPW4XIggAAkWACAAAifgA== Date: Tue, 18 Jan 2011 18:58:42 +0000 Message-ID: <55DC663C2F4F9F439F23543E0078E8B307F4C7@EXC001> References: <55DC663C2F4F9F439F23543E0078E8B305A4C9@EXC001> <55DC663C2F4F9F439F23543E0078E8B305A7B8@EXC001> <7EE86E89365CA94F8E7B8251F9260710035160@CIO-KRC-D1MBX01.osuad.osu.edu> <7EE86E89365CA94F8E7B8251F92607100351DE@CIO-KRC-D1MBX01.osuad.osu.edu> <7EE86E89365CA94F8E7B8251F9260710035299@CIO-KRC-D1MBX01.osuad.osu.edu> <7EE86E89365CA94F8E7B8251F92607100352B9@CIO-KRC-D1MBX01.osuad.osu.edu> <7EE86E89365CA94F8E7B8251F926071003532C@CIO-KRC-D1MBX01.osuad.osu.edu> <4D3406DF.2050106@sunet.se> <55DC663C2F4F9F439F23543E0078E8B30779F3@EXC001> <55DC663C2F4F9F439F23543E0078E8B307F21D@EXC001> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [194.82.140.76] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Josh Howlett , "abfab@ietf.org" , "Josh@core3.amsl.com" Subject: Re: [abfab] Proposed changes to draft-ieft-abfab-aaa-saml 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, 18 Jan 2011 18:55:51 -0000 Tom, > It depends on the trust relationship the SP has with the various AAs > in question, but in general, this is a hard problem. How does the SP > prove to the AA that the user is present and actively involved in the > transaction? The AA would have to have a fairly liberal attribute > release policy to hand out user attributes to the SP without some form > of user consent. Right, this is an important point. I don't think consent is a showstopper i= n the sense that one can reasonably choose to not care about consent in man= y scenarios. However, I agree that it would be very desirable to have a str= ong story for consent. ABFAB *may* provide a better approach for consent than that which can be ac= hieved through the conventional HTTP-based bindings, because the architectu= re posits an agent (the EAP peer) on the subject's host which could communi= cate directly with any Issuer known by the subject (e.g. the AA uses some k= ind of RPC to request user interaction through this agent). We have previou= sly considered the agent as primarily a means of managing user interaction = for identity selection, but it doesn't seem unreasonable to extend this to = consent management. I think we have previously concluded that it would be reasonable to apply t= his kind of approach, but there isn't a concrete proposal on the table at t= he moment. Suggestions 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 Oxford, Didcot, Oxfordshire. OX11 0SG From ietf@augustcellars.com Wed Jan 19 15:15:46 2011 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 0C11B28C0F1 for ; Wed, 19 Jan 2011 15:15:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_12=0.6, J_CHICKENPOX_53=0.6] 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 BLPoKa6waNKU for ; Wed, 19 Jan 2011 15:15:45 -0800 (PST) Received: from new-smtp01.pacifier.net (new-smtp01.pacifier.net [64.255.237.177]) by core3.amsl.com (Postfix) with ESMTP id 0EB9C3A7021 for ; Wed, 19 Jan 2011 15:15:45 -0800 (PST) Received: from TITUS (static-66-14-119-7.bdsl.verizon.net [66.14.119.7]) (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 812DD2CA64; Wed, 19 Jan 2011 15:18:25 -0800 (PST) From: "Jim Schaad" To: "'Sam Hartman'" , "'Klaas Wierenga'" References: <4D10F279.3030601@cisco.com> <4D2AEE2A.1080808@cisco.com> In-Reply-To: Date: Wed, 19 Jan 2011 15:36:39 -0800 Message-ID: <015501cbb831$bc840cb0$358c2610$@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: AQIjQuKbZ+gCK9OCb+PYvsteFk6r7AHNoxy4AZSyxXSTDsdq0A== Content-Language: en-us Cc: abfab@ietf.org Subject: Re: [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: Wed, 19 Jan 2011 23:15:46 -0000 > -----Original Message----- > From: abfab-bounces@ietf.org [mailto:abfab-bounces@ietf.org] On Behalf > Of Sam Hartman > Sent: Monday, January 10, 2011 10:28 AM > To: Klaas Wierenga > Cc: abfab@ietf.org > Subject: Re: [abfab] draft-lear-abfab-arch-01 posted > > Klaas, thanks so much for your comments. > I'm responding as an individual not on behalf of the authors as a group. > > I agree that we need to do a better job of discussing federation selection; > the current text does not do much about that. This is definitely a good > comment and something for us to work on. > > You ask whether we intend to preclude SOAP. I think that's for you to tell us: > we've had a WG discussion on this topic and I think we have enough of a > discussion to approach a consensus. My reading is that we are going to focus > on AAA transport but nothing will preclude soap. > However it would be useful to get a consensus call from the chairs on this.' Are we looking at SOAP as a message format or at SOAP as a transport ? I don't think that they are necessarily the same thing. > > I agree that the specific protocol flows could be moved later in the document > and that would improve things. > I think it's a little complicated where you want this information: there is some > value in having the diagrams fairly early. I am in favor of having some diagrams really early in the processes. I think this really helps to get understanding setup early. But I tend to be a very pictorial person. > > You propose introducing more abstraction: having an abstract discussion of > the aspects of the system and then discussing specific technology choices. > Definitely for the application integration, where we've acknowledged in our > charter that other options are possible, we should do this. Also, we should > separate the abstract discussion of AAA from RADIUS and Diameter. > However, the use of AAA, EAP, and to some extent SAML is baked in at a > fairly deep level. > So, we're not obligated to treat things abstractly. > We can if it makes the document flow better. However sometimes it is easier > to understand one concrete system than a bunch of abstractions. > So, can we explore how valuable that will actually be? > > > 3.3 p14 "GSS-API is specified...": What is the relevance of mentioning the > sub-operations of the initial context exchange? > > > No, not really. > I thought it might, but it didn't end up being useful. > > > 4 p17 It seems that part of this discussion belongs higher up in the document > (design goals?) and part is implementation choices > > It's hard to discuss this abstractly. I don't think we have enough community > experience for that discussion nor do I think we understand what this would > mean abstractly well enough to have this discussion before the discussions of > concrete technologies. > So, I'm sympathetic to the concern, but I'm not sure I know how to do what > you ask. > If you want to throw something together or have a chat, we could do that. > > 4.1 p17: explain better what is confusing about the mutual authentication > terminology > > It's that to some people mutual authentication implies that the client's > identity is being released. > In GSS, that's not true. > > > 4.2 p18 first paragraph: the sentence starting with "Even when it is checked" > is not a well-formed sentence, and I don't understand what it should read. > > Ah, a typeo. s:if the trust:the trust > 4.2 p19: I don't really understand the whiteboard example, how is the user > able to validate the content that is being displayed? What if some users get > (slightly) different content than others? > > Note here we're talking about a physical electronic LCD whiteboard in a > room, not some shared conference whiteboard software.Typically a > presenter can validate the content of their own presentation. How do we > deal with attacks that give different users different content? I claim that an > attack that presents different content to people in the same physical room > looking at the same LCD is outside of the scope of > ABFAB:-) > If we make the context clear--that we're talking about a networked LCD--is > this example more clear? > 4.2 p19 last paragraph: i think if you explain GSS-API CB you also need to > explain EAP CB > > I agree that this document needs to discuss EAP channel binding. We > propose to do that in the unwritten section 6.1 as part of the deployment > discussion. > I guess we could briefly discuss in section 3 as well. The discussion may also need to include problems with matching names. If you have a TLS DNS name and you have some type of Kerbros realm name - they may not be the same name but still be the same entity. > 4.3 p19 "Using host based service...": Why does ABFAB need to adopt this > approach? > > > We need to adopt this approach if we want ABFAB to work with IMAP, SMTP, > LDAP, SSH, NFS or a variety of other protocols that use this naming approach. > We could alternatively update all those specifications and update all the > implementations that use generic frameworks such as SSPI or Cyrus SASL. > This is a case where following the existing standards makes deploymentand > implementation easier. > Can you suggest additional text for the last paragraph of this section to better > clarify? > _______________________________________________ > abfab mailing list > abfab@ietf.org > https://www.ietf.org/mailman/listinfo/abfab From hartmans@painless-security.com Wed Jan 19 15:30:02 2011 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 108343A71D9 for ; Wed, 19 Jan 2011 15:30:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.285 X-Spam-Level: X-Spam-Status: No, score=-2.285 tagged_above=-999 required=5 tests=[AWL=-0.020, 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 DbSjQCF2Eixq for ; Wed, 19 Jan 2011 15:30:01 -0800 (PST) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by core3.amsl.com (Postfix) with ESMTP id 245ED3A71C5 for ; Wed, 19 Jan 2011 15:30: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 3A6FF20239; Wed, 19 Jan 2011 18:30:55 -0500 (EST) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id D3192432C; Wed, 19 Jan 2011 18:32:34 -0500 (EST) From: Sam Hartman To: "Jim Schaad" References: <4D10F279.3030601@cisco.com> <4D2AEE2A.1080808@cisco.com> <015501cbb831$bc840cb0$358c2610$@augustcellars.com> Date: Wed, 19 Jan 2011 18:32:34 -0500 In-Reply-To: <015501cbb831$bc840cb0$358c2610$@augustcellars.com> (Jim Schaad's message of "Wed, 19 Jan 2011 15:36:39 -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] 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: Wed, 19 Jan 2011 23:30:02 -0000 >>>>> "Jim" == Jim Schaad writes: We're talking about various SAML exchanges defined to support SOAP over HTTP. Basically, when we've been talking about SOAP we're using that as shorthand for the SAML profiles for an SP talking to an IDP that exist today. We're arguing about the balance between our AAA transport and the existing transport and what should be used when why by whom. From ietf@augustcellars.com Wed Jan 19 16:31:46 2011 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 8707128C131; Wed, 19 Jan 2011 16:31:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.566 X-Spam-Level: X-Spam-Status: No, score=-2.566 tagged_above=-999 required=5 tests=[AWL=0.033, 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 SJtHeQJ17r1v; Wed, 19 Jan 2011 16:31:45 -0800 (PST) Received: from smtp2.pacifier.net (smtp2.pacifier.net [64.255.237.172]) by core3.amsl.com (Postfix) with ESMTP id A1F8028C130; Wed, 19 Jan 2011 16:31:44 -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 61E3B6A46F; Wed, 19 Jan 2011 16:34:25 -0800 (PST) From: "Jim Schaad" To: "'Sam Hartman'" , , References: In-Reply-To: Date: Wed, 19 Jan 2011 16:06:01 -0800 Message-ID: <015601cbb83c$5a487e40$0ed97ac0$@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: AQEc8ihovdZ5DbuDGptHOYErkbr+GJU2gAiQ Content-Language: en-us Subject: Re: [abfab] Multiple attribute providers in an authentication 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, 20 Jan 2011 00:31:46 -0000 Sam Comments in line. > -----Original Message----- > From: abfab-bounces@ietf.org [mailto:abfab-bounces@ietf.org] On Behalf > Of Sam Hartman > Sent: Monday, January 10, 2011 11:18 AM > To: abfab@ietf.org; kitten@ietf.org > Subject: [abfab] Multiple attribute providers in an authentication > > > Background: there was a discussion between authors of the abfab > architecture proposal about multiple attribute providers. > The idea is that you have an identity provider that is producing a set of > attributes about a subject. In the case of ABFAB we're mostly thinking of a > SAML IDP for this particular example. > > The IDP has some attributes it may be in a position to assert. > But the IDP may also want to gather attributes from other sources and pass > those along. > > One option it has is to simply pass the attributes along as if it issued them > itself. That option isn't really interesting from a protocol standpoint because > it is indistinguishable from the IDP actually issuing the attribute itself. That is > probably a fine thing to do in certain deployments but we don't need to > spend a lot of time on it. > > Another option is that the IDP can go actually get a SAML assertion (or > attribute certificate or the like) and include that in what is sent to the RP. > > At first glance, the protocol implications of doing this look simple. You just > stick the assertion in the existing bag of bits and move on. > > however, it's not that simple because of semantics. > > Today in ABFAB, we haven't done a great job of describing what the trust > semantics of the attribute in draft-ietf-abfab-aaa-saml are. However what > has been going through at least Josh and my mind is that the RP SHOULD > assume that the AAA framework provides an integrity protected channel for > that SAML message. The message is actually issued by the IDP corresponding > to the NAI used to make the access request. In addition, for the SAML > assertions sent from the IDP to the RP, the RP SHOULD assume that the IDP > is asserting those attributes about the subject. Would you consider it to be permissible for an intermediate to re-write the assertions to change the framework they are being made in from the IdP's home network to the federation network's framework? This would say that they may not have quite the same degree of integrity protection as might be initially assumed. > That is, the RP need not perform any validation of the SAML assertion. The > RP still needs to validate whether the IDP is permitted to make the claims it > does. > There's no requirement that these SAML assertions be signed. > The IDP MAY sign the assertion; the RP MAY consider any signatures that are > present. However in the interoperable case, any signatures that are present > are ignored. > > If there are multiple assertions from the same IDP it seems reasonable to > treat them all the same. > > Things get a lot more messy when assertions from multiple IDPs are > included. Are you saying that the principal has multiple names or that they are multiple assertions being made about a single name? > What does it mean to include them in the AAA transport? I can think of > several trust models that are appropriate depending on deployment: > > * The IDP corresponding to the subject's NAI has validated these > additional assertions and wishes to assert that the attributes can be > trusted. "If you trust me then you should trust these." Here, the > assertions are being included either for convenience of packaging the > attributes into some form the RP can process or because it is possible > that the RP may be able to validate some signature and trust the > attribute source more than the IDP. > > * The subject IDP has performed SAML validation on the > assertions. However the IDP is making no claims about how trusted the > attributes included in the additional assertions are. Even if the IDP > would be permitted to make a claim made in an additional assertion, > the RP needs to make an independent policy decision about whether the > actual issuer should be permitted to make that claim. > > * Here are some assertions for the RP's convenience. The IDP makes no > claims about them; not even the implied claim that they have not been > modified in transit. They better be signed, the RP better have > metadata for their issuer, and the RP is more or less on its own. > > Another source of complexity surrounds how an IDP links an assertion to a > subject. What confidence is the RP asserting that the additional assertion > describes the same principal as the access-accept message. > > Another potential source of complexity is how does the IDP know what > information to gather? Does the IDP just know somehow? Does the RP pass > information back? What happens if the naming space of the claims is different between the IDP and the RP? What happens if the additional attributes need to come from a completely different fourth realm? I.e. my name comes from the country of issue, the RP is a bank and the attributes need to come from a university? > > How does the RP make the policy decisions it needs to make? How does it > get metadata that is needed? > > I think this sort of issue will also have impacts for kitten, because we'll need > to describe it in the naming extensions interface. It seems like ABFAB is not > going to be the only group facing these sorts of discussions; Kerberos is in the > middle of a similar discussion right now. I completely agree this is a hard problem that we need to start writing down, if not answers then at least boundaries of the problem. Jim > > _______________________________________________ > abfab mailing list > abfab@ietf.org > https://www.ietf.org/mailman/listinfo/abfab From ietf@augustcellars.com Wed Jan 19 16:32:10 2011 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 2E79028C130 for ; Wed, 19 Jan 2011 16:32:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.567 X-Spam-Level: X-Spam-Status: No, score=-2.567 tagged_above=-999 required=5 tests=[AWL=0.032, 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 IRaeSOIkUndk for ; Wed, 19 Jan 2011 16:32:09 -0800 (PST) Received: from smtp2.pacifier.net (smtp2.pacifier.net [64.255.237.172]) by core3.amsl.com (Postfix) with ESMTP id 59CD828C0CF for ; Wed, 19 Jan 2011 16:32:09 -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 66A2C6A472; Wed, 19 Jan 2011 16:34:26 -0800 (PST) From: "Jim Schaad" To: "'Josh Howlett'" , "'Klaas Wierenga'" , References: <55DC663C2F4F9F439F23543E0078E8B305A4C9@EXC001> <55DC663C2F4F9F439F23543E0078E8B305A7B8@EXC001> <7EE86E89365CA94F8E7B8251F9260710035160@CIO-KRC-D1MBX01.osuad.osu.edu> <7EE86E89365CA94F8E7B8251F92607100351DE@CIO-KRC-D1MBX01.osuad.osu.edu> <7EE86E89365CA94F8E7B8251F9260710035299@CIO-KRC-D1MBX01.osuad.osu.edu> <7EE86E89365CA94F8E7B8251F92607100352B9@CIO-KRC-D1MBX01.osuad.osu.edu> <7EE86E89365CA94F8E7B8251F926071003532C@CIO-KRC-D1MBX01.osuad.osu.edu> <4D3406DF.2050106@sunet.se> <55DC663C2F4F9F439F23543E0078E8B30779F3@EXC001> <55DC663C2F4F9F439F23543E0078E8B307F21D@EXC001> <4D35BD33.2050608@cisco.com> <55DC663C2F4F9F439F23543E0078E8B307F26F@EXC001> In-Reply-To: <55DC663C2F4F9F439F23543E0078E8B307F26F@EXC001> Date: Wed, 19 Jan 2011 16:52:46 -0800 Message-ID: <015701cbb83c$64190160$2c4b0420$@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: AQKD60stnoWjdz0NkrMtrJXHfL4ciwKxD9vuAMfO88kClnQ37gGYv/TnAkmF49IB5PdJPwIOiG1FAfXMuPQB8xuKIwHJJiLqAotxIrICjQdvcwGjo2UDAuUekuoBsKyUTQE5t/gjAdDGd7yRWPhqwA== Content-Language: en-us Subject: Re: [abfab] Proposed changes to draft-ieft-abfab-aaa-saml 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, 20 Jan 2011 00:32:10 -0000 > -----Original Message----- > From: abfab-bounces@ietf.org [mailto:abfab-bounces@ietf.org] On Behalf > Of Josh Howlett > Sent: Tuesday, January 18, 2011 8:21 AM > To: Klaas Wierenga; abfab@ietf.org > Cc: Josh Howlett > Subject: Re: [abfab] Proposed changes to draft-ieft-abfab-aaa-saml > > > > e.g. say we specify the "saml-20-aa" name to mean a SAML 2.0 > > attribute authority. An SP wanting to route a message to this actor to > > example.com prefixes the realm of the intended Issuer with this, thus > > "saml-20-aa.example.com". The AAA SAML attribute within this request > > message contains a SAML Request message containing the identifier for > > the subject. > > > > ehrm, that means there can only be one AA per realm? > > If that matters, I think you could have multiple AAs and disambiguate by > extending the naming semantics of the NAI. But the different AAs may be authorative for different statements for the same individuals. This does not help. Jim > > 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 Oxford, Didcot, > Oxfordshire. OX11 0SG > > _______________________________________________ > abfab mailing list > abfab@ietf.org > https://www.ietf.org/mailman/listinfo/abfab From ietf@augustcellars.com Wed Jan 19 16:32:13 2011 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 2CC4128C139 for ; Wed, 19 Jan 2011 16:32:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.568 X-Spam-Level: X-Spam-Status: No, score=-2.568 tagged_above=-999 required=5 tests=[AWL=0.031, 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 Vi2MFMzKOJ0t for ; Wed, 19 Jan 2011 16:32:12 -0800 (PST) Received: from smtp2.pacifier.net (smtp2.pacifier.net [64.255.237.172]) by core3.amsl.com (Postfix) with ESMTP id EF0D928C138 for ; Wed, 19 Jan 2011 16:32:11 -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 6829F6A46F for ; Wed, 19 Jan 2011 16:34:52 -0800 (PST) From: "Jim Schaad" To: Date: Wed, 19 Jan 2011 16:52:46 -0800 Message-ID: <015e01cbb83c$6aa99bc0$3ffcd340$@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: Acu3gNkYBBGjay8lTTCqx5iCf00LhQ== Content-Language: en-us Subject: [abfab] Comments on draft-lear-abfab-arch-01 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, 20 Jan 2011 00:32:13 -0000 Let's see how far I can demonstrate my lack of understanding. It seems to me to be a good way to figure out if there are problems with the document. The mailing list may have addressed some of these issues, I am just now catching up on it. Jim In section 1.1 Current: Some deployments may be required to deploy message routing intermediaries Suggested: Some instantiations may be required to deploy message routing intermediaries The expansion of NAI needs to be moved forward in the document. In step 2 A couple of questions come to mind here - which authentication mechanism are selecting? The End Host to IdP or the End Host to the Relying Part? Are there any options here or is there only a single possibility? In Step 3 For various reasons, I think one will want to establish a secure link to from the Client Application to the RP either before - or as - it is supplying the NAI to the RP. It might however been that you are really only saying that you are sending the realm portion of the NAI to the RP. That would be a different story, but you may still want to get some type of secure link. Note to self - in step 5 what is the security on the RP claim of identity In Step 7 You say that it happens between the endpoints - but the endpoints are not defined in this case. I believe you actually mean the IdP and the Principal but there are other endpoints it could be. In Step 8 I have a complete lack of understanding of the last sentence of this section. I don't have any idea of how this statement follows from the preceding. I can see it as saying that the IdP will know that the Principal and it are authenticated to the same RP. Section 3.1 - in Paragraph 3 - It specifies that we are going to put the NAI in the GSS_C_NT_USER_NAME field of GSS-API, is it going to be the responsibility of the GSS-API layer to fragment the realm portion of name from the full NAI depending on if it is talking to the RP or the IdP? There is no mention in this section that there may be multiple IdPs for a single realm that could be used by the RP and the selection of which IdP it wants to use is going to be based on the set of attributes that the RP needs or a level of authentication that is required by the RP (see [sp800-63-1] NIST SP 800-63-1 "Electronic Authentication Guideline", December 2008 as examples). Section 3.2 Has the sentences " Aside from a valuable secret being exposed, a synchronization problem can also often develop. Since there is no single authentication mechanism that will be used everywhere there is another associated requirement:" I have a couple of issues here. First there is a problem which is stated - i.e. synchronization - but the next sentence does not appear to expand on the problem but rather deals with a different issue. I would like to have the first thought finished before going onto the second one. I think this paragraph is supposed to be talking about issues that we have been taught - but the word Since does not convey this is a separate issue we have dealing with. In the sentence "through the authenticator (i.e., service provider)" - s/service provider/relying party/ Section 3.5 In this picture - I believe that it would be more accurate to have the EAP stream go directly through the Federation layer - this would not be routed as it is E2E. Also it might make sense to have it wrap through the Server Side box. Section 4.3 Given that you have stated that we are going to use the Kerberos realm naming, on which I have no opinion, I think that there should be some text about how the end host is going to make a decision that it is talking to the correct RP to begin with. It does not have any pre-existing security relationship with the realm of the RP. Additional Issues: 1. The document is currently written in terms of dealing with an Identity provider, and I can understand why that is so as without an identity not much will happen. However it seems to me that there is also a desire to be able to talk to an attribute service in much the same way. However it is not clear that there is a need for the End Host to talk to the attribute provider - that communication should be thought of as passing between the IdP, the RP and the AtP. The IdP may need to get a different or better identity proof as part of that conversation. 2. I am not sure if there needs to be a discussion on what needs to be a part of a federation agreement. One of the issues that I can see as being troublesome as it does not seem to be vastly expandable is the question of what makes for an equivalent statement. Is it to be expected that the SASL statements are going to be made in terms of the federation agreement attributes, or does there need to be available to the RP some type of mapping statement? From hartmans@painless-security.com Wed Jan 19 17:15:35 2011 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 3119328C0FF; Wed, 19 Jan 2011 17:15:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.285 X-Spam-Level: X-Spam-Status: No, score=-2.285 tagged_above=-999 required=5 tests=[AWL=-0.020, 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 GwFxVKsAM-JG; Wed, 19 Jan 2011 17:15:34 -0800 (PST) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by core3.amsl.com (Postfix) with ESMTP id 1D20F3A7200; Wed, 19 Jan 2011 17:15: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 D34E52029B; Wed, 19 Jan 2011 20:16:28 -0500 (EST) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id B2C63432C; Wed, 19 Jan 2011 20:18:07 -0500 (EST) From: Sam Hartman To: "Jim Schaad" References: <015601cbb83c$5a487e40$0ed97ac0$@augustcellars.com> Date: Wed, 19 Jan 2011 20:18:07 -0500 In-Reply-To: <015601cbb83c$5a487e40$0ed97ac0$@augustcellars.com> (Jim Schaad's message of "Wed, 19 Jan 2011 16:06:01 -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: kitten@ietf.org, abfab@ietf.org Subject: Re: [abfab] Multiple attribute providers in an authentication 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, 20 Jan 2011 01:15:35 -0000 >>>>> "Jim" == Jim Schaad writes: Jim> Would you consider it to be permissible for an intermediate to Jim> re-write the assertions to change the framework they are being Jim> made in from the IdP's home network to the federation network's Jim> framework? This would say that they may not have quite the Jim> same degree of integrity protection as might be initially Jim> assumed. AAA integrity is hop-by-hop. I don't think we'll have technical mechanisms in some deployments to prevent this. In some cases (draft-howlett-radsec-kmp springs to mind) it might be fairly tricky to do that. I don't think we've discussed the role of intermediates much. I can think of several models including: * Intermediates are good and need to be permitted to muck about. * When intermediates can muck about it's OK for them to do so. * Intermediates must not muck about; future deployment and other mechanisms may restrict their ability to do so more than is restricted today. We have not discussed a lot what the answer is. In some of the work Josh and I did we ran into a number of cases where having the intermediates be able to examine the information passing through has been quite valuable. (We typically found that out when we designed a mechanism to short-circuit some intermediate and then ended up adding a lot of complexity to get the intermediate some information.) Similarly in discussions at the Kerberos Consortium conference this fall, several people believed that having an organizational policy intermediate near the RP would be valuable. (In that community they believed a KDC would be a great place to put such an intermediate.) >> That is, the RP need not perform any validation of the SAML >> assertion. The RP still needs to validate whether the IDP is >> permitted to make the claims Jim> it >> does. There's no requirement that these SAML assertions be >> signed. The IDP MAY sign the assertion; the RP MAY consider any >> signatures that Jim> are >> present. However in the interoperable case, any signatures that >> are Jim> present >> are ignored. >> >> If there are multiple assertions from the same IDP it seems >> reasonable to treat them all the same. >> >> Things get a lot more messy when assertions from multiple IDPs >> are included. Jim> Are you saying that the principal has multiple names or that Jim> they are multiple assertions being made about a single name? Both. I'm assuming all the assertions are about the same subject/principal, but that entity may be known by multiple names. Someone needs to actually make sure that all the assertions are about the same subject. That is quite tricky. >> Another source of complexity surrounds how an IDP links an >> assertion to a subject. What confidence is the RP asserting that >> the additional assertion describes the same principal as the >> access-accept message. >> >> Another potential source of complexity is how does the IDP know >> what information to gather? Does the IDP just know somehow? Does >> the RP pass information back? Jim> What happens if the naming space of the claims is different Jim> between the IDP and the RP? To the extent that problem exists, I think it is independent of whether multiple attribute provders or one attribute provider is involved. I think we're defining the use of NAIs as a way to have a common name space between the RP and the first IDP. That is, the AAA federation substrate for abfab needs to provide some naming services to guarantee that we have a common namespace between the RP and IDP. Jim> What happens if the additional attributes need to come from a Jim> completely different fourth realm? I.e. my name comes from the Jim> country of issue, the RP is a bank and the attributes need to Jim> come from a university? *this* is the first point I was getting at in the paragraph from my original message. I consider this situation complicated. Jim> I completely agree this is a hard problem that we need to start Jim> writing down, if not answers then at least boundaries of the Jim> problem. Yes. I and as I understand it Moonshot don't need to solve this problem to make forward progress. I think building some walls around the problem and starting to understand where it is is valuable. However until someone steps forward and wants to spend (or fund) significant cycles on this, I don't think we will solve it. From hartmans@painless-security.com Wed Jan 19 17:16:50 2011 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 29AC83A7204 for ; Wed, 19 Jan 2011 17:16:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.284 X-Spam-Level: X-Spam-Status: No, score=-2.284 tagged_above=-999 required=5 tests=[AWL=-0.019, 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 0uUzwwtjQbaZ for ; Wed, 19 Jan 2011 17:16:49 -0800 (PST) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by core3.amsl.com (Postfix) with ESMTP id 661403A7201 for ; Wed, 19 Jan 2011 17:16: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 62FCD202A2; Wed, 19 Jan 2011 20:17:46 -0500 (EST) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id F0882432C; Wed, 19 Jan 2011 20:19:25 -0500 (EST) From: Sam Hartman To: "Jim Schaad" References: <55DC663C2F4F9F439F23543E0078E8B305A4C9@EXC001> <55DC663C2F4F9F439F23543E0078E8B305A7B8@EXC001> <7EE86E89365CA94F8E7B8251F9260710035160@CIO-KRC-D1MBX01.osuad.osu.edu> <7EE86E89365CA94F8E7B8251F92607100351DE@CIO-KRC-D1MBX01.osuad.osu.edu> <7EE86E89365CA94F8E7B8251F9260710035299@CIO-KRC-D1MBX01.osuad.osu.edu> <7EE86E89365CA94F8E7B8251F92607100352B9@CIO-KRC-D1MBX01.osuad.osu.edu> <7EE86E89365CA94F8E7B8251F926071003532C@CIO-KRC-D1MBX01.osuad.osu.edu> <4D3406DF.2050106@sunet.se> <55DC663C2F4F9F439F23543E0078E8B30779F3@EXC001> <55DC663C2F4F9F439F23543E0078E8B307F21D@EXC001> <4D35BD33.2050608@cisco.com> <55DC663C2F4F9F439F23543E0078E8B307F26F@EXC001> <015701cbb83c$64190160$2c4b0420$@augustcellars.com> Date: Wed, 19 Jan 2011 20:19:25 -0500 In-Reply-To: <015701cbb83c$64190160$2c4b0420$@augustcellars.com> (Jim Schaad's message of "Wed, 19 Jan 2011 16:52:46 -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: 'Josh Howlett' , abfab@ietf.org Subject: Re: [abfab] Proposed changes to draft-ieft-abfab-aaa-saml 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, 20 Jan 2011 01:16:50 -0000 >>>>> "Jim" == Jim Schaad writes: >> -----Original Message----- From: abfab-bounces@ietf.org >> [mailto:abfab-bounces@ietf.org] On Behalf Of Josh Howlett Sent: >> Tuesday, January 18, 2011 8:21 AM To: Klaas Wierenga; >> abfab@ietf.org Cc: Josh Howlett Subject: Re: [abfab] Proposed >> changes to draft-ieft-abfab-aaa-saml >> >> > > e.g. say we specify the "saml-20-aa" name to mean a SAML 2.0 >> > attribute authority. An SP wanting to route a message to this >> actor to > example.com prefixes the realm of the intended Issuer >> with this, thus > "saml-20-aa.example.com". The AAA SAML >> attribute within this request > message contains a SAML Request >> message containing the identifier for > the subject. >> > >> > ehrm, that means there can only be one AA per realm? >> >> If that matters, I think you could have multiple AAs and >> disambiguate by extending the naming semantics of the NAI. Jim> But the different AAs may be authorative for different Jim> statements for the same individuals. This does not help. I think Josh was proposing ways of naming AAs. Why does that not help? From hartmans@painless-security.com Wed Jan 19 17:31:27 2011 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 16F8128C147 for ; Wed, 19 Jan 2011 17:31:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.284 X-Spam-Level: X-Spam-Status: No, score=-2.284 tagged_above=-999 required=5 tests=[AWL=-0.019, 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 7X5F3q3V8uKv for ; Wed, 19 Jan 2011 17:31:26 -0800 (PST) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by core3.amsl.com (Postfix) with ESMTP id 0F26928C138 for ; Wed, 19 Jan 2011 17:31:25 -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 E4ABD20246; Wed, 19 Jan 2011 20:32:21 -0500 (EST) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 91C1B432C; Wed, 19 Jan 2011 20:34:00 -0500 (EST) From: Sam Hartman To: "Jim Schaad" References: <015e01cbb83c$6aa99bc0$3ffcd340$@augustcellars.com> Date: Wed, 19 Jan 2011 20:34:00 -0500 In-Reply-To: <015e01cbb83c$6aa99bc0$3ffcd340$@augustcellars.com> (Jim Schaad's message of "Wed, 19 Jan 2011 16:52:46 -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] Comments on draft-lear-abfab-arch-01 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, 20 Jan 2011 01:31:27 -0000 >>>>> "Jim" == Jim Schaad writes: Jim> In step 2 A couple of questions come to mind here - which Jim> authentication mechanism are selecting? The End Host to IdP or Jim> the End Host to the Relying Part? Are there any options here Jim> or is there only a single possibility? There is no authentication of the end-host to the RP. The end-host authenticates to the IDP. There is a key confirmation step where the end-host and RP prove they have the same session key. In some sense, that performs an authentication function; it definitely binds the RP->IDP authentication with the end-host->IDP authentication. Jim> In Step 3 For various reasons, I think one will want to Jim> establish a secure link to from the Client Application to the Jim> RP either before - or as - it is supplying the NAI to the RP. Jim> It might however been that you are really only saying that you Jim> are sending the realm portion of the NAI to the RP. That would Jim> be a different story, but you may still want to get some type Jim> of secure link. You're typically only sending the realm portion if your EAP method uses privacy identifiers (the good ones do). A secure link to the RP at this stage is out of scope for a GSS substrate for abfab in my opinion. It adds a lot of mess, and there are better ways of doing most of what you are probably trying to do. Also, note that since the end-host has no credential for the RP, and this is a huge feature of the architecture, your options are limited. Jim> Section 3.1 - in Paragraph 3 - It specifies that we are going Jim> to put the NAI in the GSS_C_NT_USER_NAME field of GSS-API, is Jim> it going to be the responsibility of the GSS-API layer to Jim> fragment the realm portion of name from the full NAI depending Jim> on if it is talking to the RP or the IdP? Um. I think you're a bit confused about what role GSS-API fills here. The NAI is an input to the GSS-API, which locally on the end-host feeds it to a specific EAP method. That method will hide it if that method hides identity. Jim> There is no mention in this section that there may be multiple Jim> IdPs for a single realm that could be used by the RP and the Jim> selection of which IdP it wants to use is going to be based on Jim> the set of attributes that the RP needs or a level of Jim> authentication that is required by the RP (see [sp800-63-1] Jim> NIST SP 800-63-1 "Electronic Authentication Guideline", Jim> December 2008 as examples). True, basically because there's no existing protocol mechanism to accomplish the end-host finding out what the RP wants. This is kind of a GSS failing; there is some Microsoft work that could expand GSS in some ways. Abfab can take advantage of this whenever GSS gains the feature. I think I have an action item to discuss federation and IDP selection (although someone else may have the action item for IDP selection--can't remember). However it's more going to be about future extensions and directions for expansion. Jim> Section 3.2 Has the sentences " Aside from a valuable secret Jim> being exposed, a synchronization problem can also often Jim> develop. Since there is no single authentication mechanism Jim> that will be used everywhere there is another associated Jim> requirement:" I have a couple of issues here. First there is a Jim> problem which is stated - i.e. synchronization - but the next Jim> sentence does not appear to expand on the problem but rather Jim> deals with a different issue. I would like to have the first Jim> thought finished before going onto the second one. I think Jim> this paragraph is supposed to be talking about issues that we Jim> have been taught - but the word Since does not convey this is a Jim> separate issue we have dealing with. Help with wording would be greatly appreciated here. Jim> In the sentence "through the authenticator (i.e., service Jim> provider)" - s/service provider/relying party/ Jim> Section 3.5 In this picture - I believe that it would be more Jim> accurate to have the EAP stream go directly through the Jim> Federation layer - this would not be routed as it is E2E. No, I think the EAP stream is routed. Just as TLS is routed over IP. Jim> Section 4.3 Given that you have stated that we are going to use Jim> the Kerberos realm naming, on which I have no opinion, I think Jim> that there should be some text about how the end host is going Jim> to make a decision that it is talking to the correct RP to Jim> begin with. It does not have any pre-existing security Jim> relationship with the realm of the RP. It kind of needs to trust the RP for some of this. It needs to derive a name for the RP from input it gets from the user or a trusted referral. Then, the IDP and some proxy goo is responsible for making sure that the RP it is talking to is the RP it names. Jim> Additional Issues: Jim> 1. The document is currently written in terms of dealing with Jim> an Identity provider, and I can understand why that is so as Jim> without an identity not much will happen. However it seems to Jim> me that there is also a desire to be able to talk to an Jim> attribute service in much the same way. However it is not Jim> clear that there is a need for the End Host to talk to the Jim> attribute provider - that communication should be thought of as Jim> passing between the IdP, the RP and the AtP. The IdP may need Jim> to get a different or better identity proof as part of that Jim> conversation. Hmm. Jim> 2. I am not sure if there needs to be a discussion on what Jim> needs to be a part of a federation agreement. One of the Jim> issues that I can see as being troublesome as it does not seem Jim> to be vastly expandable is the question of what makes for an Jim> equivalent statement. Is it to be expected that the SASL Jim> statements are going to be made in terms of the federation Jim> agreement attributes, or does there need to be available to the Jim> RP some type of mapping statement? I hope we can avoid discussions of what goes in a federation agreement. From ietf@augustcellars.com Wed Jan 19 17:32:10 2011 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 A4FC928C144 for ; Wed, 19 Jan 2011 17:32:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.57 X-Spam-Level: X-Spam-Status: No, score=-2.57 tagged_above=-999 required=5 tests=[AWL=0.029, 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 WJtXG2LA7Ay8 for ; Wed, 19 Jan 2011 17:32:09 -0800 (PST) Received: from new-smtp01.pacifier.net (new-smtp01.pacifier.net [64.255.237.177]) by core3.amsl.com (Postfix) with ESMTP id 8F7F428C138 for ; Wed, 19 Jan 2011 17:32:09 -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 EC7312CA52; Wed, 19 Jan 2011 17:34:50 -0800 (PST) From: "Jim Schaad" To: "'Sam Hartman'" References: <4D10F279.3030601@cisco.com> <4D2AEE2A.1080808@cisco.com> <015501cbb831$bc840cb0$358c2610$@augustcellars.com> In-Reply-To: Date: Wed, 19 Jan 2011 17:53:11 -0800 Message-ID: <016d01cbb844$cb6b87e0$624297a0$@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: AQIjQuKbZ+gCK9OCb+PYvsteFk6r7AHNoxy4AZSyxXQCKDvd4QFABHANkvOuw8A= Content-Language: en-us Cc: abfab@ietf.org Subject: Re: [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: Thu, 20 Jan 2011 01:32:10 -0000 > -----Original Message----- > From: Sam Hartman [mailto:hartmans@painless-security.com] > Sent: Wednesday, January 19, 2011 3:33 PM > To: Jim Schaad > Cc: 'Klaas Wierenga'; abfab@ietf.org > Subject: Re: [abfab] draft-lear-abfab-arch-01 posted > > >>>>> "Jim" == Jim Schaad writes: > > We're talking about various SAML exchanges defined to support SOAP over > HTTP. Basically, when we've been talking about SOAP we're using that as > shorthand for the SAML profiles for an SP talking to an IDP that exist today. > > We're arguing about the balance between our AAA transport and the > existing transport and what should be used when why by whom. I agree that SOAP over HTTP is the most common, but it is not the only binding that exists. It would be potentially useful for me to be able to send SOAP messages over DIAMETER at some point in the future. So for me the distinction between the message format and the transport is a useful distinction. Jim From hartmans@painless-security.com Wed Jan 19 17:34:15 2011 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 D58E328C138 for ; Wed, 19 Jan 2011 17:34:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.283 X-Spam-Level: X-Spam-Status: No, score=-2.283 tagged_above=-999 required=5 tests=[AWL=-0.018, 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 8r9YOGqIol4n for ; Wed, 19 Jan 2011 17:34:15 -0800 (PST) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by core3.amsl.com (Postfix) with ESMTP id 0C5D128C123 for ; Wed, 19 Jan 2011 17:34:15 -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 0129620222; Wed, 19 Jan 2011 20:35:12 -0500 (EST) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 7503E432C; Wed, 19 Jan 2011 20:36:50 -0500 (EST) From: Sam Hartman To: "Jim Schaad" References: <4D10F279.3030601@cisco.com> <4D2AEE2A.1080808@cisco.com> <015501cbb831$bc840cb0$358c2610$@augustcellars.com> <016d01cbb844$cb6b87e0$624297a0$@augustcellars.com> Date: Wed, 19 Jan 2011 20:36:50 -0500 In-Reply-To: <016d01cbb844$cb6b87e0$624297a0$@augustcellars.com> (Jim Schaad's message of "Wed, 19 Jan 2011 17:53:11 -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] 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: Thu, 20 Jan 2011 01:34:16 -0000 >>>>> "Jim" == Jim Schaad writes: >> -----Original Message----- From: Sam Hartman >> [mailto:hartmans@painless-security.com] Sent: Wednesday, January >> 19, 2011 3:33 PM To: Jim Schaad Cc: 'Klaas Wierenga'; >> abfab@ietf.org Subject: Re: [abfab] draft-lear-abfab-arch-01 >> posted >> >> >>>>> "Jim" == Jim Schaad writes: >> >> We're talking about various SAML exchanges defined to support >> SOAP over HTTP. Basically, when we've been talking about SOAP >> we're using that as shorthand for the SAML profiles for an SP >> talking to an IDP that exist Jim> today. >> >> We're arguing about the balance between our AAA transport and the >> existing transport and what should be used when why by whom. Jim> I agree that SOAP over HTTP is the most common, but it is not Jim> the only binding that exists. It would be potentially useful Jim> for me to be able to send SOAP messages over DIAMETER at some Jim> point in the future. So for me the distinction between the Jim> message format and the transport is a useful distinction. I'm not aware of a SAML binding for SOAP over diameter. As far as ABFAB is concerned the real question is whether ABFAB is defining the transport or whether you are using an existing SAML binding. --Sam From ietf@augustcellars.com Wed Jan 19 17:57:50 2011 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 047DC28C117 for ; Wed, 19 Jan 2011 17:57:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.571 X-Spam-Level: X-Spam-Status: No, score=-2.571 tagged_above=-999 required=5 tests=[AWL=0.028, 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 MXdQ33Ze85uK for ; Wed, 19 Jan 2011 17:57:49 -0800 (PST) Received: from new-smtp01.pacifier.net (new-smtp01.pacifier.net [64.255.237.177]) by core3.amsl.com (Postfix) with ESMTP id 3264C3A700F for ; Wed, 19 Jan 2011 17:57:49 -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 7B9352CA34; Wed, 19 Jan 2011 18:00:29 -0800 (PST) From: "Jim Schaad" To: "'Sam Hartman'" References: <55DC663C2F4F9F439F23543E0078E8B305A4C9@EXC001> <55DC663C2F4F9F439F23543E0078E8B305A7B8@EXC001> <7EE86E89365CA94F8E7B8251F9260710035160@CIO-KRC-D1MBX01.osuad.osu.edu> <7EE86E89365CA94F8E7B8251F92607100351DE@CIO-KRC-D1MBX01.osuad.osu.edu> <7EE86E89365CA94F8E7B8251F9260710035299@CIO-KRC-D1MBX01.osuad.osu.edu> <7EE86E89365CA94F8E7B8251F92607100352B9@CIO-KRC-D1MBX01.osuad.osu.edu> <7EE86E89365CA94F8E7B8251F926071003532C@CIO-KRC-D1MBX01.osuad.osu.edu> <4D3406DF.2050106@sunet.se> <55DC663C2F4F9F439F23543E0078E8B30779F3@EXC001> <55DC663C2F4F9F439F23543E0078E8B307F21D@EXC001> <4D35BD33.2050608@cisco.com> <55DC663C2F4F9F439F23543E0078E8B307F26F@EXC001> <015701cbb83c$64190160$2c4b0420$@augustcellars.com> In-Reply-To: Date: Wed, 19 Jan 2011 18:18:42 -0800 Message-ID: <016e01cbb848$6119d4b0$234d7e10$@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: AQKD60stnoWjdz0NkrMtrJXHfL4ciwKxD9vuAMfO88kClnQ37gGYv/TnAkmF49IB5PdJPwIOiG1FAfXMuPQB8xuKIwHJJiLqAotxIrICjQdvcwGjo2UDAuUekuoBsKyUTQE5t/gjAdDGd7wB9JxMZAHdJCt4kTqPMKA= Content-Language: en-us Cc: 'Josh Howlett' , abfab@ietf.org Subject: Re: [abfab] Proposed changes to draft-ieft-abfab-aaa-saml 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, 20 Jan 2011 01:57:50 -0000 > -----Original Message----- > From: Sam Hartman [mailto:hartmans@painless-security.com] > Sent: Wednesday, January 19, 2011 5:19 PM > To: Jim Schaad > Cc: 'Josh Howlett'; 'Klaas Wierenga'; abfab@ietf.org > Subject: Re: [abfab] Proposed changes to draft-ieft-abfab-aaa-saml > > >>>>> "Jim" == Jim Schaad writes: > > >> -----Original Message----- From: abfab-bounces@ietf.org > >> [mailto:abfab-bounces@ietf.org] On Behalf Of Josh Howlett Sent: > >> Tuesday, January 18, 2011 8:21 AM To: Klaas Wierenga; > >> abfab@ietf.org Cc: Josh Howlett Subject: Re: [abfab] Proposed > >> changes to draft-ieft-abfab-aaa-saml > >> > >> > > e.g. say we specify the "saml-20-aa" name to mean a SAML 2.0 > >> > attribute authority. An SP wanting to route a message to this > >> actor to > example.com prefixes the realm of the intended Issuer > >> with this, thus > "saml-20-aa.example.com". The AAA SAML > >> attribute within this request > message contains a SAML Request > >> message containing the identifier for > the subject. > >> > > >> > ehrm, that means there can only be one AA per realm? > >> > >> If that matters, I think you could have multiple AAs and > >> disambiguate by extending the naming semantics of the NAI. > > Jim> But the different AAs may be authorative for different > Jim> statements for the same individuals. This does not help. > > I think Josh was proposing ways of naming AAs. > > Why does that not help? I thought that he was given an example of uniform name of an attribute authority, as oppose to suggesting that there might be different names. But that also implies that you need to be able to query as to which of the different authorities you need to query in order to get the attributes you care about. Even more issues of attribute name and quality matching to be dealt with. Jim From Josh.Howlett@ja.net Thu Jan 20 01:59:42 2011 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 10D3D3A6FB7 for ; Thu, 20 Jan 2011 01:59:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.468 X-Spam-Level: X-Spam-Status: No, score=-102.468 tagged_above=-999 required=5 tests=[AWL=0.131, 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 qHpueezNPI+l for ; Thu, 20 Jan 2011 01:59:41 -0800 (PST) Received: from har003676.ukerna.ac.uk (har003676.ukerna.ac.uk [194.82.140.75]) by core3.amsl.com (Postfix) with ESMTP id 387913A6DA2 for ; Thu, 20 Jan 2011 01:59:41 -0800 (PST) Received: from har003676.ukerna.ac.uk (localhost.localdomain [127.0.0.1]) by localhost (Email Security Appliance) with SMTP id 895E34A6B3C_D38082EB; Thu, 20 Jan 2011 10:02:22 +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 78B884A6B60_D38082CF; Thu, 20 Jan 2011 10:02:20 +0000 (GMT) Received: from EXC001.atlas.ukerna.ac.uk ([193.62.83.37]) by EXC001 ([193.62.83.37]) with mapi id 14.01.0218.012; Thu, 20 Jan 2011 10:02:33 +0000 From: Josh Howlett To: Jim Schaad , 'Sam Hartman' Thread-Topic: [abfab] draft-lear-abfab-arch-01 posted Thread-Index: AQHLoT1Ze3iKLilXkEaBdn1JxzBPzJPZIAzVgAAnDoCAAIMmkA== Date: Thu, 20 Jan 2011 10:02:32 +0000 Message-ID: <55DC663C2F4F9F439F23543E0078E8B308A438@EXC001> References: <4D10F279.3030601@cisco.com> <4D2AEE2A.1080808@cisco.com> <015501cbb831$bc840cb0$358c2610$@augustcellars.com> <016d01cbb844$cb6b87e0$624297a0$@augustcellars.com> In-Reply-To: <016d01cbb844$cb6b87e0$624297a0$@augustcellars.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [194.82.140.76] 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] 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: Thu, 20 Jan 2011 09:59:42 -0000 > > We're arguing about the balance between our AAA transport and the > > existing transport and what should be used when why by whom. >=20 > I agree that SOAP over HTTP is the most common, but it is not the only > binding that exists. It would be potentially useful for me to be able > to send SOAP messages over DIAMETER at some point in the future. So for > me the distinction between the message format and the transport is a usef= ul > distinction. Jim, I don't believe that Abfab itself requires SOAP messaging. But what's = your use-case? Josh. JANET(UK) is a trading name of The JNT Association, a company limited by guarantee which is registered in England under No. 2881024=20 and whose Registered Office is at Lumen House, Library Avenue, Harwell Oxford, Didcot, Oxfordshire. OX11 0SG From Josh.Howlett@ja.net Thu Jan 20 02:12:43 2011 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 C5BF73A721F for ; Thu, 20 Jan 2011 02:12:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.473 X-Spam-Level: X-Spam-Status: No, score=-102.473 tagged_above=-999 required=5 tests=[AWL=0.126, 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 0rZrKOnbkjd5 for ; Thu, 20 Jan 2011 02:12:42 -0800 (PST) Received: from har003676.ukerna.ac.uk (har003676.ukerna.ac.uk [194.82.140.75]) by core3.amsl.com (Postfix) with ESMTP id DC2FE3A7219 for ; Thu, 20 Jan 2011 02:12:38 -0800 (PST) Received: from har003676.ukerna.ac.uk (localhost.localdomain [127.0.0.1]) by localhost (Email Security Appliance) with SMTP id 30DD24A6B3C_D380B39B; Thu, 20 Jan 2011 10:15:21 +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 116544A6B3B_D380B36F; Thu, 20 Jan 2011 10:15:18 +0000 (GMT) Received: from EXC001.atlas.ukerna.ac.uk ([193.62.83.37]) by EXC001 ([193.62.83.37]) with mapi id 14.01.0218.012; Thu, 20 Jan 2011 10:15:37 +0000 From: Josh Howlett To: Jim Schaad , 'Sam Hartman' Thread-Topic: [abfab] Proposed changes to draft-ieft-abfab-aaa-saml Thread-Index: AQHLuEATIyHwctNWOUmE/oDJ1svZrpPZIDYAgACBqCA= Date: Thu, 20 Jan 2011 10:15:36 +0000 Message-ID: <55DC663C2F4F9F439F23543E0078E8B308A460@EXC001> References: <55DC663C2F4F9F439F23543E0078E8B305A4C9@EXC001> <55DC663C2F4F9F439F23543E0078E8B305A7B8@EXC001> <7EE86E89365CA94F8E7B8251F9260710035160@CIO-KRC-D1MBX01.osuad.osu.edu> <7EE86E89365CA94F8E7B8251F92607100351DE@CIO-KRC-D1MBX01.osuad.osu.edu> <7EE86E89365CA94F8E7B8251F9260710035299@CIO-KRC-D1MBX01.osuad.osu.edu> <7EE86E89365CA94F8E7B8251F92607100352B9@CIO-KRC-D1MBX01.osuad.osu.edu> <7EE86E89365CA94F8E7B8251F926071003532C@CIO-KRC-D1MBX01.osuad.osu.edu> <4D3406DF.2050106@sunet.se> <55DC663C2F4F9F439F23543E0078E8B30779F3@EXC001> <55DC663C2F4F9F439F23543E0078E8B307F21D@EXC001> <4D35BD33.2050608@cisco.com> <55DC663C2F4F9F439F23543E0078E8B307F26F@EXC001> <015701cbb83c$64190160$2c4b0420$@augustcellars.com> <016e01cbb848$6119d4b0$234d7e10$@augustcellars.com> In-Reply-To: <016e01cbb848$6119d4b0$234d7e10$@augustcellars.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-cr-puzzleid: {CD380D8F-2233-4756-B3FE-4B09032BA2B0} x-cr-hashedpuzzle: BR6u BfzG B3BP Irbi Kduk POZQ Rv3j VgUZ V2z9 bDmb eHyw i7e2 jCC6 mfZj pUgN qXx3; 4; YQBiAGYAYQBiAEAAaQBlAHQAZgAuAG8AcgBnADsAaABhAHIAdABtAGEAbgBzAEAAcABhAGkAbgBsAGUAcwBzAC0AcwBlAGMAdQByAGkAdAB5AC4AYwBvAG0AOwBpAGUAdABmAEAAYQB1AGcAdQBzAHQAYwBlAGwAbABhAHIAcwAuAGMAbwBtADsAawBsAGEAYQBzAEAAYwBpAHMAYwBvAC4AYwBvAG0A; Sosha1_v1; 7; {CD380D8F-2233-4756-B3FE-4B09032BA2B0}; agBvAHMAaAAuAGgAbwB3AGwAZQB0AHQAQABqAGEALgBuAGUAdAA=; Thu, 20 Jan 2011 10:15:04 GMT; UgBFADoAIABbAGEAYgBmAGEAYgBdACAAUAByAG8AcABvAHMAZQBkACAAYwBoAGEAbgBnAGUAcwAgAHQAbwAgAGQAcgBhAGYAdAAtAGkAZQBmAHQALQBhAGIAZgBhAGIALQBhAGEAYQAtAHMAYQBtAGwA x-originating-ip: [194.82.140.76] 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] Proposed changes to draft-ieft-abfab-aaa-saml 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, 20 Jan 2011 10:12:43 -0000 > I thought that he was given an example of uniform name of an attribute > authority, as oppose to suggesting that there might be different > names. > But that also implies that you need to be able to query as to which of > the different authorities you need to query in order to get the attributes > you care about. Even more issues of attribute name and quality matching = to > be dealt with. Yes, but I don't think that this is any different in Abfab from the multipl= e AA case with contemporary technologies; and today this is generally consi= dered a deployment issue. So I think we can choose to either apply the same= deployment strategies used today, or define a standard way of doing it. I'm personally fairly agnostic about this, although I get a sense from the = list and private communications that there is interest in defining a standa= rd approach for this. Josh. JANET(UK) is a trading name of The JNT Association, a company limited by guarantee which is registered in England under No. 2881024=20 and whose Registered Office is at Lumen House, Library Avenue, Harwell Oxford, Didcot, Oxfordshire. OX11 0SG From ietf@augustcellars.com Thu Jan 20 08:14:26 2011 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 F06053A7149 for ; Thu, 20 Jan 2011 08:14:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.572 X-Spam-Level: X-Spam-Status: No, score=-2.572 tagged_above=-999 required=5 tests=[AWL=0.027, 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 L5OzAMx3gWrZ for ; Thu, 20 Jan 2011 08:14:25 -0800 (PST) Received: from new-smtp02.pacifier.net (new-smtp02.pacifier.net [64.255.237.176]) by core3.amsl.com (Postfix) with ESMTP id 90BE83A70F5 for ; Thu, 20 Jan 2011 08:14:25 -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-smtp02.pacifier.net (Postfix) with ESMTPSA id 178BB2CA02; Thu, 20 Jan 2011 08:17:08 -0800 (PST) From: "Jim Schaad" To: "'Sam Hartman'" References: <015e01cbb83c$6aa99bc0$3ffcd340$@augustcellars.com> In-Reply-To: Date: Thu, 20 Jan 2011 08:35:31 -0800 Message-ID: <019301cbb8c0$0e8463a0$2b8d2ae0$@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: AQJQ+Dtxf1C/LDX9ic1UEW+T9DRrtADYYen8ksjBfhA= Content-Language: en-us Cc: abfab@ietf.org Subject: Re: [abfab] Comments on draft-lear-abfab-arch-01 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, 20 Jan 2011 16:14:27 -0000 > -----Original Message----- > From: abfab-bounces@ietf.org [mailto:abfab-bounces@ietf.org] On Behalf > Of Sam Hartman > Sent: Wednesday, January 19, 2011 5:34 PM > To: Jim Schaad > Cc: abfab@ietf.org > Subject: Re: [abfab] Comments on draft-lear-abfab-arch-01 > > >>>>> "Jim" == Jim Schaad writes: > > Jim> In step 2 A couple of questions come to mind here - which > Jim> authentication mechanism are selecting? The End Host to IdP or > Jim> the End Host to the Relying Part? Are there any options here > Jim> or is there only a single possibility? > > There is no authentication of the end-host to the RP. > The end-host authenticates to the IDP. > There is a key confirmation step where the end-host and RP prove they have > the same session key. > In some sense, that performs an authentication function; it definitely binds > the RP->IDP authentication with the end-host->IDP authentication. I was expecting to see some degree of authentication of the RP to the end-host before the process started. If this is not the case then all of the name matching logic is going to occur in the IDP and none of it in the end-host which has the best guess as to who it thinks it should be talking to. Are you referring to a step where the end-host and RP prove they have the same session key to each other, or are they trying to prove this to a third party? I can figure out that the first occurs but not the second. Currently the only check that is performed is that the name is the same. If we are clobbering the name with the key, then it is vital that the end-host and the RP agree on the name form of the RP before they are clobbered and given to the IDP. You did not address the question of a single possibility - the current text says it is a selection step, but if the selection is done by the specification then this is not really a selection that is part of the exchange. > > Jim> In Step 3 For various reasons, I think one will want to > Jim> establish a secure link to from the Client Application to the > Jim> RP either before - or as - it is supplying the NAI to the RP. > Jim> It might however been that you are really only saying that you > Jim> are sending the realm portion of the NAI to the RP. That would > Jim> be a different story, but you may still want to get some type > Jim> of secure link. > > You're typically only sending the realm portion if your EAP method uses > privacy identifiers (the good ones do). > > A secure link to the RP at this stage is out of scope for a GSS substrate for > abfab in my opinion. > It adds a lot of mess, and there are better ways of doing most of what you > are probably trying to do. > > Also, note that since the end-host has no credential for the RP, and this is a > huge feature of the architecture, your options are limited. So we are not even planning to say that we are going to be using TLS here. However it would still be possible to do some type of leap-of-faith credential here where we can get a secure link - which I think you are really planning to do since you talked about comparing the keys using the IDP as an arbiter. > > Jim> Section 3.1 - in Paragraph 3 - It specifies that we are going > Jim> to put the NAI in the GSS_C_NT_USER_NAME field of GSS-API, is > Jim> it going to be the responsibility of the GSS-API layer to > Jim> fragment the realm portion of name from the full NAI depending > Jim> on if it is talking to the RP or the IdP? > > Um. > I think you're a bit confused about what role GSS-API fills here. > The NAI is an input to the GSS-API, which locally on the end-host feeds it to a > specific EAP method. > That method will hide it if that method hides identity. Ok - then I am confused. Are we talking about having a single GSS-API method which is going to coordinate both of the secure links we are looking at, or are there going to be two different GSS-API methods, or is the end-host to RP link not going to be covered by GSS-API? My assumption was the first - that is a single GSS-API method was going to have to do the secure link from the end-host to the RP as well as the EAP conversation to the IDP. In this case the question does make sense as the name being sent over EAP is different than that being sent to the RP, but both are coming out a single common GSS-API method > > Jim> There is no mention in this section that there may be multiple > Jim> IdPs for a single realm that could be used by the RP and the > Jim> selection of which IdP it wants to use is going to be based on > Jim> the set of attributes that the RP needs or a level of > Jim> authentication that is required by the RP (see [sp800-63-1] > Jim> NIST SP 800-63-1 "Electronic Authentication Guideline", > Jim> December 2008 as examples). > > True, basically because there's no existing protocol mechanism to accomplish > the end-host finding out what the RP wants. > This is kind of a GSS failing; there is some Microsoft work that could expand > GSS in some ways. > Abfab can take advantage of this whenever GSS gains the feature. > > I think I have an action item to discuss federation and IDP selection (although > someone else may have the action item for IDP selection--can't remember). > However it's more going to be about future extensions and directions for > expansion. It's a hard problem - as long as that is discussed we can probably punt for now. > > > Jim> Section 3.2 Has the sentences " Aside from a valuable secret > Jim> being exposed, a synchronization problem can also often > Jim> develop. Since there is no single authentication mechanism > Jim> that will be used everywhere there is another associated > Jim> requirement:" I have a couple of issues here. First there is a > Jim> problem which is stated - i.e. synchronization - but the next > Jim> sentence does not appear to expand on the problem but rather > Jim> deals with a different issue. I would like to have the first > Jim> thought finished before going onto the second one. I think > Jim> this paragraph is supposed to be talking about issues that we > Jim> have been taught - but the word Since does not convey this is a > Jim> separate issue we have dealing with. > > Help with wording would be greatly appreciated here. Not a problem - Elliot - what did you mean by a synchronization problem? > > Jim> In the sentence "through the authenticator (i.e., service > Jim> provider)" - s/service provider/relying party/ > > Jim> Section 3.5 In this picture - I believe that it would be more > Jim> accurate to have the EAP stream go directly through the > Jim> Federation layer - this would not be routed as it is E2E. > > No, I think the EAP stream is routed. > > Just as TLS is routed over IP. > While TLS is routed over IP - I generally think of it as being channel and thus direct between the two parties. I ignore the routing that is being done by the IP layer as it does not affect the data being transported. This is not the same as with the RADIUS/DIAMETER stream where the routing layer can change the contents of the message as it travels through the federation layer. Thus I think that representing the data flows differently in the picture makes sense. > > Jim> Section 4.3 Given that you have stated that we are going to use > Jim> the Kerberos realm naming, on which I have no opinion, I think > Jim> that there should be some text about how the end host is going > Jim> to make a decision that it is talking to the correct RP to > Jim> begin with. It does not have any pre-existing security > Jim> relationship with the realm of the RP. > > It kind of needs to trust the RP for some of this. > It needs to derive a name for the RP from input it gets from the user or a > trusted referral. > Then, the IDP and some proxy goo is responsible for making sure that the RP > it is talking to is the RP it names. But there is a difference between relying on just the IDP to do the name matching, and the end-host doing the name matching and then sending the name that it gets from the RP to send to the IDP for the final name matching check. I am worried about the question of trying to go from a DNS name to a NAI name at this point. > > Jim> Additional Issues: > > Jim> 1. The document is currently written in terms of dealing with > Jim> an Identity provider, and I can understand why that is so as > Jim> without an identity not much will happen. However it seems to > Jim> me that there is also a desire to be able to talk to an > Jim> attribute service in much the same way. However it is not > Jim> clear that there is a need for the End Host to talk to the > Jim> attribute provider - that communication should be thought of as > Jim> passing between the IdP, the RP and the AtP. The IdP may need > Jim> to get a different or better identity proof as part of that > Jim> conversation. > > Hmm. > > Jim> 2. I am not sure if there needs to be a discussion on what > Jim> needs to be a part of a federation agreement. One of the > Jim> issues that I can see as being troublesome as it does not seem > Jim> to be vastly expandable is the question of what makes for an > Jim> equivalent statement. Is it to be expected that the SASL > Jim> statements are going to be made in terms of the federation > Jim> agreement attributes, or does there need to be available to the > Jim> RP some type of mapping statement? > > I hope we can avoid discussions of what goes in a federation agreement. I can understand this, however I think that there needs to be some high level discussion of questions like how mapping of statements should be done. Jim > > _______________________________________________ > abfab mailing list > abfab@ietf.org > https://www.ietf.org/mailman/listinfo/abfab From hartmans@painless-security.com Thu Jan 20 13:30:18 2011 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 1B6243A683A for ; Thu, 20 Jan 2011 13:30:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.283 X-Spam-Level: X-Spam-Status: No, score=-2.283 tagged_above=-999 required=5 tests=[AWL=-0.018, 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 cqv5BJtwEy+R for ; Thu, 20 Jan 2011 13:30:17 -0800 (PST) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by core3.amsl.com (Postfix) with ESMTP id 005F43A6838 for ; Thu, 20 Jan 2011 13:30:16 -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 8EDAE20246 for ; Thu, 20 Jan 2011 16:31:14 -0500 (EST) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id CED64432C; Thu, 20 Jan 2011 16:32:46 -0500 (EST) From: Sam Hartman To: abfab@ietf.org Date: Thu, 20 Jan 2011 16:32:46 -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] draft-ietf-abfab-gss-eap-naming: how to name vendor-specific attributes 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, 20 Jan 2011 21:30:18 -0000 We want to be able to name AAA attributes. The reason is that we want GSS applications to be able to request these attributes from the gss library so they can get authorization information returned from the AAA server. That's relatively easy for standardized attributes. What do we do about vendor specific attributes (VSAs)? At the Moonshot meeting last September, people were assuming that VSAs were uniform in format. That's not true. There is a suggested format in the RADIUS spec (I have not looked at Diameter). However it's not used by everything. So, how do we want to name these attributes? I guess one option is to define attribute names for the recommended VSA format and later if there are VSA formats that are used in abfab, we can describe how they are handled. One robustness concern is this means that a GSS implementation needs to parse each VSA and be robust even if it is mall-formed under the standard format. Another implication is that an attribute may end up generating incorrect names because it happens to parse under the recommended format even when that is not the actual format. From gabilm@um.es Fri Jan 21 01:10:16 2011 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 828E13A68FD for ; Fri, 21 Jan 2011 01:10:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.299 X-Spam-Level: X-Spam-Status: No, score=-4.299 tagged_above=-999 required=5 tests=[AWL=-2.000, BAYES_00=-2.599, 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 luIRbZuCH3yX for ; Fri, 21 Jan 2011 01:10:15 -0800 (PST) Received: from xenon12.um.es (xenon12.um.es [155.54.212.166]) by core3.amsl.com (Postfix) with ESMTP id 8A4CD3A68FB for ; Fri, 21 Jan 2011 01:10:15 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by xenon12.um.es (Postfix) with ESMTP id EF7004BCFB for ; Fri, 21 Jan 2011 10:12:58 +0100 (CET) X-Virus-Scanned: by antispam in UMU at xenon12.um.es Received: from xenon12.um.es ([127.0.0.1]) by localhost (xenon12.um.es [127.0.0.1]) (amavisd-new, port 10024) with LMTP id vfQhosHokNa9 for ; Fri, 21 Jan 2011 10:12:58 +0100 (CET) Received: from MacBook-Pro-de-Gabriel-Lopez.local (unknown [84.236.164.151]) (Authenticated sender: gabilm) by xenon12.um.es (Postfix) with ESMTPA id 8A0534BA0C for ; Fri, 21 Jan 2011 10:12:57 +0100 (CET) Message-ID: <4D394E32.6020001@um.es> Date: Fri, 21 Jan 2011 10:13:22 +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: <4D10F279.3030601@cisco.com> <4D2AEE2A.1080808@cisco.com> <015501cbb831$bc840cb0$358c2610$@augustcellars.com> In-Reply-To: <015501cbb831$bc840cb0$358c2610$@augustcellars.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [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: Fri, 21 Jan 2011 09:10:16 -0000 El 20/01/11 00:36, Jim Schaad escribió: > > I am in favor of having some diagrams really early in the processes. I > think this really helps to get understanding setup early. But I tend to be > a very pictorial person. > I agree with Jim here, flow diagrams will help to understand the architecture and to detect missing problems. some other comments: - pag. 6. - 5. [... ]At this stage, the RP will likely have no idea who the principal is. You propose here to optionally send a SAML Attribute Query to the idP/AA, but this query has to include the user's subject. How does it match with the previous sentence? You could also here request a SAML AuthnStatement that could be use latter to request attributes by SOAP channels (if you decide to consider this scenario) - pag. 6 - 6. IdP informs the principal of which EAP method to use [...] In this case the RADIUS server plays the role of idP, but what happens if the organization already have a running idP (i.e. Shibboleth)? - pag. 7 - 9. What kind of checks is done here? could you provide an example? I mean. Are you checking if idP could issue an attribute statement including user's attributes for SP? An Attribute Release Policy? - pag. 12. if you decide to apply abfab arch over eduroam you could make use of trust-anchor and PKI services (eduGAIN) to assert trust between organizations, but this option is not described in the draft. - pag. 19. The text: "Host-based service names do not work ideally when different instances of a service are running on different ports. Also, these do not work ideally when SRV record or other insecure referrals are used." is not in-line with the rest of the section. Best regards, Gabi. -- ---------------------------------------------------------------- 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 lear@cisco.com Fri Jan 21 01:51:02 2011 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 317B23A690D for ; Fri, 21 Jan 2011 01:51:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.04 X-Spam-Level: X-Spam-Status: No, score=-110.04 tagged_above=-999 required=5 tests=[AWL=0.259, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, 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 tLnmBjpzsDJI for ; Fri, 21 Jan 2011 01:51:01 -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 0320B3A690A for ; Fri, 21 Jan 2011 01:51:00 -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: AmcEAP7mOE2Q/khNgWdsb2JhbACEE6BRFQEBFiIkoyyKWJA+gSSDOHQEix8 Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-2.cisco.com with ESMTP; 21 Jan 2011 09:53:45 +0000 Received: from dhcp-10-55-86-19.cisco.com (dhcp-10-55-86-19.cisco.com [10.55.86.19]) by ams-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p0L9rjfI019797; Fri, 21 Jan 2011 09:53:45 GMT Message-ID: <4D3957A8.1090607@cisco.com> Date: Fri, 21 Jan 2011 10:53:44 +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: =?UTF-8?B?R2FicmllbCBMw7NwZXo=?= References: <4D10F279.3030601@cisco.com> <4D2AEE2A.1080808@cisco.com> <015501cbb831$bc840cb0$358c2610$@augustcellars.com> <4D394E32.6020001@um.es> In-Reply-To: <4D394E32.6020001@um.es> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: abfab@ietf.org Subject: Re: [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: Fri, 21 Jan 2011 09:51:02 -0000 Hi Gabriel, Thank you for your comments. First, everyone please remember that this draft is absolutely a work in progress and meant to reflect what we are in fact standardizing, as well as indicate what we are not. Perhaps it also serves as an excellent way to focus us on what we may need to standardize but have not yet agreed to do so. As to your comments: On 1/21/11 10:13 AM, Gabriel López wrote: > El 20/01/11 00:36, Jim Schaad escribió: >> >> I am in favor of having some diagrams really early in the processes. I >> think this really helps to get understanding setup early. But I tend >> to be >> a very pictorial person. >> > I agree with Jim here, flow diagrams will help to understand the > architecture and to detect missing problems. I agree, but I'm not sure that was what Jim was actually saying. Jim, were you asking for additional pictoral-non-flow-based diagrams? If so, what would you find useful? > > > some other comments: > > - pag. 6. - 5. [... ]At this stage, the RP will likely have no > idea who the principal > is. > > You propose here to optionally send a SAML Attribute Query to the > idP/AA, but this query has to include the user's subject. How does it > match with the previous sentence? At that point we are not yet ready to issue a SAML Attribute Query. That should happen in Step 10. As you can see there is some XXX in there that needs to be completed. > > You could also here request a SAML AuthnStatement that could be > use latter to request attributes by SOAP channels (if you decide to > consider this scenario) > > - pag. 6 - 6. IdP informs the principal of which EAP method to use > [...] > > In this case the RADIUS server plays the role of idP, but what > happens if the organization already have a running idP (i.e. Shibboleth)? They get to run some additional code. Not sure how we get around that. > > - pag. 7 - 9. What kind of checks is done here? could you provide > an example? I mean. > Are you checking if idP could issue an attribute > statement including user's attributes for SP? > An Attribute Release Policy? That is view of what Step 9 is all about. What would follow Step 9 (latter part of Step 10) would be a SAML assertion. Step 10 probably needs to be broken down. > > - pag. 12. if you decide to apply abfab arch over eduroam you > could make use of trust-anchor and PKI services (eduGAIN) to assert > trust between organizations, but this option is not described in the > draft. Thus far we have not ventured into PKI at all in the draft. > > - pag. 19. The text: "Host-based service names do not work ideally > when different instances > of a service are running on different ports. Also, these do not work > ideally when SRV record or other insecure referrals are used." is > not in-line with the rest of the section. Again, thanks for your comments! From Josh.Howlett@ja.net Fri Jan 21 01:55:37 2011 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 6102F3A690A for ; Fri, 21 Jan 2011 01:55:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.478 X-Spam-Level: X-Spam-Status: No, score=-102.478 tagged_above=-999 required=5 tests=[AWL=0.121, 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 EvOPYQMbmsPc for ; Fri, 21 Jan 2011 01:55:36 -0800 (PST) Received: from har003676.ukerna.ac.uk (har003676.ukerna.ac.uk [194.82.140.75]) by core3.amsl.com (Postfix) with ESMTP id 8EE823A6902 for ; Fri, 21 Jan 2011 01:55:36 -0800 (PST) Received: from har003676.ukerna.ac.uk (localhost.localdomain [127.0.0.1]) by localhost (Email Security Appliance) with SMTP id A7B284A6B7A_D3958BCB; Fri, 21 Jan 2011 09:58:20 +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 87A6F4A6B77_D3958BBF; Fri, 21 Jan 2011 09:58:19 +0000 (GMT) Received: from EXC001.atlas.ukerna.ac.uk ([193.62.83.37]) by EXC001 ([193.62.83.37]) with mapi id 14.01.0218.012; Fri, 21 Jan 2011 09:58:39 +0000 From: Josh Howlett To: Sam Hartman , "abfab@ietf.org" Thread-Topic: [abfab] draft-ietf-abfab-gss-eap-naming: how to name vendor-specific attributes Thread-Index: AQHLuOm3OUK9xnia20i4M+zmtGcISJPbMUig Date: Fri, 21 Jan 2011 09:58:38 +0000 Message-ID: <55DC663C2F4F9F439F23543E0078E8B308D35A@EXC001> References: In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [194.82.140.76] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Josh Howlett Subject: Re: [abfab] draft-ietf-abfab-gss-eap-naming: how to name vendor-specific attributes 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, 21 Jan 2011 09:55:37 -0000 > So, how do we want to name these attributes? I guess one option is to > define attribute names for the recommended VSA format and later if > there > are VSA formats that are used in abfab, we can describe how they are > handled. Seems like a reasonable approach. Is this something we might want to bring = to the attention of RADEXT? Josh. JANET(UK) is a trading name of The JNT Association, a company limited by guarantee which is registered in England under No. 2881024=20 and whose Registered Office is at Lumen House, Library Avenue, Harwell Oxford, Didcot, Oxfordshire. OX11 0SG From gabilm@um.es Fri Jan 21 02:19:36 2011 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 AD8C63A6916 for ; Fri, 21 Jan 2011 02:19:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.299 X-Spam-Level: X-Spam-Status: No, score=-5.299 tagged_above=-999 required=5 tests=[AWL=1.000, 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 jT7TOL0CVqOy for ; Fri, 21 Jan 2011 02:19:21 -0800 (PST) Received: from xenon14.um.es (xenon14.um.es [155.54.212.168]) by core3.amsl.com (Postfix) with ESMTP id 2A6BB3A6902 for ; Fri, 21 Jan 2011 02:19:10 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by xenon14.um.es (Postfix) with ESMTP id 893045D44B for ; Fri, 21 Jan 2011 11:21:50 +0100 (CET) X-Virus-Scanned: by antispam in UMU at xenon14.um.es Received: from xenon14.um.es ([127.0.0.1]) by localhost (xenon14.um.es [127.0.0.1]) (amavisd-new, port 10024) with LMTP id BeIdtYMvpqqB for ; Fri, 21 Jan 2011 11:21:50 +0100 (CET) Received: from MacBook-Pro-de-Gabriel-Lopez.local (unknown [84.236.164.151]) (Authenticated sender: gabilm) by xenon14.um.es (Postfix) with ESMTPA id CC27E5D61B for ; Fri, 21 Jan 2011 11:21:47 +0100 (CET) Message-ID: <4D395E54.3030308@um.es> Date: Fri, 21 Jan 2011 11:22:12 +0100 From: =?UTF-8?B?R2FicmllbCBMw7NwZXo=?= 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: <4D10F279.3030601@cisco.com> <4D2AEE2A.1080808@cisco.com> <015501cbb831$bc840cb0$358c2610$@augustcellars.com> <4D394E32.6020001@um.es> <4D3957A8.1090607@cisco.com> In-Reply-To: <4D3957A8.1090607@cisco.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [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: Fri, 21 Jan 2011 10:19:36 -0000 El 21/01/11 10:53, Eliot Lear escribió: > Hi Gabriel, > > Thank you for your comments. First, everyone please remember that this > draft is absolutely a work in progress and meant to reflect what we are > in fact standardizing, as well as indicate what we are not. Perhaps it > also serves as an excellent way to focus us on what we may need to > standardize but have not yet agreed to do so. > > As to your comments: > > On 1/21/11 10:13 AM, Gabriel López wrote: >> El 20/01/11 00:36, Jim Schaad escribió: >>> I am in favor of having some diagrams really early in the processes. I >>> think this really helps to get understanding setup early. But I tend >>> to be >>> a very pictorial person. >>> >> I agree with Jim here, flow diagrams will help to understand the >> architecture and to detect missing problems. > I agree, but I'm not sure that was what Jim was actually saying. Jim, > were you asking for additional pictoral-non-flow-based diagrams? If > so, what would you find useful? >> >> some other comments: >> >> - pag. 6. - 5. [... ]At this stage, the RP will likely have no >> idea who the principal >> is. >> >> You propose here to optionally send a SAML Attribute Query to the >> idP/AA, but this query has to include the user's subject. How does it >> match with the previous sentence? > At that point we are not yet ready to issue a SAML Attribute Query. > That should happen in Step 10. As you can see there is some XXX in > there that needs to be completed. so, the idp returns SAML attributes without a SAML attribute query or the RP, in a latter second round-trip sends the SAML attribute query to the idP over RADIUS. That's one of the issues the diagrams should clarify :) >> You could also here request a SAML AuthnStatement that could be >> use latter to request attributes by SOAP channels (if you decide to >> consider this scenario) >> >> - pag. 6 - 6. IdP informs the principal of which EAP method to use >> [...] >> >> In this case the RADIUS server plays the role of idP, but what >> happens if the organization already have a running idP (i.e. Shibboleth)? > They get to run some additional code. Not sure how we get around that. > and the trust based on the AAA infrastructure could not be enough. thanks for the answer. regards, Gabi. >> - pag. 7 - 9. What kind of checks is done here? could you provide >> an example? I mean. >> Are you checking if idP could issue an attribute >> statement including user's attributes for SP? >> An Attribute Release Policy? > That is view of what Step 9 is all about. What would follow Step 9 > (latter part of Step 10) would be a SAML assertion. Step 10 probably > needs to be broken down. >> - pag. 12. if you decide to apply abfab arch over eduroam you >> could make use of trust-anchor and PKI services (eduGAIN) to assert >> trust between organizations, but this option is not described in the >> draft. > Thus far we have not ventured into PKI at all in the draft. > >> - pag. 19. The text: "Host-based service names do not work ideally >> when different instances >> of a service are running on different ports. Also, these do not work >> ideally when SRV record or other insecure referrals are used." is >> not in-line with the rest of the section. > Again, thanks for your comments! > -- ---------------------------------------------------------------- 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 hartmans@painless-security.com Fri Jan 21 04:19:00 2011 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 114893A693C for ; Fri, 21 Jan 2011 04:19:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.132 X-Spam-Level: X-Spam-Status: No, score=-2.132 tagged_above=-999 required=5 tests=[AWL=-0.167, 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 7PX8kquhiTDE for ; Fri, 21 Jan 2011 04:18:59 -0800 (PST) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by core3.amsl.com (Postfix) with ESMTP id 4EEAC3A693B for ; Fri, 21 Jan 2011 04:18:59 -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 88D6B20222; Fri, 21 Jan 2011 07:19:54 -0500 (EST) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 0E658432C; Fri, 21 Jan 2011 07:21:32 -0500 (EST) From: Sam Hartman To: Gabriel =?iso-8859-1?Q?L=F3pez?= References: <4D10F279.3030601@cisco.com> <4D2AEE2A.1080808@cisco.com> <015501cbb831$bc840cb0$358c2610$@augustcellars.com> <4D394E32.6020001@um.es> Date: Fri, 21 Jan 2011 07:21:32 -0500 In-Reply-To: <4D394E32.6020001@um.es> ("Gabriel =?iso-8859-1?Q?L=F3pez=22'?= =?iso-8859-1?Q?s?= message of "Fri, 21 Jan 2011 10:13:22 +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] 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: Fri, 21 Jan 2011 12:19:00 -0000 >>>>> "Gabriel" == Gabriel López writes: Gabriel> - pag. 6 - 6. IdP informs the principal of which EAP Gabriel> method to use [...] Gabriel> In this case the RADIUS server plays the role of idP, Gabriel> but what happens if the organization already have a running Gabriel> idP (i.e. Shibboleth)? We're viewing the AAA server, SAML IDP and EAP server all as one big box we've been calling IDP. They may be realized as separate entities. The division of labor is a local matter. From hartmans@painless-security.com Fri Jan 21 04:27:41 2011 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 432063A6950 for ; Fri, 21 Jan 2011 04:27:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.128 X-Spam-Level: X-Spam-Status: No, score=-2.128 tagged_above=-999 required=5 tests=[AWL=-0.163, 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 riktz-R6U4tv for ; Fri, 21 Jan 2011 04:27:40 -0800 (PST) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by core3.amsl.com (Postfix) with ESMTP id 4D4673A693C for ; Fri, 21 Jan 2011 04:27:40 -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 DA9312021E; Fri, 21 Jan 2011 07:28:39 -0500 (EST) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 10F78432C; Fri, 21 Jan 2011 07:30:17 -0500 (EST) From: Sam Hartman To: Gabriel =?iso-8859-1?Q?L=F3pez?= References: <4D10F279.3030601@cisco.com> <4D2AEE2A.1080808@cisco.com> <015501cbb831$bc840cb0$358c2610$@augustcellars.com> <4D394E32.6020001@um.es> <4D3957A8.1090607@cisco.com> <4D395E54.3030308@um.es> Date: Fri, 21 Jan 2011 07:30:17 -0500 In-Reply-To: <4D395E54.3030308@um.es> ("Gabriel =?iso-8859-1?Q?L=F3pez=22'?= =?iso-8859-1?Q?s?= message of "Fri, 21 Jan 2011 11:22:12 +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] 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: Fri, 21 Jan 2011 12:27:41 -0000 >>>>> "Gabriel" == Gabriel López writes: Gabriel> El 21/01/11 10:53, Eliot Lear escribió: >> Hi Gabriel, >> >> Thank you for your comments. First, everyone please remember >> that this draft is absolutely a work in progress and meant to >> reflect what we are in fact standardizing, as well as indicate >> what we are not. Perhaps it also serves as an excellent way to >> focus us on what we may need to standardize but have not yet >> agreed to do so. >> >> As to your comments: >> >> On 1/21/11 10:13 AM, Gabriel López wrote: >>> El 20/01/11 00:36, Jim Schaad escribió: >>>> I am in favor of having some diagrams really early in the >>>> processes. I think this really helps to get understanding >>>> setup early. But I tend to be a very pictorial person. >>>> >>> I agree with Jim here, flow diagrams will help to understand the >>> architecture and to detect missing problems. >> I agree, but I'm not sure that was what Jim was actually saying. >> Jim, were you asking for additional pictoral-non-flow-based >> diagrams? If so, what would you find useful? >>> >>> some other comments: >>> >>> - pag. 6. - 5. [... ]At this stage, the RP will likely have no >>> idea who the principal is. >>> >>> You propose here to optionally send a SAML Attribute Query to >>> the idP/AA, but this query has to include the user's >>> subject. How does it match with the previous sentence? >> At that point we are not yet ready to issue a SAML Attribute >> Query. That should happen in Step 10. As you can see there is >> some XXX in there that needs to be completed. Gabriel> so, the idp returns SAML attributes without a SAML Gabriel> attribute query or the RP, in a latter second round-trip Gabriel> sends the SAML attribute query to the idP over RADIUS. Gabriel> That's one of the issues the diagrams should clarify :) I'd like to push back on this a bit. If there's one thing coming out of the attribute provider discussion it is a strong indication of complexity. Let's have the basic abfab architecture not include support for multiple round trip attribute queries. No one has stepped forward to do the work. The current code, GSS EAP spec, GSS naming extensions and semantics of the SAML attributes all need to be extended. I think Josh has volunteered to do some of the work of extending the AAA attribute semantics. I think that Eliot had volunteered to take a stab at writing up some of the architectural issues with the attribute query problem to show that it is something we can do as a future extension. I think there's plenty of text in the list discussion to support that. However, this feature is detachable from the base architecture. Let's detach it: the base architecture is complex enough. What would this mean? It would mean we would not discuss additional AAA-based attribute queries in the diagrams or the step-by-step overview. We would have a brief discussion of the issues in their own section, but would not enumerate the interactions in the rest of the document. We will not make it a requirement that components of the system designed today support these queries. We will continue to make sure that what we build can be extended in the future to support multiple rounds. When someone steps forward, they can write documents extending our system to support this feature. Probably at least one of the documents needs to fall into kitten not here. --Sam From gabilm@um.es Fri Jan 21 04:39:51 2011 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 C3B0E3A6955 for ; Fri, 21 Jan 2011 04:39:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.632 X-Spam-Level: X-Spam-Status: No, score=-3.632 tagged_above=-999 required=5 tests=[AWL=-1.333, BAYES_00=-2.599, 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 Ntn8d-E3Snc8 for ; Fri, 21 Jan 2011 04:39:49 -0800 (PST) Received: from xenon12.um.es (xenon12.um.es [155.54.212.166]) by core3.amsl.com (Postfix) with ESMTP id 915083A6952 for ; Fri, 21 Jan 2011 04:39:49 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by xenon12.um.es (Postfix) with ESMTP id 76B304BC56; Fri, 21 Jan 2011 13:42:34 +0100 (CET) X-Virus-Scanned: by antispam in UMU at xenon12.um.es Received: from xenon12.um.es ([127.0.0.1]) by localhost (xenon12.um.es [127.0.0.1]) (amavisd-new, port 10024) with LMTP id nEXoDSSA+eRf; Fri, 21 Jan 2011 13:42:34 +0100 (CET) Received: from MacBook-Pro-de-Gabriel-Lopez.local (unknown [84.236.164.151]) (Authenticated sender: gabilm) by xenon12.um.es (Postfix) with ESMTPA id BC4064C225; Fri, 21 Jan 2011 13:42:31 +0100 (CET) Message-ID: <4D397F50.4030305@um.es> Date: Fri, 21 Jan 2011 13:42:56 +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: Sam Hartman References: <4D10F279.3030601@cisco.com> <4D2AEE2A.1080808@cisco.com> <015501cbb831$bc840cb0$358c2610$@augustcellars.com> <4D394E32.6020001@um.es> <4D3957A8.1090607@cisco.com> <4D395E54.3030308@um.es> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: abfab@ietf.org Subject: Re: [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: Fri, 21 Jan 2011 12:39:51 -0000 El 21/01/11 13:30, Sam Hartman escribió: >>>>>> "Gabriel" == Gabriel López writes: > > Gabriel> so, the idp returns SAML attributes without a SAML > Gabriel> attribute query or the RP, in a latter second round-trip > Gabriel> sends the SAML attribute query to the idP over RADIUS. > Gabriel> That's one of the issues the diagrams should clarify :) > > I'd like to push back on this a bit. > > If there's one thing coming out of the attribute provider discussion it > is a strong indication of complexity. Let's have the basic abfab > architecture not include support for multiple round trip attribute > queries. No one has stepped forward to do the work. The current code, > GSS EAP spec, GSS naming extensions and semantics of the SAML attributes > all need to be extended. That's what I supposed, and I think should be clarified in the document. Following this approach, the current document proposes to return the attribute statements without sending an attribute query. As far as I understood. Maybe it is a low level detail that should not be mentioned in the document but I think should be clarified. Best regards, Gabi. > > > --Sam -- ---------------------------------------------------------------- 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 Josh.Howlett@ja.net Fri Jan 21 04:40:59 2011 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 C06443A6958 for ; Fri, 21 Jan 2011 04:40:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.332 X-Spam-Level: X-Spam-Status: No, score=-102.332 tagged_above=-999 required=5 tests=[AWL=-0.033, 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 Ewxa55X6xQDE for ; Fri, 21 Jan 2011 04:40:59 -0800 (PST) Received: from har003676.ukerna.ac.uk (har003676.ukerna.ac.uk [194.82.140.75]) by core3.amsl.com (Postfix) with ESMTP id 1006C3A6952 for ; Fri, 21 Jan 2011 04:40:59 -0800 (PST) Received: from har003676.ukerna.ac.uk (localhost.localdomain [127.0.0.1]) by localhost (Email Security Appliance) with SMTP id C3FFF4A6B76_D397F7FB; Fri, 21 Jan 2011 12:43:43 +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 B1FC74A6B6F_D397F7DF; Fri, 21 Jan 2011 12:43:41 +0000 (GMT) Received: from EXC001.atlas.ukerna.ac.uk ([193.62.83.37]) by EXC001 ([193.62.83.37]) with mapi id 14.01.0218.012; Fri, 21 Jan 2011 12:44:01 +0000 From: Josh Howlett To: Sam Hartman , =?iso-8859-1?Q?Gabriel_L=F3pez?= Thread-Topic: [abfab] draft-lear-abfab-arch-01 posted Thread-Index: AQHLoT1Ze3iKLilXkEaBdn1JxzBPzJPbi60ngAACRJA= Date: Fri, 21 Jan 2011 12:44:00 +0000 Message-ID: <55DC663C2F4F9F439F23543E0078E8B308D5FF@EXC001> References: <4D10F279.3030601@cisco.com> <4D2AEE2A.1080808@cisco.com> <015501cbb831$bc840cb0$358c2610$@augustcellars.com> <4D394E32.6020001@um.es> <4D3957A8.1090607@cisco.com> <4D395E54.3030308@um.es> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [194.82.140.76] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Josh Howlett , "abfab@ietf.org" Subject: Re: [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: Fri, 21 Jan 2011 12:40:59 -0000 > Probably at least one of the documents > needs to fall into kitten not here. Is it worth having some discussion at Kitten in Prague, if only to explain = the use-case? (in fact, I think this is the second nice-to-have that we've = identified as having a dependency there). Josh. JANET(UK) is a trading name of The JNT Association, a company limited by guarantee which is registered in England under No. 2881024=20 and whose Registered Office is at Lumen House, Library Avenue, Harwell Oxford, Didcot, Oxfordshire. OX11 0SG From lear@cisco.com Fri Jan 21 05:47:40 2011 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 DB2473A697A for ; Fri, 21 Jan 2011 05:47:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.195 X-Spam-Level: X-Spam-Status: No, score=-110.195 tagged_above=-999 required=5 tests=[AWL=0.404, 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 O628TAAycyiM for ; Fri, 21 Jan 2011 05:47:40 -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 D361E3A6983 for ; Fri, 21 Jan 2011 05:47:39 -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: AvIEABIeOU2Q/khMgWdsb2JhbACEE6BRFQEBFiIkoyqKWJBFgSSDOHQEix8 Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-2.cisco.com with ESMTP; 21 Jan 2011 13:50:25 +0000 Received: from dhcp-10-55-86-19.cisco.com (dhcp-10-55-86-19.cisco.com [10.55.86.19]) by ams-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p0LDoO6N020415; Fri, 21 Jan 2011 13:50:25 GMT Message-ID: <4D398F20.8050205@cisco.com> Date: Fri, 21 Jan 2011 14:50:24 +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: <4D10F279.3030601@cisco.com> <4D2AEE2A.1080808@cisco.com> <015501cbb831$bc840cb0$358c2610$@augustcellars.com> <4D394E32.6020001@um.es> <4D3957A8.1090607@cisco.com> <4D395E54.3030308@um.es> 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] 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: Fri, 21 Jan 2011 13:47:41 -0000 Hi Sam, On 1/21/11 1:30 PM, Sam Hartman wrote: > However, this feature is detachable from the base architecture. > Let's detach it: the base architecture is complex enough. Again- that is fine so long as we don't end up redoing the architecture later because we didn't think about this case now. That's the amount of thought we have to give to the problem now, IMHO. Eliot From hartmans@painless-security.com Fri Jan 21 06:17:48 2011 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 7B4D43A699C for ; Fri, 21 Jan 2011 06:17:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.274 X-Spam-Level: X-Spam-Status: No, score=-2.274 tagged_above=-999 required=5 tests=[AWL=-0.009, 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 v8PBgUafzK8m for ; Fri, 21 Jan 2011 06:17:47 -0800 (PST) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by core3.amsl.com (Postfix) with ESMTP id CE3813A6992 for ; Fri, 21 Jan 2011 06:17:47 -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 7A2342021E; Fri, 21 Jan 2011 09:18:47 -0500 (EST) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 85FD6432C; Fri, 21 Jan 2011 09:20:25 -0500 (EST) From: Sam Hartman To: Josh Howlett References: <4D10F279.3030601@cisco.com> <4D2AEE2A.1080808@cisco.com> <015501cbb831$bc840cb0$358c2610$@augustcellars.com> <4D394E32.6020001@um.es> <4D3957A8.1090607@cisco.com> <4D395E54.3030308@um.es> <55DC663C2F4F9F439F23543E0078E8B308D5FF@EXC001> Date: Fri, 21 Jan 2011 09:20:25 -0500 In-Reply-To: <55DC663C2F4F9F439F23543E0078E8B308D5FF@EXC001> (Josh Howlett's message of "Fri, 21 Jan 2011 12:44:00 +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: kitten-chairs@tools.ietf.org, "abfab@ietf.org" Subject: Re: [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: Fri, 21 Jan 2011 14:17:48 -0000 >>>>> "Josh" == Josh Howlett writes: >> Probably at least one of the documents needs to fall into kitten >> not here. Josh> Is it worth having some discussion at Kitten in Prague, if Josh> only to explain the use-case? (in fact, I think this is the Josh> second nice-to-have that we've identified as having a Josh> dependency there). I think talking to the kitten chairs about a brief abfab update as a recurring item would be good. I think we've identified this and something about credential/network selection as nice-to-have. From hartmans@painless-security.com Fri Jan 21 06:18:46 2011 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 6A3DC3A699E for ; Fri, 21 Jan 2011 06:18:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.274 X-Spam-Level: X-Spam-Status: No, score=-2.274 tagged_above=-999 required=5 tests=[AWL=-0.009, 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 tMS-9g2-sEtB for ; Fri, 21 Jan 2011 06:18:45 -0800 (PST) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by core3.amsl.com (Postfix) with ESMTP id B70443A699C for ; Fri, 21 Jan 2011 06:18:45 -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 69FBB20271; Fri, 21 Jan 2011 09:19:45 -0500 (EST) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 6A999432C; Fri, 21 Jan 2011 09:21:23 -0500 (EST) From: Sam Hartman To: Eliot Lear References: <4D10F279.3030601@cisco.com> <4D2AEE2A.1080808@cisco.com> <015501cbb831$bc840cb0$358c2610$@augustcellars.com> <4D394E32.6020001@um.es> <4D3957A8.1090607@cisco.com> <4D395E54.3030308@um.es> <4D398F20.8050205@cisco.com> Date: Fri, 21 Jan 2011 09:21:23 -0500 In-Reply-To: <4D398F20.8050205@cisco.com> (Eliot Lear's message of "Fri, 21 Jan 2011 14:50:24 +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] 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: Fri, 21 Jan 2011 14:18:46 -0000 >>>>> "Eliot" == Eliot Lear writes: Eliot> Hi Sam, Eliot> On 1/21/11 1:30 PM, Sam Hartman wrote: >> However, this feature is detachable from the base architecture. >> Let's detach it: the base architecture is complex enough. Eliot> Again- that is fine so long as we don't end up redoing the Eliot> architecture later because we didn't think about this case Eliot> now. That's the amount of thought we have to give to the Eliot> problem now, IMHO. You and I are in 100% agreement. I tried to capture that in the longer part of my message; sorry if it was not clear. --Sam From ietf@augustcellars.com Fri Jan 21 13:25:17 2011 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 B1D9D3A6A81 for ; Fri, 21 Jan 2011 13:25:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[AWL=0.600, 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 Vd3rvL2-9qnK for ; Fri, 21 Jan 2011 13:25:17 -0800 (PST) Received: from smtp1.pacifier.net (smtp1.pacifier.net [64.255.237.171]) by core3.amsl.com (Postfix) with ESMTP id EB3593A6823 for ; Fri, 21 Jan 2011 13:25:16 -0800 (PST) Received: from TITUS (static-66-14-119-7.bdsl.verizon.net [66.14.119.7]) (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 2A9866EF47; Fri, 21 Jan 2011 13:28:02 -0800 (PST) From: "Jim Schaad" To: "Sam Hartman" Date: Fri, 21 Jan 2011 13:46:33 -0800 Message-ID: <021f01cbb9b4$accb7d60$06627820$@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: Acu5suEV15MAh75RQ7O8zIBHtwa3FA== Content-Language: en-us Cc: abfab@ietf.org Subject: [abfab] Comments on draft-ietf-abfab-aaa-saml-00 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, 21 Jan 2011 21:25:17 -0000 Sam, I think there is a disconnect between the picture and the text. The picture has a field called MT but the text has a field called Construct Type (CT). I believe that these are supposed to be the same fields and are mis-labeled. I am going to show Radius ignorance now, I assume there must be a rule that you cannot change the order of attributes in AAA, otherwise just a simple concatenation would not work. Is there a rule or assumption that all of the parts of a fragmented attribute would be contiguous? I think that for completeness we should be able to have multiple SAML elements present as attributes. This would require either an intervening other element or the ability to distinguish between continued items and first time items. Should this be done by making four elements rather than just two? Or by length prefixing the construct field? What do you think the level of review that needs to be added for additional elements? Do we need to further refine the range of construct numbers to have private and RFC required numbers? Please number your TBD values so that I can distinguish between them without having to think. Is there a reason to label this as being SAML specific rather than just letting it be XML values and letting the construct type identify the type of values? Would it make sense to create a new CT value for just carrying an SAML assertion which is not part of a request or response? Doing so would allow for one to toss in arbitrary (and hopefully related) items that were not actually asked for. Jim From cantor.2@osu.edu Fri Jan 21 13:35:32 2011 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 2593D3A6964 for ; Fri, 21 Jan 2011 13:35:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.574 X-Spam-Level: X-Spam-Status: No, score=-3.574 tagged_above=-999 required=5 tests=[AWL=0.025, 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 It2WuH61Lsu1 for ; Fri, 21 Jan 2011 13:35:31 -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 251863A6945 for ; Fri, 21 Jan 2011 13:35:31 -0800 (PST) Received: from CIO-TNC-HT06.osuad.osu.edu ([164.107.81.172]) by defang3.it.ohio-state.edu (8.13.7/8.13.1) with ESMTP id p0LLcEwt017735; Fri, 21 Jan 2011 16:38:14 -0500 Received: from CIO-KRC-D1MBX01.osuad.osu.edu ([fe80::450b:35e6:80f4:f3e0]) by CIO-TNC-HT06.osuad.osu.edu ([fe80::8c6c:9f26:5aa2:4458%25]) with mapi; Fri, 21 Jan 2011 16:35:34 -0500 From: "Cantor, Scott E." To: Jim Schaad Thread-Topic: [abfab] Comments on draft-ietf-abfab-aaa-saml-00 Thread-Index: Acu5suEV15MAh75RQ7O8zIBHtwa3FAAAHA7w Date: Fri, 21 Jan 2011 21:38:14 +0000 Message-ID: <7EE86E89365CA94F8E7B8251F926071004F734@CIO-KRC-D1MBX01.osuad.osu.edu> References: <021f01cbb9b4$accb7d60$06627820$@augustcellars.com> In-Reply-To: <021f01cbb9b4$accb7d60$06627820$@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.172; 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 Cc: "abfab@ietf.org" Subject: Re: [abfab] Comments on draft-ietf-abfab-aaa-saml-00 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, 21 Jan 2011 21:35:32 -0000 > Is there a reason to label this as being SAML specific rather than just > letting it be XML values and letting the construct type identify the type= of > values? Because it would be expensive to have to go parsing things just to find the= one you knew how to handle. Same reason most XML vocabularies have their o= wn MIME types. -- Scott From hartmans@painless-security.com Fri Jan 21 13:41:46 2011 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 D20913A67F8 for ; Fri, 21 Jan 2011 13:41:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.274 X-Spam-Level: X-Spam-Status: No, score=-2.274 tagged_above=-999 required=5 tests=[AWL=-0.009, 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 cZ5gT36bxbBI for ; Fri, 21 Jan 2011 13:41:46 -0800 (PST) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by core3.amsl.com (Postfix) with ESMTP id 1E1B93A67C2 for ; Fri, 21 Jan 2011 13:41:45 -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 C429320271; Fri, 21 Jan 2011 16:42:43 -0500 (EST) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 17ADC432C; Fri, 21 Jan 2011 16:44:21 -0500 (EST) From: Sam Hartman To: "Cantor\, Scott E." References: <021f01cbb9b4$accb7d60$06627820$@augustcellars.com> <7EE86E89365CA94F8E7B8251F926071004F734@CIO-KRC-D1MBX01.osuad.osu.edu> Date: Fri, 21 Jan 2011 16:44:21 -0500 In-Reply-To: <7EE86E89365CA94F8E7B8251F926071004F734@CIO-KRC-D1MBX01.osuad.osu.edu> (Scott E. Cantor's message of "Fri, 21 Jan 2011 21:38:14 +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] Comments on draft-ietf-abfab-aaa-saml-00 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, 21 Jan 2011 21:41:46 -0000 [Jim, your mail server is rejecting all my messages, so note that I've chosen to not send some private comments I would have otherwise sent you.] >>>>> "Cantor," == Cantor, Scott E writes: >> Is there a reason to label this as being SAML specific rather >> than just letting it be XML values and letting the construct type >> identify the type of values? Cantor,> Because it would be expensive to have to go parsing things Cantor,> just to find the one you knew how to handle. Same reason Cantor,> most XML vocabularies have their own MIME types. Also, we're going to need to attach processing semantics here, like the discussion of technical trust we've been having. Those semantics are very much SAML specific. From ietf@augustcellars.com Fri Jan 21 14:04:43 2011 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 E010B3A6803 for ; Fri, 21 Jan 2011 14:04:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=0.300, 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 0ftdyCeS-w9O for ; Fri, 21 Jan 2011 14:04:43 -0800 (PST) Received: from new-smtp02.pacifier.net (new-smtp02.pacifier.net [64.255.237.176]) by core3.amsl.com (Postfix) with ESMTP id 3ABB13A67EC for ; Fri, 21 Jan 2011 14:04:43 -0800 (PST) Received: from TITUS (static-66-14-119-7.bdsl.verizon.net [66.14.119.7]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by new-smtp02.pacifier.net (Postfix) with ESMTPSA id 56F882CA1F; Fri, 21 Jan 2011 14:07:30 -0800 (PST) From: "Jim Schaad" To: "'Cantor, Scott E.'" References: <021f01cbb9b4$accb7d60$06627820$@augustcellars.com> <7EE86E89365CA94F8E7B8251F926071004F734@CIO-KRC-D1MBX01.osuad.osu.edu> In-Reply-To: <7EE86E89365CA94F8E7B8251F926071004F734@CIO-KRC-D1MBX01.osuad.osu.edu> Date: Fri, 21 Jan 2011 14:26:01 -0800 Message-ID: <022901cbb9ba$2f81c340$8e8549c0$@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: AQFaRNpRLCJj/VeiMdb6V3BhuMbbmgG8DUVolLEJ/TA= Content-Language: en-us Cc: abfab@ietf.org Subject: Re: [abfab] Comments on draft-ietf-abfab-aaa-saml-00 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, 21 Jan 2011 22:04:44 -0000 Scott, What I suggested was that the overall attribute be allowed to carry arbitrary XML rather than be restricted to SAML. It would still have the CT field which could be used to identify more specifically what the XML content was. Jim > -----Original Message----- > From: Cantor, Scott E. [mailto:cantor.2@osu.edu] > Sent: Friday, January 21, 2011 1:38 PM > To: Jim Schaad > Cc: abfab@ietf.org > Subject: RE: [abfab] Comments on draft-ietf-abfab-aaa-saml-00 > > > Is there a reason to label this as being SAML specific rather than > > just letting it be XML values and letting the construct type identify > > the type of values? > > Because it would be expensive to have to go parsing things just to find the > one you knew how to handle. Same reason most XML vocabularies have > their own MIME types. > > -- Scott From cantor.2@osu.edu Fri Jan 21 14:24:43 2011 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 0B68C3A684B for ; Fri, 21 Jan 2011 14:24:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.575 X-Spam-Level: X-Spam-Status: No, score=-3.575 tagged_above=-999 required=5 tests=[AWL=0.024, 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 kt7DRMkijjSf for ; Fri, 21 Jan 2011 14:24:42 -0800 (PST) Received: from defang4.it.ohio-state.edu (defang4.it.ohio-state.edu [128.146.216.84]) by core3.amsl.com (Postfix) with ESMTP id C49133A683C for ; Fri, 21 Jan 2011 14:24:41 -0800 (PST) Received: from CIO-TNC-HT05.osuad.osu.edu (cio-tnc-ht05.osuad.osu.edu [164.107.81.168]) by defang4.it.ohio-state.edu (8.13.1/8.13.1) with ESMTP id p0LMRPHV003129; Fri, 21 Jan 2011 17:27:25 -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; Fri, 21 Jan 2011 17:24:02 -0500 From: "Cantor, Scott E." To: Jim Schaad Thread-Topic: [abfab] Comments on draft-ietf-abfab-aaa-saml-00 Thread-Index: Acu5suEV15MAh75RQ7O8zIBHtwa3FAAAHA7wAAwxk4AACoZHcA== Date: Fri, 21 Jan 2011 22:26:43 +0000 Message-ID: <7EE86E89365CA94F8E7B8251F926071004F776@CIO-KRC-D1MBX01.osuad.osu.edu> References: <021f01cbb9b4$accb7d60$06627820$@augustcellars.com> <7EE86E89365CA94F8E7B8251F926071004F734@CIO-KRC-D1MBX01.osuad.osu.edu> <022901cbb9ba$2f81c340$8e8549c0$@augustcellars.com> In-Reply-To: <022901cbb9ba$2f81c340$8e8549c0$@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.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.84 Cc: "abfab@ietf.org" Subject: Re: [abfab] Comments on draft-ietf-abfab-aaa-saml-00 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, 21 Jan 2011 22:24:43 -0000 > What I suggested was that the overall attribute be allowed to carry > arbitrary XML rather than be restricted to SAML. It would still have the= CT > field which could be used to identify more specifically what the XML cont= ent > was. Doesn't that just create a second registry to maintain? You could stick URI= s into the CT field to avoid that, I suppose, but I think it just moves the= document into the position of managing a framework for all uses of XML in = RADIUS attributes, which is probably out of scope. -- Scott From hartmans@mit.edu Mon Jan 24 13:07:34 2011 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 B297D3A6AD5 for ; Mon, 24 Jan 2011 13:07:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.44 X-Spam-Level: X-Spam-Status: No, score=-102.44 tagged_above=-999 required=5 tests=[AWL=-0.775, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_210=0.6, 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 uzkcrq8nqgzr for ; Mon, 24 Jan 2011 13:07:34 -0800 (PST) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by core3.amsl.com (Postfix) with ESMTP id 8396A3A696B for ; Mon, 24 Jan 2011 13:07: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 0A43E2014E for ; Mon, 24 Jan 2011 16:08:40 -0500 (EST) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 788F6432C; Mon, 24 Jan 2011 16:10:14 -0500 (EST) Resent-To: abfab@ietf.org Resent-From: Sam Hartman Resent-Date: Mon, 24 Jan 2011 16:10:14 -0500 Resent-Message-ID: X-From-Line: nobody Mon Jan 24 16:05:42 2011 From: Sam Hartman To: abfab@ietf.org,Alan DeKok Date: Mon, 24 Jan 2011 16:05:42 -0500 Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) Lines: 50 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [abfab] What are our AAA attribute requirements 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, 24 Jan 2011 21:07:34 -0000 I've been in the middle of a discussion with Alan trying to figure out requirements for a RADIUS library for Moonshot to use. (Our current solution needs a bit of work) We were having a discussion surrounding RADIUS attribute dictionaries. Typically a RADIUs server or library has a dictionary that maps an attribute number to a name and gives the attribute a type such as integer, string or IP address. Alan points out that it would be easy to give the application the opaque RADIUS value but that if we need to decode the attribute in a manner specific to its type then the dictionary is required. RFC 2138 defines four types of data: strings, integers, IP addresses and times. (Additional types such as IPv6 prefixes are defined by later specifications.) In addition, there's a question about how multi-valued attributes are handled. For example, for the EAP messages and for our use of SAML, we'reassuming that the multiple values are concatenated. An alternative for some attributes would be to treat them as multiple values of a short attribute. I think the interpretation of RADIUS strings and opaque data would be the same as far as we're concerned. GSS-API buffers don't tend to have a trailing null in the C bindings, so I can't see a difference. Integers are MSB-first 32-bit quantities. As are IP addresses and times. So, we have a number of options: 1) Just give the application opaque data with a specific interpretation of multi-valued attributes we hard-code. 2) Require that the GSS-EAP implementation understand the type and multi-value semantics of anything it exposes. That's kind of undesirable because we want the GSS-EAP implementation to eventually be a component of the operating system and we expect deployments to extend the set of attributes thought the use of vendor-specific attributes. We expect facilities like Shibboleth to be able to map AAA attributes into local attributes under the control of a configuration file. 3) Encode the type into the attribute name exposed through GSS-API naming extensions. We'd need to decide how inquire_name_attrs works (an API for enumerating all the attributes an application may request.) It could assume things were strings but applications could request the attribute with a different type if they knew better. Comments very welcome. From lukeh@padl.com Mon Jan 24 13:25:08 2011 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 93E2F3A698D for ; Mon, 24 Jan 2011 13:25:08 -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 fYxBHR6IHvXD for ; Mon, 24 Jan 2011 13:25:07 -0800 (PST) Received: from us.padl.com (us.padl.com [216.154.215.154]) by core3.amsl.com (Postfix) with ESMTP id 79CF83A6AF5 for ; Mon, 24 Jan 2011 13:25:02 -0800 (PST) Received: by us.padl.com with ESMTP id p0OLRj9o010029; Mon, 24 Jan 2011 16:27:48 -0500 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Luke Howard In-Reply-To: Date: Tue, 25 Jan 2011 08:27:50 +1100 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Sam Hartman X-Mailer: Apple Mail (2.1082) X-SMTP-Vilter-Version: 1.3.6 X-Spamd-Symbols: 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] What are our AAA attribute requirements 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, 24 Jan 2011 21:25:08 -0000 > I think the interpretation of RADIUS strings and opaque data would be > the same as far as we're concerned. GSS-API buffers don't tend to have = a > trailing null in the C bindings, so I can't see a difference. Don't forget that get_attribute provides a display_value (printable = representation) and that this is supported in the Moonshot = implementation -- but requires the RADIUS library be configured with = dictionaries. value is always the raw data. > 2) Require that the GSS-EAP implementation understand the type and > multi-value semantics of anything it exposes. That's kind of = undesirable > because we want the GSS-EAP implementation to eventually be a = component > of the operating system and we expect deployments to extend the set of > attributes thought the use of vendor-specific attributes. We expect > facilities like Shibboleth to be able to map AAA attributes into local > attributes under the control of a configuration file. Isn't then the dictionary just another configuration file? > 3) Encode the type into the attribute name exposed through GSS-API > naming extensions. We'd need to decide how inquire_name_attrs works = (an > API for enumerating all the attributes an application may request.) It > could assume things were strings but applications could request the > attribute with a different type if they knew better. Seems less desirable. -- Luke= From hartmans@painless-security.com Mon Jan 24 13:29:38 2011 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 ABE363A698D for ; Mon, 24 Jan 2011 13:29:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.273 X-Spam-Level: X-Spam-Status: No, score=-2.273 tagged_above=-999 required=5 tests=[AWL=-0.008, 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 7Fo4o+CSA2tl for ; Mon, 24 Jan 2011 13:29:37 -0800 (PST) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by core3.amsl.com (Postfix) with ESMTP id 9D1D93A6987 for ; Mon, 24 Jan 2011 13:29:37 -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 1E00D2014E; Mon, 24 Jan 2011 16:30:43 -0500 (EST) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 7C4EC432C; Mon, 24 Jan 2011 16:32:17 -0500 (EST) From: Sam Hartman To: Luke Howard References: Date: Mon, 24 Jan 2011 16:32:17 -0500 In-Reply-To: (Luke Howard's message of "Tue, 25 Jan 2011 08:27:50 +1100") 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] What are our AAA attribute requirements 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, 24 Jan 2011 21:29:38 -0000 >>>>> "Luke" == Luke Howard writes: >> I think the interpretation of RADIUS strings and opaque data >> would be the same as far as we're concerned. GSS-API buffers >> don't tend to have a trailing null in the C bindings, so I can't >> see a difference. Luke> Don't forget that get_attribute provides a display_value Luke> (printable representation) and that this is supported in the Luke> Moonshot implementation -- but requires the RADIUS library be Luke> configured with dictionaries. value is always the raw data. Why do we (kitten--Nico, Leif and I) do these things to ourselves? >> 2) Require that the GSS-EAP implementation understand the type >> and multi-value semantics of anything it exposes. That's kind of >> undesirable because we want the GSS-EAP implementation to >> eventually be a component of the operating system and we expect >> deployments to extend the set of attributes thought the use of >> vendor-specific attributes. We expect facilities like Shibboleth >> to be able to map AAA attributes into local attributes under the >> control of a configuration file. Luke> Isn't then the dictionary just another configuration file? Yes. For that use it's probably OK. However it requires you get the dictionary set up correctly even if your application understands what RADIUS attribute it wants. >> 3) Encode the type into the attribute name exposed through >> GSS-API naming extensions. We'd need to decide how >> inquire_name_attrs works (an API for enumerating all the >> attributes an application may request.) It could assume things >> were strings but applications could request the attribute with a >> different type if they knew better. Luke> Seems less desirable. Agreed. From trscavo@gmail.com Mon Jan 24 13:32:55 2011 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 A9B573A698D for ; Mon, 24 Jan 2011 13:32:55 -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 Nt6EQwJHo5fV for ; Mon, 24 Jan 2011 13:32:54 -0800 (PST) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id B93BF3A6987 for ; Mon, 24 Jan 2011 13:32:53 -0800 (PST) Received: by fxm9 with SMTP id 9so4926848fxm.31 for ; Mon, 24 Jan 2011 13:35:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=xphjtfoVRWYnVmrIKcpgbLR5X0uVHmsnYwRJkT4Puho=; b=r1WJeUy91ECyX89Mgwlw3MRFXEKDCUex3Re8ofI+Ll7TLHbr5QyVNhRQh4nTdTGnam aQ5BoYJuoritdGWAH6v1DHTBeHv4KQb+Ded0G6d2dNWnp1HvPWFmbATG1ekbJLX5mNMo rAgnLhVPH3iQezTcAyJYk1WimXQtAiZeWvcYY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=g17sgFhw791da1aKyMWEjODMNi2w80anUxxvCkv3m05N4icPNSSUxtu53RdUcHALN5 MGgCD65n910x10z6zVYvB+IxGg0c+r4FljSA3YX5iPxgktRtwspDmlF8eKTGZvbr+RgZ wBD3808NrfP2HaK0NQqL+FiDmLFhHgLwWwQPI= MIME-Version: 1.0 Received: by 10.223.115.75 with SMTP id h11mr4805024faq.119.1295904948509; Mon, 24 Jan 2011 13:35:48 -0800 (PST) Received: by 10.223.87.6 with HTTP; Mon, 24 Jan 2011 13:35:48 -0800 (PST) In-Reply-To: References: Date: Mon, 24 Jan 2011 15:35:48 -0600 Message-ID: From: Tom Scavo To: Sam Hartman Content-Type: text/plain; charset=ISO-8859-1 Cc: abfab@ietf.org Subject: Re: [abfab] What are our AAA attribute requirements 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, 24 Jan 2011 21:32:56 -0000 On Mon, Jan 24, 2011 at 3:05 PM, Sam Hartman wrote: > > We expect > facilities like Shibboleth to be able to map AAA attributes into local > attributes under the control of a configuration file. It might be easier to consider all attribute values to be mere strings. Also, I think you should avoid an extra configuration file if at all possible. Just my two cents worth :-) Tom From cantor.2@osu.edu Mon Jan 24 13:42:33 2011 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 C43553A694F for ; Mon, 24 Jan 2011 13:42:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.576 X-Spam-Level: X-Spam-Status: No, score=-3.576 tagged_above=-999 required=5 tests=[AWL=0.023, 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 WK78vnXuP+nv for ; Mon, 24 Jan 2011 13:42:33 -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 CDA803A68EE for ; Mon, 24 Jan 2011 13:42:32 -0800 (PST) Received: from CIO-TNC-HT06.osuad.osu.edu ([164.107.81.172]) by defang3.it.ohio-state.edu (8.13.7/8.13.1) with ESMTP id p0OLjNju031480; Mon, 24 Jan 2011 16:45:23 -0500 Received: from CIO-KRC-D1MBX01.osuad.osu.edu ([fe80::450b:35e6:80f4:f3e0]) by CIO-TNC-HT06.osuad.osu.edu ([fe80::8c6c:9f26:5aa2:4458%25]) with mapi; Mon, 24 Jan 2011 16:42:31 -0500 From: "Cantor, Scott E." To: Sam Hartman , "abfab@ietf.org" , Alan DeKok Thread-Topic: [abfab] What are our AAA attribute requirements Thread-Index: AQHLvAq9bKFikKqQukCAaocy5+ye15Pgprcg Date: Mon, 24 Jan 2011 21:45:24 +0000 Message-ID: <7EE86E89365CA94F8E7B8251F9260710067BCC@CIO-KRC-D1MBX01.osuad.osu.edu> References: 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-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CanIt-Geo: ip=164.107.81.172; 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] What are our AAA attribute requirements 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, 24 Jan 2011 21:42:33 -0000 > 2) Require that the GSS-EAP implementation understand the type and > multi-value semantics of anything it exposes. That's kind of undesirable > because we want the GSS-EAP implementation to eventually be a component > of the operating system and we expect deployments to extend the set of > attributes thought the use of vendor-specific attributes. We expect > facilities like Shibboleth to be able to map AAA attributes into local > attributes under the control of a configuration file. I specifically have to know what formats, if any, I would need to implement= support within Shibboleth (or more accurately in an extension of it) for u= sing as input. I have been expecting to build something that operates on th= e GSS context via the naming extensions to pull out non-SAML information an= d be able to process it, but that obviously requires additional configurati= on of some sort. It seems like a bad thing to require that sort of configuration in both pla= ces, though. I was expecting that if Shibboleth was going to be chewing on = RADIUS attributes that there wouldn't need to be anything in the way of ext= ra configuration in the GSS layer to make them available. -- Scott From hartmans@mit.edu Mon Jan 24 13:03:05 2011 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 903443A693C for ; Mon, 24 Jan 2011 13:03:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.44 X-Spam-Level: X-Spam-Status: No, score=-102.44 tagged_above=-999 required=5 tests=[AWL=-0.775, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_210=0.6, 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 uKD7gd8MZjlk for ; Mon, 24 Jan 2011 13:03:04 -0800 (PST) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by core3.amsl.com (Postfix) with ESMTP id 2FAB83A6966 for ; Mon, 24 Jan 2011 13:03:04 -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 638682014E; Mon, 24 Jan 2011 16:04:09 -0500 (EST) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id F1AE1432C; Mon, 24 Jan 2011 16:05:42 -0500 (EST) From: Sam Hartman To: abfab@ietf.org,Alan DeKok Date: Mon, 24 Jan 2011 16:05:42 -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 X-Mailman-Approved-At: Mon, 24 Jan 2011 13:54:05 -0800 Subject: [abfab] What are our AAA attribute requirements 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, 24 Jan 2011 21:03:05 -0000 I've been in the middle of a discussion with Alan trying to figure out requirements for a RADIUS library for Moonshot to use. (Our current solution needs a bit of work) We were having a discussion surrounding RADIUS attribute dictionaries. Typically a RADIUs server or library has a dictionary that maps an attribute number to a name and gives the attribute a type such as integer, string or IP address. Alan points out that it would be easy to give the application the opaque RADIUS value but that if we need to decode the attribute in a manner specific to its type then the dictionary is required. RFC 2138 defines four types of data: strings, integers, IP addresses and times. (Additional types such as IPv6 prefixes are defined by later specifications.) In addition, there's a question about how multi-valued attributes are handled. For example, for the EAP messages and for our use of SAML, we'reassuming that the multiple values are concatenated. An alternative for some attributes would be to treat them as multiple values of a short attribute. I think the interpretation of RADIUS strings and opaque data would be the same as far as we're concerned. GSS-API buffers don't tend to have a trailing null in the C bindings, so I can't see a difference. Integers are MSB-first 32-bit quantities. As are IP addresses and times. So, we have a number of options: 1) Just give the application opaque data with a specific interpretation of multi-valued attributes we hard-code. 2) Require that the GSS-EAP implementation understand the type and multi-value semantics of anything it exposes. That's kind of undesirable because we want the GSS-EAP implementation to eventually be a component of the operating system and we expect deployments to extend the set of attributes thought the use of vendor-specific attributes. We expect facilities like Shibboleth to be able to map AAA attributes into local attributes under the control of a configuration file. 3) Encode the type into the attribute name exposed through GSS-API naming extensions. We'd need to decide how inquire_name_attrs works (an API for enumerating all the attributes an application may request.) It could assume things were strings but applications could request the attribute with a different type if they knew better. Comments very welcome. From hartmans@painless-security.com Mon Jan 24 13:57:50 2011 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 1EFAB3A698E for ; Mon, 24 Jan 2011 13:57:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.273 X-Spam-Level: X-Spam-Status: No, score=-2.273 tagged_above=-999 required=5 tests=[AWL=-0.008, 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 pEKqLU4WyW36 for ; Mon, 24 Jan 2011 13:57:49 -0800 (PST) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by core3.amsl.com (Postfix) with ESMTP id 72D063A698D for ; Mon, 24 Jan 2011 13:57: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 DA69120222 for ; Mon, 24 Jan 2011 16:58:52 -0500 (EST) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 4C281432C; Mon, 24 Jan 2011 17:00:27 -0500 (EST) From: Sam Hartman To: abfab@ietf.org Date: Mon, 24 Jan 2011 17:00:27 -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] exported name format 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, 24 Jan 2011 21:57:50 -0000 Should our exported name format be any different than the string representation of our mechanism name? Section 3.2 of RFC 2743 defines the wrapping for our name form, but I'm wondering what should go in the wrapping. Unless someone thinks something more needs to go in I think it should be just the string form of the MN. --Sam From hartmans@mit.edu Mon Jan 24 13:59:14 2011 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 3D85E3A696F for ; Mon, 24 Jan 2011 13:59:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.273 X-Spam-Level: X-Spam-Status: No, score=-2.273 tagged_above=-999 required=5 tests=[AWL=-0.008, 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 UtYjtah-5y5k for ; Mon, 24 Jan 2011 13:59:13 -0800 (PST) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by core3.amsl.com (Postfix) with ESMTP id 933883A698D for ; Mon, 24 Jan 2011 13:59:13 -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 2C2E020222 for ; Mon, 24 Jan 2011 17:00:19 -0500 (EST) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 9B8D7432C; Mon, 24 Jan 2011 17:01:53 -0500 (EST) From: Sam Hartman To: abfab@ietf.org Date: Mon, 24 Jan 2011 16:59:03 -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] OIDs 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, 24 Jan 2011 21:59:14 -0000 #The chairs were going to look into OIDs at the last IETF. What's the status of that? So far, I believe we need an OID for: 1) the mechanism 2) A name type for importing the string representation of a gss-eap name It seems likely that additional oids will be needed in the future. From hartmans@painless-security.com Mon Jan 24 14:00:25 2011 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 5F0983A69A4 for ; Mon, 24 Jan 2011 14:00:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.273 X-Spam-Level: X-Spam-Status: No, score=-2.273 tagged_above=-999 required=5 tests=[AWL=-0.008, 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 5fkToyjWII1r for ; Mon, 24 Jan 2011 14:00:24 -0800 (PST) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by core3.amsl.com (Postfix) with ESMTP id AC6853A696F for ; Mon, 24 Jan 2011 14:00:24 -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 26AB720222; Mon, 24 Jan 2011 17:01:30 -0500 (EST) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 984E9432C; Mon, 24 Jan 2011 17:03:04 -0500 (EST) From: Sam Hartman To: Tom Scavo References: Date: Mon, 24 Jan 2011 17:03:04 -0500 In-Reply-To: (Tom Scavo's message of "Mon, 24 Jan 2011 15:35: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 Subject: Re: [abfab] What are our AAA attribute requirements 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, 24 Jan 2011 22:00:25 -0000 >>>>> "Tom" == Tom Scavo writes: Tom> On Mon, Jan 24, 2011 at 3:05 PM, Sam Hartman Tom> wrote: >> > We expect facilities like Shibboleth to be able to map AAA attributes >> into local attributes under the control of a configuration file. Tom> It might be easier to consider all attribute values to be mere Tom> strings. What does it mean to consider all attributes strings? From cantor.2@osu.edu Mon Jan 24 14:03:33 2011 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 DFED33A698E for ; Mon, 24 Jan 2011 14:03:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.577 X-Spam-Level: X-Spam-Status: No, score=-3.577 tagged_above=-999 required=5 tests=[AWL=0.022, 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 S8JsDKvGjnp0 for ; Mon, 24 Jan 2011 14:03:33 -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 DA2583A696F for ; Mon, 24 Jan 2011 14:03:32 -0800 (PST) Received: from CIO-KRC-HT01.osuad.osu.edu ([164.107.81.38]) by defang16.it.ohio-state.edu (8.13.7/8.13.1) with ESMTP id p0OM6RpJ003364; Mon, 24 Jan 2011 17:06:27 -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; Mon, 24 Jan 2011 17:03:33 -0500 From: "Cantor, Scott E." To: Sam Hartman , Tom Scavo Thread-Topic: [abfab] What are our AAA attribute requirements Thread-Index: AQHLvAq9bKFikKqQukCAaocy5+ye15Pg+RAAgAAHngD//60dAA== Date: Mon, 24 Jan 2011 22:06:24 +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.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.130 Cc: "abfab@ietf.org" Subject: Re: [abfab] What are our AAA attribute requirements 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, 24 Jan 2011 22:03:34 -0000 >What does it mean to consider all attributes strings? In XML, it just means treating everything as text and ignoring data typing. It doesn't work when the data representation isn't textual with a self-descriptive character encoding like XML's. -- Scott From leifj@sunet.se Mon Jan 24 14:04:27 2011 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 8DDAE3A696F for ; Mon, 24 Jan 2011 14:04:27 -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 6a8Q9MmslkLG for ; Mon, 24 Jan 2011 14:04:26 -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 48D8B3A6968 for ; Mon, 24 Jan 2011 14:04:26 -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 p0OM7E3c029804 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 24 Jan 2011 23:07:16 +0100 (CET) Message-ID: <4D3DF812.80108@sunet.se> Date: Mon, 24 Jan 2011 23:07:14 +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] OIDs 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, 24 Jan 2011 22:04:27 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 01/24/2011 10:59 PM, Sam Hartman wrote: > #The chairs were going to look into OIDs at the last IETF. > What's the status of that? > > So far, I believe we need an OID for: > > 1) the mechanism > > 2) A name type for importing the string representation of a gss-eap name > > It seems likely that additional oids will be needed in the future. As I recall we talked to Sean and came to the conclusion that we can't ask the IANA to pre-allocate OIDs for us but I may be mis-remembering this. Cheers Leif -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk09+BEACgkQ8Jx8FtbMZneYqQCgoVyOWJuf0dkWrelBU7nfSENa maYAnR3UQwqyybXbUYqub2s3eKWMfbIn =yaUB -----END PGP SIGNATURE----- From leifj@sunet.se Mon Jan 24 14:57:12 2011 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 29E153A69B5 for ; Mon, 24 Jan 2011 14:57: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=[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 IY93qaKACoqc for ; Mon, 24 Jan 2011 14:57:11 -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 EC9FE3A69B4 for ; Mon, 24 Jan 2011 14:57:10 -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 p0ON02so014643 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 25 Jan 2011 00:00:05 +0100 (CET) Message-ID: <4D3E0472.50204@sunet.se> Date: Tue, 25 Jan 2011 00:00:02 +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] What are our AAA attribute requirements 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, 24 Jan 2011 22:57:12 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > Why do we (kitten--Nico, Leif and I) do these things to ourselves? As a former colleague of mine said when I, upon the birth of his 5th child, asked him "what were you thinking?", replied "it seemed like a good idea at the time". Cheers Leif -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk0+BHIACgkQ8Jx8FtbMZnf1+gCcCO3qI0Ze399pZUSDDV29PYfo 3LoAnRSBmoBDkHdPkkBaRZXUNppZrNa8 =pLP3 -----END PGP SIGNATURE----- From hartmans@painless-security.com Mon Jan 24 15:41:42 2011 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 236613A69B4 for ; Mon, 24 Jan 2011 15:41:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.273 X-Spam-Level: X-Spam-Status: No, score=-2.273 tagged_above=-999 required=5 tests=[AWL=-0.008, 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 Aox9TpgKMoC2 for ; Mon, 24 Jan 2011 15:41:41 -0800 (PST) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by core3.amsl.com (Postfix) with ESMTP id 6E2C13A6995 for ; Mon, 24 Jan 2011 15:41:41 -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 C91132022C; Mon, 24 Jan 2011 18:42:46 -0500 (EST) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 3AF30432C; Mon, 24 Jan 2011 18:44:21 -0500 (EST) From: Sam Hartman To: Leif Johansson References: <4D3E0472.50204@sunet.se> Date: Mon, 24 Jan 2011 18:44:21 -0500 In-Reply-To: <4D3E0472.50204@sunet.se> (Leif Johansson's message of "Tue, 25 Jan 2011 00:00:02 +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] What are our AAA attribute requirements 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, 24 Jan 2011 23:41:42 -0000 >>>>> "Leif" == Leif Johansson writes: >> Why do we (kitten--Nico, Leif and I) do these things to >> ourselves? Leif> As a former colleague of mine said when I, upon the birth of Leif> his 5th child, asked him "what were you thinking?", replied Leif> "it seemed like a good idea at the time". To be fair, thinking for 30 minutes about this, it isn't all that bad of an idea as an optional facility. --Sam From aland@deployingradius.com Mon Jan 24 18:41:32 2011 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 B88743A6946 for ; Mon, 24 Jan 2011 18:41:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.582 X-Spam-Level: X-Spam-Status: No, score=-102.582 tagged_above=-999 required=5 tests=[AWL=0.017, 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 RTsQNiAE2o8K for ; Mon, 24 Jan 2011 18:41:32 -0800 (PST) Received: from liberty.deployingradius.com (liberty.deployingradius.com [88.191.76.128]) by core3.amsl.com (Postfix) with ESMTP id D61133A6B5B for ; Mon, 24 Jan 2011 18:41:31 -0800 (PST) Message-ID: <4D3E3904.4070302@deployingradius.com> Date: Tue, 25 Jan 2011 03:44:20 +0100 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Sam Hartman References: In-Reply-To: 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] What are our AAA attribute requirements 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, 25 Jan 2011 02:41:32 -0000 Sam Hartman wrote: > Luke> Isn't then the dictionary just another configuration file? > Yes. For that use it's probably OK. However it requires you get the > dictionary set up correctly even if your application understands what > RADIUS attribute it wants. If the application understands the attributes it wants, the dictionaries can be statically defined. The dictionaries are mainly used by *administrators* to create authorization policies. "If I see FOO with value BAR, do something". The definition of FOO is in the dictionary, which maps bytes in the RADIUS packet to "data type for BAR". The "do something" part is controlled by the administrator, and can be pretty much anything from "run a shell script" to "return other attributes". RADIUS clients have traditionally been very limited. They request a particular kind of authorization/authentication. They receive either a NAK or an ACK. The ACK contains specific details about the requested authorization, such as IP address assignment. If the ACK contains authorizations for things the client *didn't* ask for, the client ignores them, because the authorizations are inappropriate. Even if the client understands the attributes, it doesn't know what to do with them, because they don't fit within an existing authorization framework. Alan DeKok. From lukeh@padl.com Mon Jan 24 20:16:45 2011 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 272F53A6A3D for ; Mon, 24 Jan 2011 20:16:45 -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 Kth+6rLp2jIt for ; Mon, 24 Jan 2011 20:16:44 -0800 (PST) Received: from us.padl.com (us.padl.com [216.154.215.154]) by core3.amsl.com (Postfix) with ESMTP id 5A6703A69B4 for ; Mon, 24 Jan 2011 20:16:44 -0800 (PST) Received: by us.padl.com with ESMTP id p0P4JRRT027930; Mon, 24 Jan 2011 23:19:30 -0500 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Luke Howard In-Reply-To: Date: Tue, 25 Jan 2011 15:19:32 +1100 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Sam Hartman 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.4 Cc: abfab@ietf.org Subject: Re: [abfab] OIDs 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, 25 Jan 2011 04:16:45 -0000 On 25/01/2011, at 8:59 AM, Sam Hartman wrote: > #The chairs were going to look into OIDs at the last IETF. > What's the status of that? >=20 > So far, I believe we need an OID for: >=20 > 1) the mechanism >=20 > 2) A name type for importing the string representation of a gss-eap = name That's all I have (modulo mechanisms are suffixed with encryption type). There are also a bunch of implementation-specific OIDs for = set_cred_option but we don't need to standardise those. -- Luke= From lear@cisco.com Tue Jan 25 03:21:12 2011 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 290B63A6AC2 for ; Tue, 25 Jan 2011 03:21:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.182 X-Spam-Level: X-Spam-Status: No, score=-110.182 tagged_above=-999 required=5 tests=[AWL=0.417, 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 gKjYIpvkPwYF for ; Tue, 25 Jan 2011 03:21:10 -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 8F45B3A683F for ; Tue, 25 Jan 2011 03:21:10 -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: Av0EAJ9BPk2Q/khNgWdsb2JhbACEE6BcFgEWIiShJ4pfkGGBI4M4dASMKA Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-1.cisco.com with ESMTP; 25 Jan 2011 11:24:07 +0000 Received: from ams3-vpn-dhcp4915.cisco.com (ams3-vpn-dhcp4915.cisco.com [10.61.83.50]) by ams-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p0PBO7JG008981; Tue, 25 Jan 2011 11:24:07 GMT Message-ID: <4D3EB2D3.8000604@cisco.com> Date: Tue, 25 Jan 2011 12:24:03 +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: Leif Johansson References: <4D3DF812.80108@sunet.se> In-Reply-To: <4D3DF812.80108@sunet.se> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: abfab@ietf.org Subject: Re: [abfab] OIDs 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, 25 Jan 2011 11:21:12 -0000 Leif, Can you check this. There is some leeway given for emergent work from the IETF. But it should be baked at least a little. Eliot On 1/24/11 11:07 PM, Leif Johansson wrote: > On 01/24/2011 10:59 PM, Sam Hartman wrote: > > #The chairs were going to look into OIDs at the last IETF. > > What's the status of that? > > > So far, I believe we need an OID for: > > > 1) the mechanism > > > 2) A name type for importing the string representation of a gss-eap name > > > It seems likely that additional oids will be needed in the future. > > As I recall we talked to Sean and came to the conclusion that we can't > ask the IANA to pre-allocate OIDs for us but I may be mis-remembering > this. > > Cheers Leif _______________________________________________ abfab mailing list abfab@ietf.org https://www.ietf.org/mailman/listinfo/abfab From hartmans@painless-security.com Tue Jan 25 05:15:50 2011 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 9DD2A3A69E2 for ; Tue, 25 Jan 2011 05:15:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.273 X-Spam-Level: X-Spam-Status: No, score=-2.273 tagged_above=-999 required=5 tests=[AWL=-0.008, 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 K0AfwPYGrL6e for ; Tue, 25 Jan 2011 05:15:50 -0800 (PST) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by core3.amsl.com (Postfix) with ESMTP id ECCB73A686D for ; Tue, 25 Jan 2011 05:15: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 2EB942022C; Tue, 25 Jan 2011 08:16:54 -0500 (EST) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 24D0C432C; Tue, 25 Jan 2011 08:18:27 -0500 (EST) From: Sam Hartman To: Alan DeKok References: <4D3E3904.4070302@deployingradius.com> Date: Tue, 25 Jan 2011 08:18:27 -0500 In-Reply-To: <4D3E3904.4070302@deployingradius.com> (Alan DeKok's message of "Tue, 25 Jan 2011 03:44: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] What are our AAA attribute requirements 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, 25 Jan 2011 13:15:50 -0000 >>>>> "Alan" == Alan DeKok writes: Alan> Sam Hartman wrote: Luke> Isn't then the dictionary just another configuration file? >> Yes. For that use it's probably OK. However it requires you get >> the dictionary set up correctly even if your application >> understands what RADIUS attribute it wants. Alan> If the application understands the attributes it wants, the Alan> dictionaries can be statically defined. As I mentioned, the GSS-API naming extensions API does not present a way for an application to give a dictionary to a RADIUS library. So, if we were designing something for RADIUS instead of working with an existing abstract interface, you would be correct. From leifj@sunet.se Tue Jan 25 05:22:19 2011 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 0D0A63A6BC0 for ; Tue, 25 Jan 2011 05:22:19 -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 sJgTTo4WP2Ic for ; Tue, 25 Jan 2011 05:22:17 -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 1FB8A28B56A for ; Tue, 25 Jan 2011 05:22:14 -0800 (PST) Received: from [192.36.125.230] (dhcp.pilsnet.sunet.se [192.36.125.230]) (authenticated bits=0) by backup-server.nordu.net (8.14.3/8.14.3) with ESMTP id p0PDP47I004925 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 25 Jan 2011 14:25:07 +0100 (CET) Message-ID: <4D3ECF30.7050503@sunet.se> Date: Tue, 25 Jan 2011 14:25:04 +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: Eliot Lear References: <4D3DF812.80108@sunet.se> <4D3EB2D3.8000604@cisco.com> In-Reply-To: <4D3EB2D3.8000604@cisco.com> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: abfab@ietf.org Subject: Re: [abfab] OIDs 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, 25 Jan 2011 13:22:19 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 01/25/2011 12:24 PM, Eliot Lear wrote: > Leif, > > Can you check this. There is some leeway given for emergent work from > the IETF. But it should be baked at least a little. > I'm on it. The initial response from Sean is that we can ask IANA for an experimental ARC. Do we want that even if it means we may have to change things as things get published? Cheers Leif -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk0+zzAACgkQ8Jx8FtbMZncrBwCgiu5LBk1mIdJW3R+9RakWWcQM gsEAn1ZWKBrawkM5fEZe7I/rfws+y3F1 =XCc3 -----END PGP SIGNATURE----- From turners@ieca.com Tue Jan 25 05:51:48 2011 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 BEDCE3A68C6 for ; Tue, 25 Jan 2011 05:51:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.345 X-Spam-Level: X-Spam-Status: No, score=-102.345 tagged_above=-999 required=5 tests=[AWL=0.253, BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001, 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 B9wzd6whs3xf for ; Tue, 25 Jan 2011 05:51:47 -0800 (PST) Received: from nm1-vm0.bullet.mail.ne1.yahoo.com (nm1-vm0.bullet.mail.ne1.yahoo.com [98.138.91.74]) by core3.amsl.com (Postfix) with SMTP id 9E86E3A6858 for ; Tue, 25 Jan 2011 05:51:47 -0800 (PST) Received: from [98.138.90.48] by nm1.bullet.mail.ne1.yahoo.com with NNFMP; 25 Jan 2011 13:54:45 -0000 Received: from [98.138.89.234] by tm1.bullet.mail.ne1.yahoo.com with NNFMP; 25 Jan 2011 13:54:45 -0000 Received: from [127.0.0.1] by omp1049.mail.ne1.yahoo.com with NNFMP; 25 Jan 2011 13:54:45 -0000 X-Yahoo-Newman-Id: 296107.38660.bm@omp1049.mail.ne1.yahoo.com Received: (qmail 2732 invoked from network); 25 Jan 2011 13:54:44 -0000 Received: from thunderfish.local (turners@71.191.5.27 with plain) by smtp111.biz.mail.mud.yahoo.com with SMTP; 25 Jan 2011 05:54:44 -0800 PST X-Yahoo-SMTP: ZrP3VLSswBDL75pF8ymZHDSu9B.vcMfDPgLJ X-YMail-OSG: aUlTPkgVM1nnoDsD.Ghd6MrkLFVrb00NPIm3OBvfW8Yt5Yw .XXzlteLDYdh7ONnFnvo6OwJsN2dy5d1nyR_p.5iYohR5E.9P2RCNLj4uIgl VjtoUWy6h_22UjEfkCY5FlC4i0.wcaQhbIQo_k8b4IPwutiYru4irVKWGEta dHqw35fznCMxRZbNoJT9q8R4erDB5pzDBeTLIS1Ln1uYPqn6gaLzL1XMEw8g gzHYpukPvxTUODA6KSkRdTMyfpQY7CMhmHwaMu9HMvqrzQwDDg5Uu0vhnIrv T5FqwQKiqz4Zo.YqrB5M8VBXWYqd3m_L4Hw-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4D3ED622.7000000@ieca.com> Date: Tue, 25 Jan 2011 08:54:42 -0500 From: Sean Turner 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: Leif Johansson References: <4D3DF812.80108@sunet.se> <4D3EB2D3.8000604@cisco.com> <4D3ECF30.7050503@sunet.se> In-Reply-To: <4D3ECF30.7050503@sunet.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: abfab@ietf.org Subject: Re: [abfab] OIDs 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, 25 Jan 2011 13:51:48 -0000 My thinking is that we get a stable abfab arc and then set up arcs under it. One being experimental. spt On 1/25/11 8:25 AM, Leif Johansson wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 01/25/2011 12:24 PM, Eliot Lear wrote: >> Leif, >> >> Can you check this. There is some leeway given for emergent work from >> the IETF. But it should be baked at least a little. >> > > I'm on it. The initial response from Sean is that we can ask IANA for > an experimental ARC. Do we want that even if it means we may have to > change things as things get published? > > Cheers Leif > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.10 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > > iEYEARECAAYFAk0+zzAACgkQ8Jx8FtbMZncrBwCgiu5LBk1mIdJW3R+9RakWWcQM > gsEAn1ZWKBrawkM5fEZe7I/rfws+y3F1 > =XCc3 > -----END PGP SIGNATURE----- > _______________________________________________ > abfab mailing list > abfab@ietf.org > https://www.ietf.org/mailman/listinfo/abfab > From leifj@sunet.se Tue Jan 25 06:05:43 2011 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 C80093A6872 for ; Tue, 25 Jan 2011 06:05:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.203 X-Spam-Level: X-Spam-Status: No, score=-1.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396] 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 N4ND2gLqXDPp for ; Tue, 25 Jan 2011 06:05:42 -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 9C1233A6858 for ; Tue, 25 Jan 2011 06:05:42 -0800 (PST) Received: from kerio.nordu.net (kerio.nordu.net [109.105.111.52]) by backup-server.nordu.net (8.14.3/8.14.3) with ESMTP id p0PE8UJI012514 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 25 Jan 2011 15:08:33 +0100 (CET) Received: from [212.247.15.226] ([212.247.15.226]) by kerio.nordu.net; Tue, 25 Jan 2011 15:08:29 +0100 References: <4D3DF812.80108@sunet.se> <4D3EB2D3.8000604@cisco.com> <4D3ECF30.7050503@sunet.se> <4D3ED622.7000000@ieca.com> Content-Transfer-Encoding: quoted-printable From: "Leif Johansson" Content-Type: text/plain; charset=us-ascii In-Reply-To: <4D3ED622.7000000@ieca.com> Message-Id: Date: Tue, 25 Jan 2011 15:08:20 +0100 To: Sean Turner Mime-Version: 1.0 (iPhone Mail 8C148) Cc: "abfab@ietf.org" Subject: Re: [abfab] OIDs 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, 25 Jan 2011 14:05:43 -0000 If nobody objects: make it so! 25 jan 2011 kl. 14:55 skrev "Sean Turner" : > My thinking is that we get a stable abfab arc and then set up arcs under i= t. One being experimental. >=20 > spt >=20 > On 1/25/11 8:25 AM, Leif Johansson wrote: >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >>=20 >> On 01/25/2011 12:24 PM, Eliot Lear wrote: >>> Leif, >>>=20 >>> Can you check this. There is some leeway given for emergent work from >>> the IETF. But it should be baked at least a little. >>>=20 >>=20 >> I'm on it. The initial response from Sean is that we can ask IANA for >> an experimental ARC. Do we want that even if it means we may have to >> change things as things get published? >>=20 >> Cheers Leif >> -----BEGIN PGP SIGNATURE----- >> Version: GnuPG v1.4.10 (GNU/Linux) >> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ >>=20 >> iEYEARECAAYFAk0+zzAACgkQ8Jx8FtbMZncrBwCgiu5LBk1mIdJW3R+9RakWWcQM >> gsEAn1ZWKBrawkM5fEZe7I/rfws+y3F1 >> =3DXCc3 >> -----END PGP SIGNATURE----- >> _______________________________________________ >> abfab mailing list >> abfab@ietf.org >> https://www.ietf.org/mailman/listinfo/abfab >>=20 From hartmans@painless-security.com Tue Jan 25 06:09:49 2011 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 3D6223A6AC4 for ; Tue, 25 Jan 2011 06:09:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.272 X-Spam-Level: X-Spam-Status: No, score=-2.272 tagged_above=-999 required=5 tests=[AWL=-0.007, 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 Bz4ob40Rf-qG for ; Tue, 25 Jan 2011 06:09:48 -0800 (PST) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by core3.amsl.com (Postfix) with ESMTP id 915963A68E0 for ; Tue, 25 Jan 2011 06:09:48 -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 55D2F20246; Tue, 25 Jan 2011 09:10:53 -0500 (EST) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 5A018432C; Tue, 25 Jan 2011 09:12:26 -0500 (EST) From: Sam Hartman To: Leif Johansson References: <4D3DF812.80108@sunet.se> <4D3EB2D3.8000604@cisco.com> <4D3ECF30.7050503@sunet.se> Date: Tue, 25 Jan 2011 09:12:26 -0500 In-Reply-To: <4D3ECF30.7050503@sunet.se> (Leif Johansson's message of "Tue, 25 Jan 2011 14:25:04 +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] OIDs 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, 25 Jan 2011 14:09:49 -0000 >>>>> "Leif" == Leif Johansson writes: Leif> On 01/25/2011 12:24 PM, Eliot Lear wrote: >> Leif, >> >> Can you check this. There is some leeway given for emergent work >> from the IETF. But it should be baked at least a little. >> I'm on it. The initial response from Sean is that we can ask IANA for Leif> an experimental ARC. Do we want that even if it means we may Leif> have to change things as things get published? I think changing things as they get published would be fairly problematic. I'd much rather use non-IETF OIDs than live with that constraint. If we're forced to break backward compatibility then we'll have to evaluate whether the OID needs to change. Currently, I think the answer would be no; fairly soon, I think the answer would be yes. However I don't think it would be a big deal if we needed to burn a few codepoints in an ABFAB mechanisms oid arc. I also think it matters very little where that OID arc lives--IETF or not. From leifj@sunet.se Tue Jan 25 06:22:42 2011 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 13E6C3A67C3 for ; Tue, 25 Jan 2011 06:22:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[AWL=0.698, 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 D0CkyJc76iqi for ; Tue, 25 Jan 2011 06:22: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 9EF513A67B4 for ; Tue, 25 Jan 2011 06:22:40 -0800 (PST) Received: from [10.33.1.113] ([212.247.15.226]) (authenticated bits=0) by backup-server.nordu.net (8.14.3/8.14.3) with ESMTP id p0PEPUoa000536 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 25 Jan 2011 15:25:33 +0100 (CET) Message-ID: <4D3EDD5A.3050003@sunet.se> Date: Tue, 25 Jan 2011 15:25:30 +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: Sam Hartman References: <4D3DF812.80108@sunet.se> <4D3EB2D3.8000604@cisco.com> <4D3ECF30.7050503@sunet.se> In-Reply-To: X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: abfab@ietf.org Subject: Re: [abfab] OIDs 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, 25 Jan 2011 14:22:42 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > If we're forced to break backward compatibility then we'll have to > evaluate whether the OID needs to change. Currently, I think the answer > would be no; fairly soon, I think the answer would be yes. However I > don't think it would be a big deal if we needed to burn a few codepoints > in an ABFAB mechanisms oid arc. I also think it matters very little > where that OID arc lives--IETF or not. So basically your vote is on an enterprise arc. I'm not sure I understand the reasons why abfab has requirement that differ so much from any other IETF protocol where protocol numbers are typically allocated on publication of the RFC. Cheers Leif -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk0+3VYACgkQ8Jx8FtbMZnf8TACgoOWK1msFa1YikKESyyVAdPM7 EIYAoKGK1GRwtAUJmOmgwlSrRvPtDWCa =GCna -----END PGP SIGNATURE----- From lear@cisco.com Tue Jan 25 06:30:29 2011 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 DAAC83A67E7 for ; Tue, 25 Jan 2011 06:30:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.188 X-Spam-Level: X-Spam-Status: No, score=-110.188 tagged_above=-999 required=5 tests=[AWL=0.411, 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 I8nIqleDAtVs for ; Tue, 25 Jan 2011 06:30:29 -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 D7EE83A67E4 for ; Tue, 25 Jan 2011 06:30:28 -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: Av0EAH5tPk2Q/khMgWdsb2JhbACEEqBcFgEWIiShJ4pfkGaBI4M4dASMKA Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-2.cisco.com with ESMTP; 25 Jan 2011 14:33:26 +0000 Received: from ams3-vpn-dhcp4915.cisco.com (ams3-vpn-dhcp4915.cisco.com [10.61.83.50]) by ams-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p0PEXPQ4018458; Tue, 25 Jan 2011 14:33:25 GMT Message-ID: <4D3EDF31.5080500@cisco.com> Date: Tue, 25 Jan 2011 15:33: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: Leif Johansson References: <4D3DF812.80108@sunet.se> <4D3EB2D3.8000604@cisco.com> <4D3ECF30.7050503@sunet.se> <4D3EDD5A.3050003@sunet.se> In-Reply-To: <4D3EDD5A.3050003@sunet.se> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: abfab@ietf.org Subject: Re: [abfab] OIDs 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, 25 Jan 2011 14:30:30 -0000 On 1/25/11 3:25 PM, Leif Johansson wrote: > So basically your vote is on an enterprise arc. I'm not sure I > understand the reasons why abfab has requirement that differ so > much from any other IETF protocol where protocol numbers are > typically allocated on publication of the RFC. Neither do I but then I'm the guy who thought it was possible to get an early allocation from IANA for IETF protocol work. From turners@ieca.com Tue Jan 25 06:50:57 2011 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 0407E3A67E2 for ; Tue, 25 Jan 2011 06:50:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.536 X-Spam-Level: X-Spam-Status: No, score=-102.536 tagged_above=-999 required=5 tests=[AWL=0.062, BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001, 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 LL4-80GMxyUD for ; Tue, 25 Jan 2011 06:50:56 -0800 (PST) Received: from nm23.bullet.mail.ac4.yahoo.com (nm23.bullet.mail.ac4.yahoo.com [98.139.52.220]) by core3.amsl.com (Postfix) with SMTP id C80563A67E7 for ; Tue, 25 Jan 2011 06:50:55 -0800 (PST) Received: from [98.139.52.197] by nm23.bullet.mail.ac4.yahoo.com with NNFMP; 25 Jan 2011 14:53:50 -0000 Received: from [98.139.52.156] by tm10.bullet.mail.ac4.yahoo.com with NNFMP; 25 Jan 2011 14:52:50 -0000 Received: from [127.0.0.1] by omp1039.mail.ac4.yahoo.com with NNFMP; 25 Jan 2011 14:52:50 -0000 X-Yahoo-Newman-Id: 804028.28338.bm@omp1039.mail.ac4.yahoo.com Received: (qmail 80103 invoked from network); 25 Jan 2011 14:52:50 -0000 Received: from thunderfish.local (turners@71.191.5.27 with plain) by smtp112.biz.mail.re2.yahoo.com with SMTP; 25 Jan 2011 06:52:50 -0800 PST X-Yahoo-SMTP: ZrP3VLSswBDL75pF8ymZHDSu9B.vcMfDPgLJ X-YMail-OSG: gBdpfZkVM1krlS3MuCMJf60zZ.Sfi7U4m.oofIQGEnEGqd2 fuIiK_6D9cajXJLbCLjg4G4wQoxUeB2PbQBduHXtyXbMA89sq6VNiqajXOaF 0SSDZNcHofoXwb9cBtadSzym4QRecS9R_NjxwZNI742n3gFvqgDJSKj_aYNK AHTn8DyWf_BGmWJia.ZNCd3tu9oDyzXCcRCulkpusgh6iUKbrgR0XxAFDlLH .xdm.ebCYTrxRYpRzQt1he7o.T.ZpaD8V_.G6d1uuLaaqzrT5OgPHuV4- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4D3EE3C2.7050007@ieca.com> Date: Tue, 25 Jan 2011 09:52:50 -0500 From: Sean Turner 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: Eliot Lear References: <4D3DF812.80108@sunet.se> <4D3EB2D3.8000604@cisco.com> <4D3ECF30.7050503@sunet.se> <4D3EDD5A.3050003@sunet.se> <4D3EDF31.5080500@cisco.com> In-Reply-To: <4D3EDF31.5080500@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: abfab@ietf.org Subject: Re: [abfab] OIDs 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, 25 Jan 2011 14:50:57 -0000 On 1/25/11 9:33 AM, Eliot Lear wrote: > > > On 1/25/11 3:25 PM, Leif Johansson wrote: >> So basically your vote is on an enterprise arc. I'm not sure I >> understand the reasons why abfab has requirement that differ so >> much from any other IETF protocol where protocol numbers are >> typically allocated on publication of the RFC. > > Neither do I but then I'm the guy who thought it was possible to get an > early allocation from IANA for IETF protocol work. I think we can get an early allocation too. The question is how much of a purist do we want to be? Technically, when you assign an OID it's linked to a particular syntax. If you change that syntax, then you need a new OID. spt From lear@cisco.com Tue Jan 25 06:55:29 2011 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 7AE203A67EB for ; Tue, 25 Jan 2011 06:55:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.195 X-Spam-Level: X-Spam-Status: No, score=-110.195 tagged_above=-999 required=5 tests=[AWL=0.404, 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 QnYWgvlHOJU8 for ; Tue, 25 Jan 2011 06:55:28 -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 87F243A67E2 for ; Tue, 25 Jan 2011 06:55:28 -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: AvQEAD90Pk2Q/khMgWdsb2JhbACEEqBcFQEBFiIkoS2KX5BigSODOHQEjCg Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-1.cisco.com with ESMTP; 25 Jan 2011 14:58:25 +0000 Received: from ams3-vpn-dhcp4915.cisco.com (ams3-vpn-dhcp4915.cisco.com [10.61.83.50]) by ams-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p0PEwPoU027351; Tue, 25 Jan 2011 14:58:25 GMT Message-ID: <4D3EE50D.5080504@cisco.com> Date: Tue, 25 Jan 2011 15:58: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: Sean Turner References: <4D3DF812.80108@sunet.se> <4D3EB2D3.8000604@cisco.com> <4D3ECF30.7050503@sunet.se> <4D3EDD5A.3050003@sunet.se> <4D3EDF31.5080500@cisco.com> <4D3EE3C2.7050007@ieca.com> In-Reply-To: <4D3EE3C2.7050007@ieca.com> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: abfab@ietf.org Subject: Re: [abfab] OIDs 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, 25 Jan 2011 14:55:29 -0000 On 1/25/11 3:52 PM, Sean Turner wrote: > I think we can get an early allocation too. The question is how much > of a purist do we want to be? Technically, when you assign an OID > it's linked to a particular syntax. If you change that syntax, then > you need a new OID. > So burn OIDs early. It's not as if they're IPv4 addresses ;-) Eliot From hartmans@painless-security.com Tue Jan 25 07:17:44 2011 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 919333A67F0 for ; Tue, 25 Jan 2011 07:17:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.272 X-Spam-Level: X-Spam-Status: No, score=-2.272 tagged_above=-999 required=5 tests=[AWL=-0.007, 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 UuJl3wziqgZ1 for ; Tue, 25 Jan 2011 07:17:43 -0800 (PST) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by core3.amsl.com (Postfix) with ESMTP id C710C3A67ED for ; Tue, 25 Jan 2011 07:17:43 -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 78CFB20167; Tue, 25 Jan 2011 10:18:48 -0500 (EST) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 24B8C432C; Tue, 25 Jan 2011 10:20:22 -0500 (EST) From: Sam Hartman To: Leif Johansson References: <4D3DF812.80108@sunet.se> <4D3EB2D3.8000604@cisco.com> <4D3ECF30.7050503@sunet.se> <4D3EDD5A.3050003@sunet.se> Date: Tue, 25 Jan 2011 10:20:22 -0500 In-Reply-To: <4D3EDD5A.3050003@sunet.se> (Leif Johansson's message of "Tue, 25 Jan 2011 15:25:30 +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] OIDs 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, 25 Jan 2011 15:17:44 -0000 >>>>> "Leif" == Leif Johansson writes: >> If we're forced to break backward compatibility then we'll have >> to evaluate whether the OID needs to change. Currently, I think >> the answer would be no; fairly soon, I think the answer would be >> yes. However I don't think it would be a big deal if we needed >> to burn a few codepoints in an ABFAB mechanisms oid arc. I also >> think it matters very little where that OID arc lives--IETF or >> not. Leif> So basically your vote is on an enterprise arc. I'm not sure I Leif> understand the reasons why abfab has requirement that differ Leif> so much from any other IETF protocol where protocol numbers Leif> are typically allocated on publication of the RFC. No, my vote would be on an IETF arc under the control of the WG turned over to IANA on our disolution. I actually think the idea of assigning codepoints on publication for new protocols works fairly poorly for most protocols. As someone implementing ABFAB, I will probably ship implementations before an RFC is published. If we need to change because of a real compatibility issue, we can do that. However, it's not work breaking backward compatibility with deployed code just to get a nicer number. --Sam From leifj@sunet.se Tue Jan 25 07:38:33 2011 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 3893A3A67FF for ; Tue, 25 Jan 2011 07:38:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.25 X-Spam-Level: X-Spam-Status: No, score=-2.25 tagged_above=-999 required=5 tests=[AWL=0.349, 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 ygQEPh04nRq6 for ; Tue, 25 Jan 2011 07:38:32 -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 03D573A67EC for ; Tue, 25 Jan 2011 07:38:31 -0800 (PST) Received: from [10.33.1.113] ([212.247.15.226]) (authenticated bits=0) by backup-server.nordu.net (8.14.3/8.14.3) with ESMTP id p0PFfFTD009513 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 25 Jan 2011 16:41:21 +0100 (CET) Message-ID: <4D3EEF1B.5020401@sunet.se> Date: Tue, 25 Jan 2011 16:41:15 +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: Eliot Lear References: <4D3DF812.80108@sunet.se> <4D3EB2D3.8000604@cisco.com> <4D3ECF30.7050503@sunet.se> <4D3EDD5A.3050003@sunet.se> <4D3EDF31.5080500@cisco.com> <4D3EE3C2.7050007@ieca.com> <4D3EE50D.5080504@cisco.com> In-Reply-To: <4D3EE50D.5080504@cisco.com> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: abfab@ietf.org Subject: Re: [abfab] OIDs 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, 25 Jan 2011 15:38:33 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 01/25/2011 03:58 PM, Eliot Lear wrote: > > > On 1/25/11 3:52 PM, Sean Turner wrote: >> I think we can get an early allocation too. The question is how much >> of a purist do we want to be? Technically, when you assign an OID >> it's linked to a particular syntax. If you change that syntax, then >> you need a new OID. >> > > So burn OIDs early. It's not as if they're IPv4 addresses ;-) > > Eliot I tend to agree with that. The WG can figure out when a revision has to imply allocating new OIDs I think. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk0+7xsACgkQ8Jx8FtbMZnc5/gCePFcWjngAZiaHHtItE6t76d+v ZFUAoMfQxb1MypXlXbnUBtdaBKjzxkXi =BdIR -----END PGP SIGNATURE----- From turners@ieca.com Tue Jan 25 11:41:22 2011 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 8065E3A6885 for ; Tue, 25 Jan 2011 11:41:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.536 X-Spam-Level: X-Spam-Status: No, score=-102.536 tagged_above=-999 required=5 tests=[AWL=0.062, BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001, 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 6sn8orB6cDxI for ; Tue, 25 Jan 2011 11:41:21 -0800 (PST) Received: from nm20-vm0.bullet.mail.sp2.yahoo.com (nm20-vm0.bullet.mail.sp2.yahoo.com [98.139.91.218]) by core3.amsl.com (Postfix) with SMTP id 9CA7C3A6881 for ; Tue, 25 Jan 2011 11:41:21 -0800 (PST) Received: from [98.139.91.68] by nm20.bullet.mail.sp2.yahoo.com with NNFMP; 25 Jan 2011 19:44:17 -0000 Received: from [98.139.91.15] by tm8.bullet.mail.sp2.yahoo.com with NNFMP; 25 Jan 2011 19:44:17 -0000 Received: from [127.0.0.1] by omp1015.mail.sp2.yahoo.com with NNFMP; 25 Jan 2011 19:44:17 -0000 X-Yahoo-Newman-Id: 378608.41502.bm@omp1015.mail.sp2.yahoo.com Received: (qmail 95996 invoked from network); 25 Jan 2011 19:44:10 -0000 Received: from thunderfish.local (turners@71.191.5.27 with plain) by smtp111.biz.mail.sp1.yahoo.com with SMTP; 25 Jan 2011 11:44:10 -0800 PST X-Yahoo-SMTP: ZrP3VLSswBDL75pF8ymZHDSu9B.vcMfDPgLJ X-YMail-OSG: itaFsUQVM1lBnddzJXUKMdsCz1UQQsCBv8xY5i59DUg0Xax 2KELR2HsSN4Z2c2aBY8ZiQUgV8rDGk5CvNu8U.3.6dJF31BVnsbHTDy89e1y a08Qr3acsR8fEO0F35LIWiL.IXFNGpa6IjC6crBSa65mzOUuIPVqjSjVxU_0 zIFvqQDYWWDzHhr89ym6Ne1HqFftWGm3rngDRrNarJArf1mnZy9LHJLEwLEJ 80SDr3WDkxzxuJ_LHtgooE0xY4_1es6CRSC.bJUmR9eEI5g38DMsoaD8- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4D3F2808.3020707@ieca.com> Date: Tue, 25 Jan 2011 14:44:08 -0500 From: Sean Turner 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: Eliot Lear References: <4D3DF812.80108@sunet.se> <4D3EB2D3.8000604@cisco.com> <4D3ECF30.7050503@sunet.se> <4D3EDD5A.3050003@sunet.se> <4D3EDF31.5080500@cisco.com> <4D3EE3C2.7050007@ieca.com> <4D3EE50D.5080504@cisco.com> In-Reply-To: <4D3EE50D.5080504@cisco.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: abfab@ietf.org Subject: Re: [abfab] OIDs 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, 25 Jan 2011 19:41:22 -0000 On 1/25/11 9:58 AM, Eliot Lear wrote: > > > On 1/25/11 3:52 PM, Sean Turner wrote: >> I think we can get an early allocation too. The question is how much >> of a purist do we want to be? Technically, when you assign an OID >> it's linked to a particular syntax. If you change that syntax, then >> you need a new OID. >> > > So burn OIDs early. It's not as if they're IPv4 addresses ;-) Yeah ;) Seriously, some people say that the warning in RFC 2026 about the drafts is enough (repeated below for convenience): ******************************************************** * * * Under no circumstances should an Internet-Draft * * be referenced by any paper, report, or Request- * * for-Proposal, nor should a vendor claim compliance * * with an Internet-Draft. * * * ******************************************************** and that you could assign an OID and then change the syntax without consequences because it's in a draft. But, we all know that sometimes things get coded never get changed. spt From turners@ieca.com Tue Jan 25 11:45:35 2011 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 6DC4A3A6889 for ; Tue, 25 Jan 2011 11:45:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.537 X-Spam-Level: X-Spam-Status: No, score=-102.537 tagged_above=-999 required=5 tests=[AWL=0.061, BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001, 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 F6lgo1m1+jSg for ; Tue, 25 Jan 2011 11:45:34 -0800 (PST) Received: from nm12-vm0.bullet.mail.ac4.yahoo.com (nm12-vm0.bullet.mail.ac4.yahoo.com [98.139.53.198]) by core3.amsl.com (Postfix) with SMTP id 4CBDE3A6838 for ; Tue, 25 Jan 2011 11:45:34 -0800 (PST) Received: from [98.139.52.189] by nm12.bullet.mail.ac4.yahoo.com with NNFMP; 25 Jan 2011 19:48:30 -0000 Received: from [98.139.52.151] by tm2.bullet.mail.ac4.yahoo.com with NNFMP; 25 Jan 2011 19:48:30 -0000 Received: from [127.0.0.1] by omp1034.mail.ac4.yahoo.com with NNFMP; 25 Jan 2011 19:48:30 -0000 X-Yahoo-Newman-Id: 125992.92929.bm@omp1034.mail.ac4.yahoo.com Received: (qmail 96331 invoked from network); 25 Jan 2011 19:48:30 -0000 Received: from thunderfish.local (turners@71.191.5.27 with plain) by smtp111.biz.mail.re2.yahoo.com with SMTP; 25 Jan 2011 11:48:28 -0800 PST X-Yahoo-SMTP: ZrP3VLSswBDL75pF8ymZHDSu9B.vcMfDPgLJ X-YMail-OSG: 2Vzdw20VM1koUVA.gYTAALZzCmu_OQUkJcs54n2Rm4BzIT9 _KIkqY8qU X-Yahoo-Newman-Property: ymail-3 Message-ID: <4D3F290B.1070505@ieca.com> Date: Tue, 25 Jan 2011 14:48:27 -0500 From: Sean Turner 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: <4D3DF812.80108@sunet.se> <4D3EB2D3.8000604@cisco.com> <4D3ECF30.7050503@sunet.se> <4D3EDD5A.3050003@sunet.se> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: abfab@ietf.org Subject: Re: [abfab] OIDs 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, 25 Jan 2011 19:45:35 -0000 On 1/25/11 10:20 AM, Sam Hartman wrote: >>>>>> "Leif" == Leif Johansson writes: > > >> If we're forced to break backward compatibility then we'll have > >> to evaluate whether the OID needs to change. Currently, I think > >> the answer would be no; fairly soon, I think the answer would be > >> yes. However I don't think it would be a big deal if we needed > >> to burn a few codepoints in an ABFAB mechanisms oid arc. I also > >> think it matters very little where that OID arc lives--IETF or > >> not. > > Leif> So basically your vote is on an enterprise arc. I'm not sure I > Leif> understand the reasons why abfab has requirement that differ > Leif> so much from any other IETF protocol where protocol numbers > Leif> are typically allocated on publication of the RFC. > > No, my vote would be on an IETF arc under the control of the WG turned > over to IANA on our disolution. > > I actually think the idea of assigning codepoints on publication for new > protocols works fairly poorly for most protocols. As someone > implementing ABFAB, I will probably ship implementations before an RFC > is published. If we need to change because of a real compatibility > issue, we can do that. However, it's not work breaking backward > compatibility with deployed code just to get a nicer number. Sam, The question is whether you think we should get a new OID every time the syntax changes. I agree that assigning an OID out of an "experimental" and then changing it to an "operational" arc if the syntax didn't change is kind of a waste of time. I have this vague notion of the syntax changing a lot. If the WG doesn't think that's going to happen then we probably don't have to go the experimental then switch to operational route. One way around this is to define the syntax use a dummy OID (of your own devising) to ensure you can work with yourself. Once you're convinced and the syntax is workable/stable - then put the OID in the draft. spt From sxw@inf.ed.ac.uk Tue Jan 25 12:24:03 2011 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 B22883A6875 for ; Tue, 25 Jan 2011 12:24:03 -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 LMVOEX3z+2Bw for ; Tue, 25 Jan 2011 12:24:03 -0800 (PST) Received: from outbound-queue-1.mail.thdo.gradwell.net (outbound-queue-1.mail.thdo.gradwell.net [212.11.70.34]) by core3.amsl.com (Postfix) with ESMTP id C30643A685C for ; Tue, 25 Jan 2011 12:24:02 -0800 (PST) Received: from outbound-edge-1.mail.thdo.gradwell.net (bonnie.gradwell.net [212.11.70.2]) by outbound-queue-1.mail.thdo.gradwell.net (Postfix) with ESMTP id 0097E21F35; Tue, 25 Jan 2011 20:26:50 +0000 (GMT) Received: from 87-194-107-64.bethere.co.uk (HELO alfheim.config) (87.194.107.64) (smtp-auth username simon@pop3.sxw.org.uk, mechanism cram-md5) by outbound-edge-1.mail.thdo.gradwell.net (qpsmtpd/0.83) with ESMTPA; Tue, 25 Jan 2011 20:26:49 +0000 Message-Id: From: Simon Wilkinson To: Sean Turner In-Reply-To: <4D3F2808.3020707@ieca.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Tue, 25 Jan 2011 20:26:48 +0000 References: <4D3DF812.80108@sunet.se> <4D3EB2D3.8000604@cisco.com> <4D3ECF30.7050503@sunet.se> <4D3EDD5A.3050003@sunet.se> <4D3EDF31.5080500@cisco.com> <4D3EE3C2.7050007@ieca.com> <4D3EE50D.5080504@cisco.com> <4D3F2808.3020707@ieca.com> X-Mailer: Apple Mail (2.936) X-Gradwell-MongoId: 4d3f3209.181e5-7bdb-1 X-Gradwell-Auth-Method: mailbox X-Gradwell-Auth-Credentials: simon@pop3.sxw.org.uk Cc: abfab@ietf.org Subject: Re: [abfab] OIDs 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, 25 Jan 2011 20:24:03 -0000 On 25 Jan 2011, at 19:44, Sean Turner wrote: > > Yeah ;) Seriously, some people say that the warning in RFC 2026 > about the drafts is enough (repeated below for convenience): The problem is that as soon as code has been shared, people start to deploy it. In the open source sector, this is a real issue if the code is shadowing the draft. I hit exactly this problem with my implementation of RFC4462 for OpenSSH. There were a issues with earlier versions of that draft and with my implementation of them. A number of vendors deployed these earlier, buggy, releases and we were left maintaining backwards compatibility hacks for many years. I don't think that there is any easy solution to this - release early, release often is always going to create these kind of conflicts, and there are problems that you only discover when implementations are produced. If those implementations are being produced as open source software, then people will deploy your development code, and expect it to not be arbitrarily broken by upgrades. So, I do feel that you are going to have to change OIDs if the meaning of those identifiers change. Cheers, Simon. From hartmans@painless-security.com Wed Jan 26 05:44:13 2011 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 7C9C13A6980 for ; Wed, 26 Jan 2011 05:44:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.272 X-Spam-Level: X-Spam-Status: No, score=-2.272 tagged_above=-999 required=5 tests=[AWL=-0.007, 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 s8u17SwY+EBk for ; Wed, 26 Jan 2011 05:44:12 -0800 (PST) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by core3.amsl.com (Postfix) with ESMTP id AC5FA3A69AE for ; Wed, 26 Jan 2011 05:44: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 8889C2022C; Wed, 26 Jan 2011 08:45:20 -0500 (EST) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id ED3B4432C; Wed, 26 Jan 2011 08:46:47 -0500 (EST) From: Sam Hartman To: Sean Turner References: <4D3DF812.80108@sunet.se> <4D3EB2D3.8000604@cisco.com> <4D3ECF30.7050503@sunet.se> <4D3EDD5A.3050003@sunet.se> <4D3F290B.1070505@ieca.com> Date: Wed, 26 Jan 2011 08:46:47 -0500 In-Reply-To: <4D3F290B.1070505@ieca.com> (Sean Turner's message of "Tue, 25 Jan 2011 14:48:27 -0500") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: abfab@ietf.org Subject: Re: [abfab] OIDs 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, 26 Jan 2011 13:44:13 -0000 >>>>> "Sean" == Sean Turner writes: Sean> Sam, Sean> The question is whether you think we should get a new OID Sean> every time the syntax changes. I agree that assigning an OID Sean> out of an "experimental" and then changing it to an Sean> "operational" arc if the syntax didn't change is kind of a Sean> waste of time. I have this vague notion of the syntax Sean> changing a lot. If the WG doesn't think that's going to Sean> happen then we probably don't have to go the experimental then Sean> switch to operational route. I haven't answered this directly because syntax is a poorly defined term here. These OIDs do not describe objects encoded using ASN.1. If we were using ASN.1 I'd say that whenever we changed the syntax since the last used version, we should change the OID. By last used version, I mean any version that someone claimed to have implemented. If we published draft 2 today and found a minor error and fixed it in draft 3 tomorrow I would not typically require an OID change even if the syntax changed. Here, I think we should change the OID if things change in a manner that breaks compatibility. We have some extension points in the spec so many of the things we might want to do would not involve an OID change. One thing we've discussed (support for null GSS target names) probably should involve an OID change because it changes the semantics (and probably syntax) of the first message from client to server. I expect we'll have one OID change from the OID in Luke's privaty arc we're having today (for the target name change above). Around that time I expect there will be people using the code and past that point I think we'd need to be fairly strict about OID changes. I don't see a need for any spec changes that would require an OID change beyond that point, which realistically means it will probably happen once or twice. (There are always changes you don't anticipate.) --Sam From leifj@sunet.se Wed Jan 26 05:58:11 2011 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 B31533A69BA for ; Wed, 26 Jan 2011 05:58:11 -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 vnSur5Ai+bpa for ; Wed, 26 Jan 2011 05:58:10 -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 8C24F3A69C7 for ; Wed, 26 Jan 2011 05:58:09 -0800 (PST) Received: from [192.36.125.230] (dhcp.pilsnet.sunet.se [192.36.125.230]) (authenticated bits=0) by backup-server.nordu.net (8.14.3/8.14.3) with ESMTP id p0QE11WM015150 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 26 Jan 2011 15:01:04 +0100 (CET) Message-ID: <4D40291D.9010502@sunet.se> Date: Wed, 26 Jan 2011 15:01:01 +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: Sam Hartman References: <4D3DF812.80108@sunet.se> <4D3EB2D3.8000604@cisco.com> <4D3ECF30.7050503@sunet.se> <4D3EDD5A.3050003@sunet.se> <4D3F290B.1070505@ieca.com> In-Reply-To: X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: abfab@ietf.org Subject: Re: [abfab] OIDs 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, 26 Jan 2011 13:58:11 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > Here, I think we should change the OID if things change in a manner that > breaks compatibility. We have some extension points in the spec so many Actually that is how I understood the "change syntax" bit. cheers Leif -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk1AKR0ACgkQ8Jx8FtbMZnclTACcDwsXVQMwlCAlFkKvg5ICBv05 +joAnjd5ke7WhtrCXSFKMpZhX6WVhlgq =f2CH -----END PGP SIGNATURE-----