Return-Path: <0 Feb 2010 21:36:57 -0000\"> 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: Wed, 10 Feb 2010 16:41:29 -0500 10 Feb 2010 21:36:57 -0000\") Message-Id: <200305122255.h4CMt1U02501@example.com> To: abfab@ietf.org MIME-Version: 1.0 >>>>> "Josh" == Josh Howlett writes: Josh> Given that we already have AAA credentials established, we can Josh> derive a second credential which provides a PSK for TLS. >> >> The acceptor has the credential shared with the TAS (trust >> authority near server for the archive). The artifact is being >> issued by the TAC (trust authority near client). We could have >> the acceptor start conversing directly with TAC and use EAP-GSS >> to bootstrap a credential. Josh> Right. This is what I was proposing with "recursive Josh> discovery". TAS recurses through the trust graph until it Josh> finds TAC, and they converse directly. Policy can be enforced Josh> at any point along the trust graph so that if someone doesn't Josh> want these entities talking, they can enforce that. I thought you were proposing that TAS obtain a credential with TAC. What we need for artifact resolution is for S to obtain a credential with TAC. So, S needs to be an X server, AAA client, artifact resolution client and key management client. Josh> I'm not concerned about the authenticity of the artifact; let Josh> us assume that we have satisfied that. I'm 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 issuer who Josh> is not who they claim to be. Ah! My terminology failure. Can we include a hash of the SAML message in the artifact or along side the artifact to get authenticity of the SAML message? Return-Path: <0 Feb 2010 22:56:13 -0000\"> 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: Wed, 10 Feb 2010 18:16:55 -0500 10 Feb 2010 22:56:13 -0000\") Message-Id: <200305122255.h4CMt1U02501@example.com> To: abfab@ietf.org MIME-Version: 1.0 >>>>> "Josh" == Josh Howlett writes: 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 trust domain to Josh> find TAC. Ah, looks like we'll both be sleeping on something. Making S be something more than a stub RADIUS client--actually having it interact with RADIUS entities other than TAC seems esthetically bad to me. I'll think on this. Certainly if S talks to more than TAS, things get complicated. For example the club really isn't in a position to kno whether S is allowed to speak for a particular name. --Sam Return-Path: <1 Feb 2010 09:55:46 -0000\"> 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 08:44:23 -0500 11 Feb 2010 09:55:46 -0000\") Message-Id: <200305122255.h4CMt1U02501@example.com> To: abfab@ietf.org MIME-Version: 1.0 >>>>> "Josh" == Josh Howlett writes: Josh> I think we need to move away from the idea of TAS or TAC as Josh> having a special role to play, and just consider them as a Josh> potential first discovery hop from the S and C respectively. Josh> To use a routing analogy, we would consider an IP architecture Josh> that required the use of a particular first hop router to be Josh> broken. A host might have a default router for unknown Josh> prefixes, but it should also be able to pick between Josh> alternative routers for prefixes it does know about. Josh> Consequently, I think it is reasonabe to think about TAS and Josh> TAC as being the default trust path for S and C respectively, Josh> but that if S or C know a better path they should use that Josh> instead. Ah! Thanks for describing things this way. It makes it clear exactly where my concerns are. Certainly an IP architecture that depended on using a certain first-hop router would be of concern, although LISP and GSE do both fall somewhat into this category. (They both have distinguished routers that a path must go through). my problem is with requiring S to talk to a node other than TAS. There are a lot of good security and simplicity reasons that you want to minimize the number of protocols, credentials and entities S needs to talk to. There are also latency and performance reasons that you want to avoid S needing to set up credentials in real time. In IP, we've discovered that there are important classes of node that should only have a default router. Many classes of small IP devices have effectively only support for a default and localhost route. We'd reject an IP architecture that required more complexity than that in an end-node. I think we should reject a moonshot architecture that requires routing logic in servers for the same reason. Some servers may well have complicated routing, but requiring them all to do so seems like a bad design. Requiring a server to engage in a key management protocol to get an artifact is doing exactly that. As an aside, I remain unconvinced that treating TAS and TAC as special architectural entities doesn't simplify the model in important ways. I definitely agree that we should support a case where TAS gets close to S--definitely on the same machine, possibly in the same process. I'm not sure though that we want to lose the model distinction. Return-Path: <1 Feb 2010 09:55:46 -0000\"> 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 08:44:45 -0500 11 Feb 2010 09:55:46 -0000\") Message-Id: <200305122255.h4CMt1U02501@example.com> To: abfab@ietf.org MIME-Version: 1.0 I will be unavailable until our 1500 call. Return-Path: <1 Feb 2010 21:01:53 -0000\"> 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: Fri, 12 Feb 2010 12:46:13 -0500 11 Feb 2010 21:01:53 -0000\") Message-Id: <200305122255.h4CMt1U02501@example.com> To: abfab@ietf.org MIME-Version: 1.0 I think we're on the same page regarding actors. I didn't see anything new in your definition of actors. I think you may be confusing BGP confederations with BGP communities. As I remember, a BGP community is an attribute attached to a route used for local policy with no protocol level interpretation. A confederation is a set of ASes aggregated together to reduce BGP-level peering complexity. Or perhaps BGP communities are operationally used as you describe? I think separating the KNP and the TNP is a very good idea. The KNP is what we use for setting up a key used between a SAML metadata consumer and target entity. That seems like a good name for that protocol. While the TNP has the same basic structure as the KNP it probably carries different XML and is focused on AAA relationships not SAML relationships. There may be some links between the two protocols. While I've read your comments about the trust graph and TML, I have not fully digested them. In particular, I don't understand the security implications of the system, nor do I understand caching and performance implications. I also don't understand how much trust discovery is actually required. For example it seems like the European academic case could be handled relatively simply. Ask TAS through an untrusted channel what authorities it accepts. Give that list to your national federation and move from there. In other words, the more assumptions we can make about the graph, the simpler our task. So, while you have a good theoretical model, I'm not sure how general of an implementation we will need nor how soon. Return-Path: <2 Feb 2010 22:10:50 -0000\"> 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: Fri, 12 Feb 2010 17:21:31 -0500 12 Feb 2010 22:10:50 -0000\") Message-Id: <200305122255.h4CMt1U02501@example.com> To: abfab@ietf.org MIME-Version: 1.0 >>>>> "Josh" == Josh Howlett writes: Josh> I understand, in particular, your skepticism concerning trust Josh> path discovery. I guess this boils down to personal opinion Josh> about the likely future scale of federated systems. You're Josh> probably right that we could live without trust path discovery Josh> purely within the European Higher Education community over the Josh> next 2 or 3 years. However - on the evidence of the adoption Josh> of federated identity within the HE community - I believe that Josh> we're in the early stages of exponential growth. While the Josh> absolute numbers are nowhere near Internet-scale at the Josh> moment, I believe that it's only a matter of time. It will Josh> escape the petri dishes of .gov, .edu, large .com, etc, and it Josh> I think it would be prudent to be prepared. There we're in complete agreement. However, I view the need to support this sort of trust path discovery as very much a next stage issue. The rest of the project seems squarely in the category of engineering work. The trust path discovery may well be research. So, I'm finding that I need to approach the trust path discovery and try and understand requirements and use cases. Then I'll want to decompose it, build logical interfaces, and understand how they fit together. At that point I'll be better able to discuss specific mechanisms. --Sam Return-Path: <2 Feb 2010 23:12:52 -0000\"> 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: Fri, 12 Feb 2010 18:28:10 -0500 12 Feb 2010 23:12:52 -0000\") Message-Id: <200305122255.h4CMt1U02501@example.com> To: abfab@ietf.org MIME-Version: 1.0 >>>>> "Josh" == Josh Howlett writes: >> There we're in complete agreement. However, I view the need to >> support this sort of trust path discovery as very much a next >> stage issue. The rest of the project seems squarely in the >> category of engineering work. Josh> Agreed. It would be nice to have a story for 3 to 5 years Josh> hence, but as you say it is important that we focus on Josh> engineering solutions to demonstrable problems of today. I Josh> will try to control my enthusiasm for fixing tomorrow's Josh> poorly-defined problems :-) Well, let's just try to channel it into defining the problems:-) 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: Fri, 12 Feb 2010 19:34:00 -0500 applications at IETF 77 Message-Id: <200305122255.h4CMt1U02501@example.com> To: abfab@ietf.org Comments: To: ietf@ietf.org, kitten@ietf.org, emu@ietf.org I've been working with JaNet(UK) on providing a federation solution for client applications such as mail readers, filesystem clients, XMPP clients and the like. There are fairly good solutions such as Open ID, Information Card and SAML for web applications. Within an enterprise, you have Kerberos. JaNet(UK) runs one of the world's largest SAML federations. As their customers are beginning to take advantage of federated access for web applications they are also asking how they can gain the same flexibility for client-server applications. This customer demand appears to have traction across the entire European academic community. I suspect that it may find traction within enterprises and other environments. We'd like to have a bar BOF at IETF 77 in California with a goal of an actual BOF this summer in Europe at IETF 78. We invite you to join our mailing list at https://www.jiscmail.ac.uk/cgi-bin/webadmin?A0=moonshot-community where we can discuss timing. We plan to discuss the general problem and a proposed solution at the bar BOF. I've already prepared a feasibility analysis for JaNet(UK)'s solution; the analysis does discuss the problem some, gives an outline of the solution and discusses technical issues and required standards work in detail. By IETF we'll have a use case paper, an internet draft on the solution,and a slide set. we look forward to your input. You can find a bit more detail on my blog at http://www.painless-security.com/blog/2010/02/12/moonshot1 You can find the feasibility analysis at http://www.painless-security.com/wp/wp-content/uploads/2010/02/moonshot-feasibility-analysis.pdf Thanks, Sam Hartman Painless Security 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, 18 Feb 2010 11:18:03 -0500 Subject: Re: SAML RADIUS Binding Message-Id: <200305122255.h4CMt1U02501@example.com> To: abfab@ietf.org MIME-Version: 1.0 Josh Howlett wrote on 2010-02-18: >> So as I suspected, this is about message size? XML == bad fit >> for size constrained protocols. > > EAP doesn't have any size constraints, but RADIUS (a common EAP > transport) does. A RADIUS message is (essentially arbitarily, AFAICT) > limited to 4kb. In some circumstances it is possible to fragment large > payloads over multiple RADIUS messages, but only if the payload is part > of an on-going conversation. The last payload (which in this context > will contain a SAML response/assertion) must fit completely into the > final RADIUS message. Ok. Reminding myself of the roles in play here, is the RADIUS traffic (ignoring proxies) basically between the IdP and an SP of some kind? If the semantics are such that the assertion was delivered as part of that conversation, one possibility would be to deliver it as an assertion reference, not an artifact, and just dereference it using the Assertion lookup profile that's already in the spec, via HTTP. It really depends on the security semantics in play. One point to make is that if there's no AuthnRequest, there probably doesn't need to be a Response. So this is probably just an Assertion anyway. -- Scott 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, 18 Feb 2010 14:32:29 -0500 Subject: Re: SAML RADIUS Binding Message-Id: <200305122255.h4CMt1U02501@example.com> To: abfab@ietf.org MIME-Version: 1.0 Josh Howlett wrote on 2010-02-18: > That makes a lot of sense. If you recall, the original approach was to > avoid authentication (which would imply a turtle issue) of the call-back > responder by attempting to match a hash claimed in the artifact to the > SAML message that it resolves. I believe we can achieve a semantically > equivalent effect by incorporating the same hash in the AssertionIdRef > value. The AssertionIdRef is basically just consumed by the relying party, there aren't any rules in the spec for processing it or decorating it. It's designed for cases in which any concerns about the context of the reference would be handled by that context. For example, in WSS, you can sign a reference such that the actual signature is over the result of dereferencing it, to maintain integrity. I guess I just don't understand the need to avoid authentication. Without authenticaton of the issuer, you can't trust the assertion anyway, it's just data at that point. I'm assuming that the "turtle" problem is dealt with by using traditonal trust mechanisms or by recursing things such that you get an assertion from some other party to let you authenticate the first one. You have to trust somebody to start with, and the runtime manifestation of that is authentication. -- Scott Return-Path: <3 Feb 2010 16:58:55 -0000\"> 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: Mon, 22 Feb 2010 09:37:48 -0500 13 Feb 2010 16:58:55 -0000\") Message-Id: <200305122255.h4CMt1U02501@example.com> To: abfab@ietf.org MIME-Version: 1.0 Replying to the question about artifact resolution given that SAML requires peer-entity authentication. First, I think the right technical approach is to ignore the RADIUS MTU issue. If that proves problematic, I think including endpoint channel bindings is preferred to establishing a key to include in the access-accept. These bindings will be sufficient for authentication--in effect you're just telling the other end what cert to expect. Return-Path: <8 Feb 2010 00:01:18 -0500\"> 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: Mon, 22 Feb 2010 10:04:04 -0500 18 Feb 2010 00:01:18 -0500\") Message-Id: <200305122255.h4CMt1U02501@example.com> To: abfab@ietf.org MIME-Version: 1.0 >>>>> "Scott" == Scott Cantor writes: >> Josh previously wrote: >> > Bad news. As I suspected, it is a requirement that the >> call-back used to > the resolve the artifact is authenticated at >> the transport layer. Scott> Well, it doesn't have to be the transport layer...you can Scott> sign the messages, for example. But the protocol as designed Scott> is for two SAML peers to interact and authenticate each other Scott> during the exchange so that the artifact is consumed by the Scott> intended party and the message can be trusted. If signing the message is acceptable, then sending a hash of a message over an integrity protected channel between the two SAML peers should be OK too. 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: Mon, 22 Feb 2010 10:12:06 -0500 Subject: Re: SAML RADIUS Binding Message-Id: <200305122255.h4CMt1U02501@example.com> To: abfab@ietf.org MIME-Version: 1.0 Sam Hartman wrote on 2010-02-22: > If signing the message is acceptable, then sending a hash of a message > over an integrity protected channel between the two SAML peers should be > OK too. The signature is for authentication of the issuer of the message. I don't really have enough experience to understand how you can substitute different mechanisms for that, but sending around hashes doesn't seem to be an authentication solution unless it's an HMAC. Maybe that's what you meant. -- Scott 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: Mon, 22 Feb 2010 11:06:56 -0500 message of \"Mon, 22 Feb 2010 10:12:06 -0500\") Message-Id: <200305122255.h4CMt1U02501@example.com> To: abfab@ietf.org MIME-Version: 1.0 >>>>> "Scott" == Scott Cantor writes: Scott> Sam Hartman wrote on 2010-02-22: >> If signing the message is acceptable, then sending a hash of a >> message over an integrity protected channel between the two SAML >> peers should be OK too. Scott> The signature is for authentication of the issuer of the Scott> message. I don't really have enough experience to understand Scott> how you can substitute different mechanisms for that, but Scott> sending around hashes doesn't seem to be an authentication Scott> solution unless it's an HMAC. Maybe that's what you meant. No, not an HMAC. Alice tells bob over an authenticated channel that she's going to send him a message with hash h. Later, through an arbitrary channel that better supports large messages than the authenticated channel Alice sends a message with hash h. On receiving that message, Bob knows it came from Alice because if a strong cryptographic hash is used, then no party can find a message other than the one Alice constructed that hashes to h. This is effectively exactly what a digital signature does. A signature is a hugely expensive RSA channel that really cannot easily send messages larger than the key size. We want to sign a message larger than a key (and get several other properties besides). So, using our RSA channel, we send a hash of the message. Then using any channel of our choice, we send the message. --Sam 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: Mon, 22 Feb 2010 11:14:31 -0500 Subject: Re: SAML RADIUS Binding Message-Id: <200305122255.h4CMt1U02501@example.com> To: abfab@ietf.org MIME-Version: 1.0 Sam Hartman wrote on 2010-02-22: > No, not an HMAC. Alice tells bob over an authenticated channel that > she's going to send him a message with hash h. Later, through an > arbitrary channel that better supports large messages than the > authenticated channel Alice sends a message with hash h. On receiving > that message, Bob knows it came from Alice because if a strong > cryptographic hash is used, then no party can find a message other than > the one Alice constructed that hashes to h. Ok, this time you said "authenticated channel", while before you said "integrity-protected". That's why I asked. -- Scott 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: Mon, 22 Feb 2010 15:31:11 -0500 message of \"Mon, 22 Feb 2010 11:14:31 -0500\") Message-Id: <200305122255.h4CMt1U02501@example.com> To: abfab@ietf.org MIME-Version: 1.0 >>>>> "Scott" == Scott Cantor writes: Scott> Sam Hartman wrote on 2010-02-22: >> No, not an HMAC. Alice tells bob over an authenticated channel >> that she's going to send him a message with hash h. Later, >> through an arbitrary channel that better supports large messages >> than the authenticated channel Alice sends a message with hash h. >> On receiving that message, Bob knows it came from Alice because >> if a strong cryptographic hash is used, then no party can find a >> message other than the one Alice constructed that hashes to h. Scott> Ok, this time you said "authenticated channel", while before Scott> you said "integrity-protected". That's why I asked. I think the terms are more or less interchangable when applied to a channel. Integrity protection is definitely useless without authentication. To be pedantic, it seems that RFC 2828 does not require that authentication service implies data integrity service, but does require that data integrity service implies authentication service. So, if you accept that lexicon, my original statement was more correct. --Sam Return-Path: <2 Feb 2010 18:17:33 -0000\"> 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: Mon, 22 Feb 2010 15:32:37 -0500 22 Feb 2010 18:17:33 -0000\") Message-Id: <200305122255.h4CMt1U02501@example.com> To: abfab@ietf.org MIME-Version: 1.0 >>>>> "Josh" == Josh Howlett writes: Josh> Sam wrote: >> First, I think the right technical approach is to ignore the >> RADIUS MTU issue. Josh> Would this be acceptable to IETF? Ot are you talking about the Josh> implementation? I was talking about the IETF. However this statement was made before reading your comment that an expert on RADIUS recommended against ignoring the MTU issue. 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: Tue, 23 Feb 2010 19:11:04 -0500 Subject: Re: SAML RADIUS Binding Message-Id: <200305122255.h4CMt1U02501@example.com> To: abfab@ietf.org MIME-Version: 1.0 Josh Howlett wrote on 2010-02-23: >> Is there any harm in processing or decorating it such that we >> can obtain the kinds of semantics we've been discussing? There's no harm unless the processing is expected to be performed by the client of the URL. The URL in question is expected to be opaque to the client with the exception of a convention to construct a URL if you know the endpoint and the Assertion ID. A different set of rules could be created with a different binding layered on top of the original one. > Reading SAML2Core section 2.3, would it be cleaner to use > AssertionURIRef instead, defining some namespace for this purpose? I don't think there's much difference, really. > Thinking aloud, might there also be some advantage in using the SAML URI > Binding rather than the Assertion Request Profile? The SAML URI Binding > is somewhat more lightweight. It's more lightweight at the cost of limiting the security features to HTTP, rather than SOAP. If I understand what you're thinking about, I think all that is moot here because you're looking for different places to put the authentication of the peers and trying to exchange a hash along with the data you want to pass because the channel is already supposed to be authenticated. -- Scott 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: Wed, 24 Feb 2010 10:06:47 -0500 Subject: Re: SAML RADIUS Binding Message-Id: <200305122255.h4CMt1U02501@example.com> To: abfab@ietf.org MIME-Version: 1.0 Josh Howlett wrote on 2010-02-24: >> It's more lightweight at the cost of limiting the security >> features to HTTP, rather than SOAP. > > Ok, I think that's probably a feature in this context. I can't see what > value SOAP adds. A framework for message-level authentication, basically, in particular the ability to use SAML assertions as a credential (recursive use, basically). There really is nothing else (in wide use) that supports the use of SAML that way on a message-oriented basis. -- Scott 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, 25 Feb 2010 14:27:17 -0500 Comments: cc: smb@cs.columbia.edu, vumip1@gmail.com Message-Id: <200305122255.h4CMt1U02501@example.com> To: abfab@ietf.org MIME-Version: 1.0 Folks, I've been talking to Vumip Khasnabish who is working on organizing a cloud computing bar bof. It seems that having cloud computing and federated authentication at the same time would be a bad idea: I suspect a lot of us want to go to both. Vumip was hoping that the clouds bof would land on Wednesday. If that happens I'd like to meet on Thursday. In terms of timing, I've never done this before. Do I want to do something like 9 PM-10:30 so people can grab a bite to eat before and so that those who wish may join the discussion of IPv6 deployment that will be ongoing by the time we conclude? --Sam 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, 25 Feb 2010 21:36:15 +0100 Content-Type: text/plain; charset=us-ascii Message-Id: <200305122255.h4CMt1U02501@example.com> To: abfab@ietf.org Mime-Version: 1.0 (Apple Message framework v1077) On Feb 25, 2010, at 8:27 PM, Sam Hartman wrote: Hi Sam, Either earlier and grab something to eat and keep the discussion going = afterwards or your proposal work for me. Klaas > Folks, I've been talking to Vumip Khasnabish who is working on > organizing a cloud computing bar bof. It seems that having cloud > computing and federated authentication at the same time would be a bad > idea: I suspect a lot of us want to go to both. Vumip was hoping that > the clouds bof would land on Wednesday. If that happens I'd like to > meet on Thursday. >=20 > In terms of timing, I've never done this before. Do I want to do > something like 9 PM-10:30 so people can grab a bite to eat before and = so > that those who wish may join the discussion of IPv6 deployment that = will > be ongoing by the time we conclude? >=20 > --Sam 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: Fri, 26 Feb 2010 16:38:46 -0500 Subject: Re: What do we use SAML request for? Message-Id: <200305122255.h4CMt1U02501@example.com> To: abfab@ietf.org MIME-Version: 1.0 > Here's what I think we need out of the SAML request. I think it > provides a place for S to indicate what attributes it needs. First, > is this correct? Secondly, is there anything else that our particular > use cases get out of a SAML request? I think the way to answer that is best handled by starting with what you want to get in return, and then in parallel setting out the assumptions made about what knowledge of the user exists between S, the entity making the request (if it's not S), and the IdP. The main thing we have to do is determine the "fit" between those answers and the existing protocols in SAML. -- Scott 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: Fri, 26 Feb 2010 18:23:02 -0500 Subject: Re: What do we use SAML request for? Message-Id: <200305122255.h4CMt1U02501@example.com> To: abfab@ietf.org MIME-Version: 1.0 > At the risk of generalising, I think it is interesting to consider > whether we can extrapolate from today's Web SSO practices, > particularly as in the use-cases we're not using SAML for > authentication (where we might care about LoA etc); only as a source > of attributes. The SAML IdP, consequently, says what goes and what doesn't and > the request is moot. Well, it's not moot because of the identifier question, but yes, I thought about mentioning that. The issues there are essentially whether users can consent in real time, and/or whether requirements from the service's end vary dynamically. Without one of those cases, you get pretty much nothing from requesting specific attributes, and in fact the Shibboleth IdP doesn't currently handle queries that specify them. (It should/will at some point soon.) -- Scott 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: Fri, 26 Feb 2010 20:39:14 -0500 Subject: Re: What do we use SAML request for? Message-Id: <200305122255.h4CMt1U02501@example.com> To: abfab@ietf.org MIME-Version: 1.0 >> whether requirements from the service's end >> vary dynamically. > > When you say dynamically, do you mean faster than requirements can be > managed out-of-band? Yes, that's a better way of saying it. -- Scott 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: Sun, 28 Feb 2010 15:21:02 -0500 Subject: Re: Consent (was RE: What do we use SAML request for?) Message-Id: <200305122255.h4CMt1U02501@example.com> To: abfab@ietf.org MIME-Version: 1.0 > I find the consent issue particularly interesting (bear with me...). One > of the benefits that we get from the browser-bound bindings is the > opportunity to interrogate the user about things like consent. Yes, for a lot of people that's *the* issue that argues for hacking WebSSO or OAuth to do basically anything you have to do. > The Interaction Service is a fairly simple spec, but there are probably > other approaches we should also consider. Ideas welcome! The original service in Liberty that I was familiar with had basically no meaningful support for the back channel. It had the ability to redirect you (web style, basically a lot like OAuth) or to tunnel information back from a service through the service's client, and then on to the original web client. Security-wise, that model was of course quite silly, since you were trusting the service that needed consent to relay your (unauthenticated) indication of consent. The last time this came up, I was given the impression that the later versions of the Interaction Service had other options that were more secure, but I haven't actually read it recently. It seems like your secure tunnel between the home domain and the supplicant offers a way to deal with this, but one issue is that the thing at the end of the tunnel isn't likely to be the IdP, so there's more glue needed. -- Scott 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: Sun, 28 Feb 2010 15:34:59 -0500 message of \"Sun, 28 Feb 2010 15:21:02 -0500\") Message-Id: <200305122255.h4CMt1U02501@example.com> To: abfab@ietf.org MIME-Version: 1.0 >>>>> "Scott" == Scott Cantor writes: Scott> It seems like your secure tunnel between the home domain and Scott> the supplicant offers a way to deal with this, but one issue Scott> is that the thing at the end of the tunnel isn't likely to be Scott> the IdP, so there's more glue needed. Another issue is that GSS and EAP basically have no concept of this at all. You could potentially define a tunneled EAP method for this conversation but it's definitely going to be ugly and a significant change to whatever you're looking at.