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 From: Sam Hartman Message-Id: <200305122255.h4CMt1U02501@example.com> To: RANDOM_USER@example.com Subject: Re: Consent MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii >>>>> "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. 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 From: Scott Cantor Message-Id: <200305122255.h4CMt1U02501@example.com> To: RANDOM_USER@example.com Organization: The Ohio State University MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit > 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 11:17:02 -0500 From: Sam Hartman Message-Id: <200305122255.h4CMt1U02501@example.com> To: RANDOM_USER@example.com Subject: Domain based names vs host+realm Content-Type: text/plain; charset=us-ascii nico, I'm writing up the 00 draft of the moonshot mechanism based on a draft I received from Josh. Like Kerberos, moonshot needs to solve the host-to-realm mapping problem. It manifests differently though. There is likely to be a server AAA proxy near the server. That proxy is responsible for deciding whether the authentication request comes from the indicated host. The request eventually gets to an EAP server. The EAP server probably only has the identity of the visited realm of the server proxy [1]. So it must decide whether that visited realm is a reasonable realm to claim the hostname that the acceptor claims. In some ways that's easier than Kerberos. We probably also want a name form that includes a host, service and realm. Syntactically that's the same as a domain-based name. It's my opinion though that semantically it's not a domain-based name and thus we should not use that name type. Do you agree? [1] It's possible the EAP server may not know the visited realm. We can't actually make that case wrok from a security standpoint so we'll have to require the EAP server to know the visited realm. --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 23:58:57 -0000 From: Josh Howlett Message-Id: <200305122255.h4CMt1U02501@example.com> To: RANDOM_USER@example.com Subject: Re: What do we use SAML request for? Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable > whether requirements from the service's end=20 > vary dynamically. When you say dynamically, do you mean faster than requirements can be managed out-of-band? 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: Fri, 26 Feb 2010 23:55:40 -0000 From: Josh Howlett Message-Id: <200305122255.h4CMt1U02501@example.com> To: RANDOM_USER@example.com Subject: Consent (was RE: What do we use SAML request for?) Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable > The issues there are essentially whether users can consent in=20 > real time 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. In Moonshot, the SAML messages are bound to a back-channel. Therefore, we can't apply the same kind of stratgy for obtaining consent. But, in many scenarios, consent is still necessary. How should we address this? Given that we're assuming the existence of a supplicant for driving identity selection and authentication, I'm also inclined to use the supplicant for consent. How would we do this? There's probably a lot of ways to model this, but I've been looking at the Liberty Alliance Interaction Service. As the name suggests, this defines a way for entities to pose questions to users. In brief, the supplicant and the user's IdP establish an HTTP connection; when an attribute request message hits the IdP, it could optionally send an interaction service message to the supplicant, which would construct a form in the supplicant for the user to complete. The user makes a decision, and the supplicant sends it back and the IdP would act on this information. We could do a lot of interesting things; for example, the supplicant could maintain a local consent policy database, or it could sync these with the IdP's own consent management database and delegate the consent decision to the IdP. The Interaction Service is a fairly simple spec, but there are probably other approaches we should also consider. Ideas welcome! josh. JANET(UK) is a trading name of The JNT Association, a company limited by guarantee which is registered in England under No. 2881024=20 and whose Registered Office is at Lumen House, Library Avenue, Harwell Science and Innovation Campus, Didcot, Oxfordshire. OX11 0SG 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 23:08:28 -0000 From: Josh Howlett Message-Id: <200305122255.h4CMt1U02501@example.com> To: RANDOM_USER@example.com Subject: Re: What do we use SAML request for? Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable > > Here's what I think we need out of the SAML request. I think it=20 > > provides a place for S to indicate what attributes it=20 > needs. First,=20 > > is this correct? Secondly, is there anything else that our=20 > particular=20 > > use cases get out of a SAML request? >=20 > I think the way to answer that is best handled by starting=20 > with what you want to get in return, and then in parallel=20 > setting out the assumptions made about what knowledge of the=20 > user exists between S, the entity making the request (if it's=20 > not S), and the IdP. >=20 > The main thing we have to do is determine the "fit" between=20 > those answers and the existing protocols in SAML. 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. 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: Fri, 26 Feb 2010 20:39:14 -0500 From: Scott Cantor Message-Id: <200305122255.h4CMt1U02501@example.com> To: RANDOM_USER@example.com Organization: The Ohio State University MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit >> 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: Fri, 26 Feb 2010 18:23:02 -0500 From: Scott Cantor Message-Id: <200305122255.h4CMt1U02501@example.com> To: RANDOM_USER@example.com Organization: The Ohio State University MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit > 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 16:38:46 -0500 From: Scott Cantor Message-Id: <200305122255.h4CMt1U02501@example.com> To: RANDOM_USER@example.com Organization: The Ohio State University MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit > 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 14:38:21 -0500 From: Sam Hartman Message-Id: <200305122255.h4CMt1U02501@example.com> To: RANDOM_USER@example.com Subject: What do we use SAML request for? So, in a side conversation, Scott, Josh and I have been discussing the SAML request that goes from S to TAC and thus to C's IDP. During that discussion I realized that I don't have a clear idea of what we're using the SAML request to accomplish. 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? --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 From: Klaas Wierenga Message-Id: <200305122255.h4CMt1U02501@example.com> To: RANDOM_USER@example.com Subject: Re: Federated authentication bar bof probably Thursday evening Mime-Version: 1.0 (Apple Message framework v1077) Content-Transfer-Encoding: quoted-printable 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: Thu, 25 Feb 2010 19:05:32 -0500 From: Thomas Hardjono Message-Id: <200305122255.h4CMt1U02501@example.com> To: RANDOM_USER@example.com Subject: Re: Federated authentication bar bof probably Thursday evening MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sam, I plan to attend both. So it would be good to have them on separate times/days. cheers, /thomas/ > -----Original Message----- > From: Moonshot community list [mailto:MOONSHOT-COMMUNITY@JISCMAIL.AC.UK] On > Behalf Of Sam Hartman > Sent: Thursday, February 25, 2010 2:27 PM > To: MOONSHOT-COMMUNITY@JISCMAIL.AC.UK > Subject: Federated authentication bar bof probably Thursday evening > > 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 14:27:17 -0500 From: Sam Hartman Message-Id: <200305122255.h4CMt1U02501@example.com> To: RANDOM_USER@example.com Subject: Federated authentication bar bof probably Thursday evening Content-Type: text/plain; charset=us-ascii 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: Wed, 24 Feb 2010 13:57:06 -0000 From: Josh Howlett Message-Id: <200305122255.h4CMt1U02501@example.com> To: RANDOM_USER@example.com Subject: Re: SAML RADIUS Binding Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable > > Reading SAML2Core section 2.3, would it be cleaner to use=20 > > AssertionURIRef instead, defining some namespace for this purpose? >=20 > I don't think there's much difference, really. I was thinking about what this might mean for the implementer of a SAML issuer. Decorating the assertion ID with these semantics surely implies that the code that constructs the assertion needs to be aware of binding that will be used to obtain it, or else it must decorate all assertions using this method; both seem rather intrusive. If we use a URI reference, I don't think we need to touch that part of the SAML issuer. =20 > > Thinking aloud, might there also be some advantage in using=20 > the SAML=20 > > URI Binding rather than the Assertion Request Profile? The SAML URI=20 > > Binding is somewhat more lightweight. >=20 > It's more lightweight at the cost of limiting the security=20 > 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. > If I understand what you're thinking about, I think all that=20 > is moot here because you're looking for different places to=20 > put the authentication of the peers and trying to exchange a=20 > hash along with the data you want to pass because the channel=20 > is already supposed to be authenticated. That's what I was thinking. 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: Wed, 24 Feb 2010 10:06:47 -0500 From: Scott Cantor Message-Id: <200305122255.h4CMt1U02501@example.com> To: RANDOM_USER@example.com Organization: The Ohio State University MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit 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: Tue, 23 Feb 2010 22:51:10 -0000 From: Josh Howlett Message-Id: <200305122255.h4CMt1U02501@example.com> To: RANDOM_USER@example.com Subject: Re: SAML RADIUS Binding Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Josh wrote: > > The AssertionIdRef is basically just consumed by the relying party,=20 > > there aren't any rules in the spec for processing it or=20 > decorating it. >=20 > Is there any harm in processing or decorating it such that we=20 > can obtain the kinds of semantics we've been discussing? Reading SAML2Core section 2.3, would it be cleaner to use AssertionURIRef instead, defining some namespace for this purpose? 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. 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: Tue, 23 Feb 2010 22:36:34 -0000 From: Josh Howlett Message-Id: <200305122255.h4CMt1U02501@example.com> To: RANDOM_USER@example.com Subject: Re: SAML RADIUS Binding Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Scott wrote: > Josh Howlett wrote on 2010-02-18: > > That makes a lot of sense. If you recall, the original=20 > approach was to=20 > > avoid authentication (which would imply a turtle issue) of the=20 > > call-back responder by attempting to match a hash claimed in the=20 > > artifact to the SAML message that it resolves. I believe we can=20 > > achieve a semantically equivalent effect by incorporating the same=20 > > hash in the AssertionIdRef value. >=20 > The AssertionIdRef is basically just consumed by the relying=20 > party, there aren't any rules in the spec for processing it=20 > or decorating it. Is there any harm in processing or decorating it such that we can obtain the kinds of semantics we've been discussing? 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: Tue, 23 Feb 2010 19:11:04 -0500 From: Scott Cantor Message-Id: <200305122255.h4CMt1U02501@example.com> To: RANDOM_USER@example.com Organization: The Ohio State University MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit 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: Tue, 23 Feb 2010 16:52:29 +0100 From: Alan DeKok Message-Id: <200305122255.h4CMt1U02501@example.com> To: RANDOM_USER@example.com Subject: Re: SAML RADIUS Binding Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Josh Howlett wrote: > Alan wrote: >> No. The RADEXT WG has specifically rejected any attempt to >> increase the RADIUS MTU. > > What was the reason(s) given? It would involve changes to the base spec, and could have unforeseen side effects. Alan DeKok. 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 13:32:46 -0000 From: Josh Howlett Message-Id: <200305122255.h4CMt1U02501@example.com> To: RANDOM_USER@example.com Subject: Re: SAML RADIUS Binding Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Alan wrote: > Josh Howlett wrote: > > Sam wrote: > >> First, I think the right technical approach is to ignore the RADIUS > >> MTU issue. > >=20 > > Would this be acceptable to IETF?=20 >=20 > No. The RADEXT WG has specifically rejected any attempt to=20 > increase the RADIUS MTU. What was the reason(s) given? 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: Tue, 23 Feb 2010 08:37:15 +0000 From: Alan DeKok Message-Id: <200305122255.h4CMt1U02501@example.com> To: RANDOM_USER@example.com Subject: Re: SAML RADIUS Binding Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Josh Howlett wrote: > Sam wrote: >> First, I think the right technical approach is to ignore the >> RADIUS MTU issue. > > Would this be acceptable to IETF? No. The RADEXT WG has specifically rejected any attempt to increase the RADIUS MTU. > Ot are you talking about the implementation? A number of implementations are more "forgiving" about MTU. Alan DeKok. 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 22:40:05 -0000 From: Josh Howlett Message-Id: <200305122255.h4CMt1U02501@example.com> To: RANDOM_USER@example.com Subject: Re: SAML RADIUS Binding Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable > How many Moonshot folks will be at IETF 77 in Anaheim? I'll=20 > be there so I'd be happy to chat with you about it then. We're planning a Bar BOF; more on this shortly. 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 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 20:24:56 -0000 From: Josh Howlett Message-Id: <200305122255.h4CMt1U02501@example.com> To: RANDOM_USER@example.com Subject: Re: SAML RADIUS Binding Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Peter, > You do have some XMPP experts on this list. :) Thanks for dropping by :-) > I'd be happy to have a chat with you and=20 > anyone else who's interested so that we can figure out what=20 > your requirements are and whether XMPP meets those=20 > requirements (or can be extended to do so). Perhaps we can=20 > set up a conference call in the near future? Having spoken to others off-line, I think that it is likely that defining a new lower-layer for EAP (while attractive in principle) will introduce a host of other issues. Looking at this pragmatically, there is a strong argument for "better the devil you know". It could be that we end up defining a new EAP lower-layer if we fail with RadSec/RADIUS, but at least we'll be better informed having tried. I am personally still interested in exploring this possibility, but I think we should consider this a 'research' topic and proceed with the SAML RADIUS Binding as originally proposed. In terms of having a call, I suggest that we wait until we have finished documenting the use-cases and the concrete technical proposal to address these. Hopefully Sam and I will have this done within 3 weeks or so. That will provide a dart-board that other ideas can take aim against. Thank you for your offer, and I look forward to having this discussion! 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 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 18:17:33 -0000 From: Josh Howlett Message-Id: <200305122255.h4CMt1U02501@example.com> To: RANDOM_USER@example.com Subject: Re: SAML RADIUS Binding Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Sam wrote: > First, I think the right technical approach is to ignore the=20 > RADIUS MTU issue. Would this be acceptable to IETF? Ot are you talking about the implementation? 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: Mon, 22 Feb 2010 15:34:49 -0700 From: Peter Saint-Andre Message-Id: <200305122255.h4CMt1U02501@example.com> To: RANDOM_USER@example.com Subject: Re: SAML RADIUS Binding Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms040402020707010106020501" This is a cryptographically signed message in MIME format. --------------ms040402020707010106020501 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 2/22/10 1:24 PM, Josh Howlett wrote: > Hi Peter, >=20 >> You do have some XMPP experts on this list. :) >=20 > Thanks for dropping by :-) >=20 >> I'd be happy to have a chat with you and=20 >> anyone else who's interested so that we can figure out what=20 >> your requirements are and whether XMPP meets those=20 >> requirements (or can be extended to do so). Perhaps we can=20 >> set up a conference call in the near future? >=20 > Having spoken to others off-line, I think that it is likely that > defining a new lower-layer for EAP (while attractive in principle) will= > introduce a host of other issues. Looking at this pragmatically, there > is a strong argument for "better the devil you know". >=20 > It could be that we end up defining a new EAP lower-layer if we fail > with RadSec/RADIUS, but at least we'll be better informed having tried.= Yes, that might make more sense. Depending on your requirements, naturally. :) > I am personally still interested in exploring this possibility, but I > think we should consider this a 'research' topic and proceed with the > SAML RADIUS Binding as originally proposed. >=20 > In terms of having a call, I suggest that we wait until we have finishe= d > documenting the use-cases and the concrete technical proposal to addres= s > these. Hopefully Sam and I will have this done within 3 weeks or so. > That will provide a dart-board that other ideas can take aim against. >=20 > Thank you for your offer, and I look forward to having this discussion!= How many Moonshot folks will be at IETF 77 in Anaheim? I'll be there so I'd be happy to chat with you about it then. Peter --=20 Peter Saint-Andre https://stpeter.im/ --------------ms040402020707010106020501 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIWnDCC B1cwggY/oAMCAQICAVUwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQK Ew1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBT aWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRl IENsaWVudCBDQTAeFw0wOTA3MDYwMDAwMDFaFw0xMDA3MDYyMzU5NTlaMIHCMQswCQYDVQQG EwJVUzERMA8GA1UECBMIQ29sb3JhZG8xDzANBgNVBAcTBkRlbnZlcjEiMCAGA1UEChMZWE1Q UCBTdGFuZGFyZHMgRm91bmRhdGlvbjEsMCoGA1UECxMjU3RhcnRDb20gVHJ1c3RlZCBDZXJ0 aWZpY2F0ZSBNZW1iZXIxGjAYBgNVBAMTEVBldGVyIFNhaW50LUFuZHJlMSEwHwYJKoZIhvcN AQkBFhJzdHBldGVyQHN0cGV0ZXIuaW0wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCas7Mrnh02GakN8sft+HJpU4MwBxEgrGDZ2ZzUxDDt2sEhM+9Q74h955MtgMhK3TeBf6Hs hDh/8Z9G//k2qNA0M2S5rejTqrmW0Jabca/L7BUZ0GhnU2N/2zeciFUmuZ4A2l1T5IMX2ZVP XnNIaefBtbImJAbDz3T0vxkzTtcqgW3wL83PMDiqiuM+e1k+VPvOW4f5ZSGkPIhYCDpWqNE5 wZvjrLNMc8jZOPs9DrsYuIVwU72Vhy1tkEh+w6YpYHrdEUAe+eKe6TuxqZ60e9z3O36uiV// Ms274iD6PbA/IGazJgaAdg6tvPehwTYGJAGmv3PsJKkLGjgoh+RrrM1LAgMBAAGjggOKMIID hjAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUH AwQwHQYDVR0OBBYEFOyws3XWgIY9FP1POVqjdZP9Lu38MB0GA1UdEQQWMBSBEnN0cGV0ZXJA c3RwZXRlci5pbTCBqAYDVR0jBIGgMIGdgBR7iZySlyShhEcCy3T8LvSs3DLl86GBgaR/MH0x CzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUg RGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQDEyBTdGFydENvbSBDZXJ0aWZp Y2F0aW9uIEF1dGhvcml0eYIBDzCCAUcGA1UdIASCAT4wggE6MIIBNgYLKwYBBAGBtTcBAgAw ggElMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMDQG CCsGAQUFBwIBFihodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUucGRmMIG8 BggrBgEFBQcCAjCBrzAUFg1TdGFydENvbSBMdGQuMAMCAQEagZZMaW1pdGVkIExpYWJpbGl0 eSwgcmVhZCB0aGUgc2VjdGlvbiAqTGVnYWwgTGltaXRhdGlvbnMqIG9mIHRoZSBTdGFydENv bSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSBQb2xpY3kgYXZhaWxhYmxlIGF0IGh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwYwYDVR0fBFwwWjAroCmgJ4YlaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vY3J0dTMtY3JsLmNybDAroCmgJ4YlaHR0cDovL2NybC5zdGFydHNz bC5jb20vY3J0dTMtY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5BggrBgEFBQcwAYYtaHR0 cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFzczMvY2xpZW50L2NhMEIGCCsGAQUFBzAC hjZodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9jZXJ0cy9zdWIuY2xhc3MzLmNsaWVudC5jYS5j cnQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0GCSqGSIb3DQEBBQUA A4IBAQBgv4xFXZqDKSOtnPOVbqOh1brj7oxRaVYk7N0MJG7x9Y/wkO3iwRwizVLcC1bA+D/R gyFilXx6IQWE63Ge2tu+Y4w5QoHYwuUFQuBZuxvZpOa3ykdgPlBQaBM8m+Ien0skwNggaizA X9Pc/sMLpP3jkO1iSF4agy4r5Ed+4G10mP5X0zO3gQwq9Uj4F9tX+58kU+fM1P8Sh+BYR4r/ kSbKE3tWcMaKblWPGwX0nYD26Je7Qb+uX/J5lCgozBrHXQWq8N98iklASf2pv+32Oi1dEjmM UgAm/J2+YmxaI02+c+H6QH8+F3RUjCiRg9XqUNjcrNrnTFnm/iMMZADktsXPMIIHVzCCBj+g AwIBAgIBVTANBgkqhkiG9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcx ODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50 IENBMB4XDTA5MDcwNjAwMDAwMVoXDTEwMDcwNjIzNTk1OVowgcIxCzAJBgNVBAYTAlVTMREw DwYDVQQIEwhDb2xvcmFkbzEPMA0GA1UEBxMGRGVudmVyMSIwIAYDVQQKExlYTVBQIFN0YW5k YXJkcyBGb3VuZGF0aW9uMSwwKgYDVQQLEyNTdGFydENvbSBUcnVzdGVkIENlcnRpZmljYXRl IE1lbWJlcjEaMBgGA1UEAxMRUGV0ZXIgU2FpbnQtQW5kcmUxITAfBgkqhkiG9w0BCQEWEnN0 cGV0ZXJAc3RwZXRlci5pbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAJqzsyue HTYZqQ3yx+34cmlTgzAHESCsYNnZnNTEMO3awSEz71DviH3nky2AyErdN4F/oeyEOH/xn0b/ +Tao0DQzZLmt6NOquZbQlptxr8vsFRnQaGdTY3/bN5yIVSa5ngDaXVPkgxfZlU9ec0hp58G1 siYkBsPPdPS/GTNO1yqBbfAvzc8wOKqK4z57WT5U+85bh/llIaQ8iFgIOlao0TnBm+Oss0xz yNk4+z0Ouxi4hXBTvZWHLW2QSH7Dpilget0RQB754p7pO7GpnrR73Pc7fq6JX/8yzbviIPo9 sD8gZrMmBoB2Dq2896HBNgYkAaa/c+wkqQsaOCiH5GuszUsCAwEAAaOCA4owggOGMAkGA1Ud EwQCMAAwCwYDVR0PBAQDAgSwMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAdBgNV HQ4EFgQU7LCzddaAhj0U/U85WqN1k/0u7fwwHQYDVR0RBBYwFIESc3RwZXRlckBzdHBldGVy LmltMIGoBgNVHSMEgaAwgZ2AFHuJnJKXJKGERwLLdPwu9KzcMuXzoYGBpH8wfTELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs IENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5ggEPMIIBRwYDVR0gBIIBPjCCATowggE2BgsrBgEEAYG1NwECADCCASUwLgYI KwYBBQUHAgEWImh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUH AgEWKGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwgbwGCCsGAQUF BwICMIGvMBQWDVN0YXJ0Q29tIEx0ZC4wAwIBARqBlkxpbWl0ZWQgTGlhYmlsaXR5LCByZWFk IHRoZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRp ZmljYXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL3d3dy5zdGFy dHNzbC5jb20vcG9saWN5LnBkZjBjBgNVHR8EXDBaMCugKaAnhiVodHRwOi8vd3d3LnN0YXJ0 c3NsLmNvbS9jcnR1My1jcmwuY3JsMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9j cnR1My1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2Nz cC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMy9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczMuY2xpZW50LmNhLmNydDAjBgNV HRIEHDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBAGC/ jEVdmoMpI62c85Vuo6HVuuPujFFpViTs3QwkbvH1j/CQ7eLBHCLNUtwLVsD4P9GDIWKVfHoh BYTrcZ7a275jjDlCgdjC5QVC4Fm7G9mk5rfKR2A+UFBoEzyb4h6fSyTA2CBqLMBf09z+wwuk /eOQ7WJIXhqDLivkR37gbXSY/lfTM7eBDCr1SPgX21f7nyRT58zU/xKH4FhHiv+RJsoTe1Zw xopuVY8bBfSdgPbol7tBv65f8nmUKCjMGsddBarw33yKSUBJ/am/7fY6LV0SOYxSACb8nb5i bFojTb5z4fpAfz4XdFSMKJGD1epQ2Nys2udMWeb+IwxkAOS2xc8wggfiMIIFyqADAgECAgEP MA0GCSqGSIb3DQEBBQUAMH0xCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQu MSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQD EyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0wNzEwMjQyMTAzMzJaFw0x MjEwMjIyMTAzMzJaMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEr MCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMv U3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwggEiMA0G CSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC5o0luEj4gypQIp71Xi2TlXyLYrj9WkRy+d9BO 0FHPYnAsC99/jx/ibNRwIfAoFhZd+LDscdRSckvwuFSz0bKg3z+9o7cwlVAC9AwMWe8IM0Lx c+8etYxsX4WIamG9fjzzi5GAW5ESKzzIN3SxHSplyGCWFwx/pgf1f4y6O9/ym+4f6zaDYP6B x0r+SaJcr6eSGNm7X3EwX1v7XpRBY+aw019o7k72d0IX910F+XGt0OwNdM61Ff3FiTiexeUZ bWxCGm6GZl+SQVG9xYVIgHQaLXoQF+g2wzrmKCbVcZhqH+hrlRnD6PfCuEyX/BR6PlAPRDlQ 6f1u3wqik+LF5P15AgMBAAGjggNbMIIDVzAMBgNVHRMEBTADAQH/MAsGA1UdDwQEAwIBpjAd BgNVHQ4EFgQUe4mckpckoYRHAst0/C70rNwy5fMwgagGA1UdIwSBoDCBnYAUTgvvGqRAW6UX aYcwyjRoQ9BBrvKhgYGkfzB9MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzEpMCcGA1UE AxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHmCAQEwCQYDVR0SBAIwADA9Bggr BgEFBQcBAQQxMC8wLQYIKwYBBQUHMAKGIWh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2Nh LmNydDBgBgNVHR8EWTBXMCygKqAohiZodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvc2ZzY2Et Y3JsLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20vc2ZzY2EuY3JsMIIBXQYD VR0gBIIBVDCCAVAwggFMBgsrBgEEAYG1NwEBBDCCATswLwYIKwYBBQUHAgEWI2h0dHA6Ly9j ZXJ0LnN0YXJ0Y29tLm9yZy9wb2xpY3kucGRmMDUGCCsGAQUFBwIBFilodHRwOi8vY2VydC5z dGFydGNvbS5vcmcvaW50ZXJtZWRpYXRlLnBkZjCB0AYIKwYBBQUHAgIwgcMwJxYgU3RhcnQg Q29tbWVyY2lhbCAoU3RhcnRDb20pIEx0ZC4wAwIBARqBl0xpbWl0ZWQgTGlhYmlsaXR5LCBy ZWFkIHRoZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENl cnRpZmljYXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL2NlcnQu c3RhcnRjb20ub3JnL3BvbGljeS5wZGYwEQYJYIZIAYb4QgEBBAQDAgAHMFAGCWCGSAGG+EIB DQRDFkFTdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIEZyZWUgU1NMIEVt YWlsIENlcnRpZmljYXRlczANBgkqhkiG9w0BAQUFAAOCAgEAUpcEDdsKFRCxFBxcSm+8oMTT fpS7fbZkxWHx5fHDjvAgaBQ+oY0tk4xtbD6VxeHYjxI63+hj8jICnqeVXPe34Bu+XzekIn2T lrnPCQobKdQF2p52QgUvIxSURed0jcBaCBV22DSKaUqDOzD/Tx6VQy78zpblXjRH7OALE/+H jzJVmspdnBUUtQOLYgPo924xkxR25VDdgtEE5vAXa/g2oCeZhy0ZEO4NbgIayAYCJcJRDz0h dD2Ahec65Kw6LB3N7VXEjiRR5/WoKwH/QteRzPJbFDc1somrApjm2cyg+5nbm1RHeFIz+GxX luRrPztvhNcby0PtAjqwY1txi4sW0R6ZJPuZ2DZ1/dzckoFhyZgFyOX3SEkNXVLldjTzneFJ FnVSzDbc720vq184jR7pYoI9+f5QJ96a0iLxEAG8SJ5auBwXI/w2FmKmwmdMvJ8/17+B4sMC IRrXrDQl2xzpVXh/Qcmk5nf+w8HFmqATGy1OUAQbXga7AySAUaYhvvFk50u0bO5DiUGwzrJO 3TrwvaC2Ei4EFaBmIVgG7TfU5TaaY9IcJSCQ7AGUYE3RFSRpsLOoA3DsxP42YERgS/Nxw29+ YqZtPoO2QPbNpI7xnHVCfNBabx3oDIf438nFfv8spw5BQqBSbEF1izJA57eE64CzHnt7lB20 OFD11avYopwxggPKMIIDxgIBATCBkjCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcx ODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50 IENBAgFVMAkGBSsOAwIaBQCgggIMMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZI hvcNAQkFMQ8XDTEwMDIyMjIyMzQ0OVowIwYJKoZIhvcNAQkEMRYEFMlZTLsbJffyhuQImpwu GfOxDQ9iMF8GCSqGSIb3DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBowYJ KwYBBAGCNxAEMYGVMIGSMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UE AxMvU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAVUw gaUGCyqGSIb3DQEJEAILMYGVoIGSMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4 MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQg Q0ECAVUwDQYJKoZIhvcNAQEBBQAEggEARt968dnAo6zFd2C3+4/qeig8ISktGcQirWz9zb8S pbTkeciG2zH2vLYluGaPleuWszFRAsfCSYepSLn8hm05gLvIY47/U0avLEd8aS3UWJjy6+mB 1p6GiK+rpKxOD1pylIYjrk0IUSTHM9PhsTp2lgv5k37MlN7KoK2XdRD9YPDGEYh7oFKG5kjP Ngm82OL7PtQOnR8n/adCEdTvsJiVXqheRHrUJbriG76GNTDPtHmNFIO7s9HQ5LDft4XIYsIG /hkuc9O0zSiG0REIQzum17YgcEDXHeyE8GSDVwkpk8vPbP4UzkWjdRVTA0vUN27nhIx0W31H afrEbHPpb2u0XQAAAAAAAA== --------------ms040402020707010106020501-- 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:32:37 -0500 From: Sam Hartman Message-Id: <200305122255.h4CMt1U02501@example.com> To: RANDOM_USER@example.com Subject: Re: SAML RADIUS Binding MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii >>>>> "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: Mon, 22 Feb 2010 15:31:11 -0500 From: Sam Hartman Message-Id: <200305122255.h4CMt1U02501@example.com> To: RANDOM_USER@example.com Subject: Re: SAML RADIUS Binding MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii >>>>> "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: 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 From: Scott Cantor Message-Id: <200305122255.h4CMt1U02501@example.com> To: RANDOM_USER@example.com Organization: The Ohio State University MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit 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 11:06:56 -0500 From: Sam Hartman Message-Id: <200305122255.h4CMt1U02501@example.com> To: RANDOM_USER@example.com Subject: Re: SAML RADIUS Binding MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii >>>>> "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 10:12:06 -0500 From: Scott Cantor Message-Id: <200305122255.h4CMt1U02501@example.com> To: RANDOM_USER@example.com Organization: The Ohio State University MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit 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 10:04:04 -0500 From: Sam Hartman Message-Id: <200305122255.h4CMt1U02501@example.com> To: RANDOM_USER@example.com Subject: Re: SAML RADIUS Binding MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii >>>>> "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 09:37:48 -0500 From: Sam Hartman Message-Id: <200305122255.h4CMt1U02501@example.com> To: RANDOM_USER@example.com Subject: Re: SAML RADIUS Binding MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii 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: 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 08:21:44 -0700 From: Peter Saint-Andre Message-Id: <200305122255.h4CMt1U02501@example.com> To: RANDOM_USER@example.com Subject: Re: SAML RADIUS Binding MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms040603030409010605010303" This is a cryptographically signed message in MIME format. --------------ms040603030409010605010303 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 2/18/10 2:53 AM, Josh Howlett wrote: >> So as I suspected, this is about message size? XML =3D=3D bad fit=20 >> for size constrained protocols. >=20 > 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.=20 > =20 >>> We discussed various alternative strategies, including=20 >> Diameter, XMPP=20 >>> messaging, a lightweight XML schema over HTTP, or the use of WS-=20 >>> Securitybinary tokens. Stefan is leaning towards XML over HTTP, but=20 >>> XMPP looks more interesting to me. >> =20 >> It might be more interesting, but are there compelling=20 >> functional advantages? >=20 > I think these are the desirable technical properties & abstractions of > the inter trust authority EAP transport protocol: >=20 > - reliable transport. > - mutual authentication of transport peers, ideally using GSS. > - request / response message framing with multiple round-trips over a > constant transport. > - message types that can hold EAP packets, EAP keys & channel bindings > and SAML request/response messages (by value). > - message source/destination semantics. > - message routing over multiple hops. > - a conversation abtraction between peers seperated by multiple hops > using multiple message round-trips > - message and/or conversation and/or transport integrity & > confidentiality. > - message extensibility >=20 > I believe that all of the strategies listed above have (or could be > feasibility extended to have) these properties. >=20 > I am presently leaning towards XMPP because (as I understand it) the > base protocol (and perhaps also extensions like In-Band Bytestreams) > gets us these properties without significant further profiling required= > (c.f. use of WS-Security & binary security tokens, where very > significant profiling would be required). Hi Josh, You do have some XMPP experts on this list. :) Although naturally I am partial to XMPP, it's not always the best tool for the job. Here I think that it meets most or all of your needs, but to know for sure I'd need to know a bit more about what you mean in this context by "reliable transport", "framing", "multiple hops", "integrity", and "confidentiality". I'd be happy to have a chat with you and anyone else who's interested so that we can figure out what your requirements are and whether XMPP meets those requirements (or can be extended to do so). Perhaps we can set up a conference call in the near future? Peter --=20 Peter Saint-Andre https://stpeter.im/ --------------ms040603030409010605010303 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIWnDCC B1cwggY/oAMCAQICAVUwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQK Ew1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBT aWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRl IENsaWVudCBDQTAeFw0wOTA3MDYwMDAwMDFaFw0xMDA3MDYyMzU5NTlaMIHCMQswCQYDVQQG EwJVUzERMA8GA1UECBMIQ29sb3JhZG8xDzANBgNVBAcTBkRlbnZlcjEiMCAGA1UEChMZWE1Q UCBTdGFuZGFyZHMgRm91bmRhdGlvbjEsMCoGA1UECxMjU3RhcnRDb20gVHJ1c3RlZCBDZXJ0 aWZpY2F0ZSBNZW1iZXIxGjAYBgNVBAMTEVBldGVyIFNhaW50LUFuZHJlMSEwHwYJKoZIhvcN AQkBFhJzdHBldGVyQHN0cGV0ZXIuaW0wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCas7Mrnh02GakN8sft+HJpU4MwBxEgrGDZ2ZzUxDDt2sEhM+9Q74h955MtgMhK3TeBf6Hs hDh/8Z9G//k2qNA0M2S5rejTqrmW0Jabca/L7BUZ0GhnU2N/2zeciFUmuZ4A2l1T5IMX2ZVP XnNIaefBtbImJAbDz3T0vxkzTtcqgW3wL83PMDiqiuM+e1k+VPvOW4f5ZSGkPIhYCDpWqNE5 wZvjrLNMc8jZOPs9DrsYuIVwU72Vhy1tkEh+w6YpYHrdEUAe+eKe6TuxqZ60e9z3O36uiV// Ms274iD6PbA/IGazJgaAdg6tvPehwTYGJAGmv3PsJKkLGjgoh+RrrM1LAgMBAAGjggOKMIID hjAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUH AwQwHQYDVR0OBBYEFOyws3XWgIY9FP1POVqjdZP9Lu38MB0GA1UdEQQWMBSBEnN0cGV0ZXJA c3RwZXRlci5pbTCBqAYDVR0jBIGgMIGdgBR7iZySlyShhEcCy3T8LvSs3DLl86GBgaR/MH0x CzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUg RGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQDEyBTdGFydENvbSBDZXJ0aWZp Y2F0aW9uIEF1dGhvcml0eYIBDzCCAUcGA1UdIASCAT4wggE6MIIBNgYLKwYBBAGBtTcBAgAw ggElMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMDQG CCsGAQUFBwIBFihodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUucGRmMIG8 BggrBgEFBQcCAjCBrzAUFg1TdGFydENvbSBMdGQuMAMCAQEagZZMaW1pdGVkIExpYWJpbGl0 eSwgcmVhZCB0aGUgc2VjdGlvbiAqTGVnYWwgTGltaXRhdGlvbnMqIG9mIHRoZSBTdGFydENv bSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSBQb2xpY3kgYXZhaWxhYmxlIGF0IGh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwYwYDVR0fBFwwWjAroCmgJ4YlaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vY3J0dTMtY3JsLmNybDAroCmgJ4YlaHR0cDovL2NybC5zdGFydHNz bC5jb20vY3J0dTMtY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5BggrBgEFBQcwAYYtaHR0 cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFzczMvY2xpZW50L2NhMEIGCCsGAQUFBzAC hjZodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9jZXJ0cy9zdWIuY2xhc3MzLmNsaWVudC5jYS5j cnQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0GCSqGSIb3DQEBBQUA A4IBAQBgv4xFXZqDKSOtnPOVbqOh1brj7oxRaVYk7N0MJG7x9Y/wkO3iwRwizVLcC1bA+D/R gyFilXx6IQWE63Ge2tu+Y4w5QoHYwuUFQuBZuxvZpOa3ykdgPlBQaBM8m+Ien0skwNggaizA X9Pc/sMLpP3jkO1iSF4agy4r5Ed+4G10mP5X0zO3gQwq9Uj4F9tX+58kU+fM1P8Sh+BYR4r/ kSbKE3tWcMaKblWPGwX0nYD26Je7Qb+uX/J5lCgozBrHXQWq8N98iklASf2pv+32Oi1dEjmM UgAm/J2+YmxaI02+c+H6QH8+F3RUjCiRg9XqUNjcrNrnTFnm/iMMZADktsXPMIIHVzCCBj+g AwIBAgIBVTANBgkqhkiG9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcx ODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50 IENBMB4XDTA5MDcwNjAwMDAwMVoXDTEwMDcwNjIzNTk1OVowgcIxCzAJBgNVBAYTAlVTMREw DwYDVQQIEwhDb2xvcmFkbzEPMA0GA1UEBxMGRGVudmVyMSIwIAYDVQQKExlYTVBQIFN0YW5k YXJkcyBGb3VuZGF0aW9uMSwwKgYDVQQLEyNTdGFydENvbSBUcnVzdGVkIENlcnRpZmljYXRl IE1lbWJlcjEaMBgGA1UEAxMRUGV0ZXIgU2FpbnQtQW5kcmUxITAfBgkqhkiG9w0BCQEWEnN0 cGV0ZXJAc3RwZXRlci5pbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAJqzsyue HTYZqQ3yx+34cmlTgzAHESCsYNnZnNTEMO3awSEz71DviH3nky2AyErdN4F/oeyEOH/xn0b/ +Tao0DQzZLmt6NOquZbQlptxr8vsFRnQaGdTY3/bN5yIVSa5ngDaXVPkgxfZlU9ec0hp58G1 siYkBsPPdPS/GTNO1yqBbfAvzc8wOKqK4z57WT5U+85bh/llIaQ8iFgIOlao0TnBm+Oss0xz yNk4+z0Ouxi4hXBTvZWHLW2QSH7Dpilget0RQB754p7pO7GpnrR73Pc7fq6JX/8yzbviIPo9 sD8gZrMmBoB2Dq2896HBNgYkAaa/c+wkqQsaOCiH5GuszUsCAwEAAaOCA4owggOGMAkGA1Ud EwQCMAAwCwYDVR0PBAQDAgSwMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAdBgNV HQ4EFgQU7LCzddaAhj0U/U85WqN1k/0u7fwwHQYDVR0RBBYwFIESc3RwZXRlckBzdHBldGVy LmltMIGoBgNVHSMEgaAwgZ2AFHuJnJKXJKGERwLLdPwu9KzcMuXzoYGBpH8wfTELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs IENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5ggEPMIIBRwYDVR0gBIIBPjCCATowggE2BgsrBgEEAYG1NwECADCCASUwLgYI KwYBBQUHAgEWImh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUH AgEWKGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwgbwGCCsGAQUF BwICMIGvMBQWDVN0YXJ0Q29tIEx0ZC4wAwIBARqBlkxpbWl0ZWQgTGlhYmlsaXR5LCByZWFk IHRoZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRp ZmljYXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL3d3dy5zdGFy dHNzbC5jb20vcG9saWN5LnBkZjBjBgNVHR8EXDBaMCugKaAnhiVodHRwOi8vd3d3LnN0YXJ0 c3NsLmNvbS9jcnR1My1jcmwuY3JsMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9j cnR1My1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2Nz cC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMy9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczMuY2xpZW50LmNhLmNydDAjBgNV HRIEHDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBAGC/ jEVdmoMpI62c85Vuo6HVuuPujFFpViTs3QwkbvH1j/CQ7eLBHCLNUtwLVsD4P9GDIWKVfHoh BYTrcZ7a275jjDlCgdjC5QVC4Fm7G9mk5rfKR2A+UFBoEzyb4h6fSyTA2CBqLMBf09z+wwuk /eOQ7WJIXhqDLivkR37gbXSY/lfTM7eBDCr1SPgX21f7nyRT58zU/xKH4FhHiv+RJsoTe1Zw xopuVY8bBfSdgPbol7tBv65f8nmUKCjMGsddBarw33yKSUBJ/am/7fY6LV0SOYxSACb8nb5i bFojTb5z4fpAfz4XdFSMKJGD1epQ2Nys2udMWeb+IwxkAOS2xc8wggfiMIIFyqADAgECAgEP MA0GCSqGSIb3DQEBBQUAMH0xCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQu MSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQD EyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0wNzEwMjQyMTAzMzJaFw0x MjEwMjIyMTAzMzJaMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEr MCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMv U3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwggEiMA0G CSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC5o0luEj4gypQIp71Xi2TlXyLYrj9WkRy+d9BO 0FHPYnAsC99/jx/ibNRwIfAoFhZd+LDscdRSckvwuFSz0bKg3z+9o7cwlVAC9AwMWe8IM0Lx c+8etYxsX4WIamG9fjzzi5GAW5ESKzzIN3SxHSplyGCWFwx/pgf1f4y6O9/ym+4f6zaDYP6B x0r+SaJcr6eSGNm7X3EwX1v7XpRBY+aw019o7k72d0IX910F+XGt0OwNdM61Ff3FiTiexeUZ bWxCGm6GZl+SQVG9xYVIgHQaLXoQF+g2wzrmKCbVcZhqH+hrlRnD6PfCuEyX/BR6PlAPRDlQ 6f1u3wqik+LF5P15AgMBAAGjggNbMIIDVzAMBgNVHRMEBTADAQH/MAsGA1UdDwQEAwIBpjAd BgNVHQ4EFgQUe4mckpckoYRHAst0/C70rNwy5fMwgagGA1UdIwSBoDCBnYAUTgvvGqRAW6UX aYcwyjRoQ9BBrvKhgYGkfzB9MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzEpMCcGA1UE AxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHmCAQEwCQYDVR0SBAIwADA9Bggr BgEFBQcBAQQxMC8wLQYIKwYBBQUHMAKGIWh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2Nh LmNydDBgBgNVHR8EWTBXMCygKqAohiZodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvc2ZzY2Et Y3JsLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20vc2ZzY2EuY3JsMIIBXQYD VR0gBIIBVDCCAVAwggFMBgsrBgEEAYG1NwEBBDCCATswLwYIKwYBBQUHAgEWI2h0dHA6Ly9j ZXJ0LnN0YXJ0Y29tLm9yZy9wb2xpY3kucGRmMDUGCCsGAQUFBwIBFilodHRwOi8vY2VydC5z dGFydGNvbS5vcmcvaW50ZXJtZWRpYXRlLnBkZjCB0AYIKwYBBQUHAgIwgcMwJxYgU3RhcnQg Q29tbWVyY2lhbCAoU3RhcnRDb20pIEx0ZC4wAwIBARqBl0xpbWl0ZWQgTGlhYmlsaXR5LCBy ZWFkIHRoZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENl cnRpZmljYXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL2NlcnQu c3RhcnRjb20ub3JnL3BvbGljeS5wZGYwEQYJYIZIAYb4QgEBBAQDAgAHMFAGCWCGSAGG+EIB DQRDFkFTdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIEZyZWUgU1NMIEVt YWlsIENlcnRpZmljYXRlczANBgkqhkiG9w0BAQUFAAOCAgEAUpcEDdsKFRCxFBxcSm+8oMTT fpS7fbZkxWHx5fHDjvAgaBQ+oY0tk4xtbD6VxeHYjxI63+hj8jICnqeVXPe34Bu+XzekIn2T lrnPCQobKdQF2p52QgUvIxSURed0jcBaCBV22DSKaUqDOzD/Tx6VQy78zpblXjRH7OALE/+H jzJVmspdnBUUtQOLYgPo924xkxR25VDdgtEE5vAXa/g2oCeZhy0ZEO4NbgIayAYCJcJRDz0h dD2Ahec65Kw6LB3N7VXEjiRR5/WoKwH/QteRzPJbFDc1somrApjm2cyg+5nbm1RHeFIz+GxX luRrPztvhNcby0PtAjqwY1txi4sW0R6ZJPuZ2DZ1/dzckoFhyZgFyOX3SEkNXVLldjTzneFJ FnVSzDbc720vq184jR7pYoI9+f5QJ96a0iLxEAG8SJ5auBwXI/w2FmKmwmdMvJ8/17+B4sMC IRrXrDQl2xzpVXh/Qcmk5nf+w8HFmqATGy1OUAQbXga7AySAUaYhvvFk50u0bO5DiUGwzrJO 3TrwvaC2Ei4EFaBmIVgG7TfU5TaaY9IcJSCQ7AGUYE3RFSRpsLOoA3DsxP42YERgS/Nxw29+ YqZtPoO2QPbNpI7xnHVCfNBabx3oDIf438nFfv8spw5BQqBSbEF1izJA57eE64CzHnt7lB20 OFD11avYopwxggPKMIIDxgIBATCBkjCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcx ODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50 IENBAgFVMAkGBSsOAwIaBQCgggIMMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZI hvcNAQkFMQ8XDTEwMDIyMjE1MjE0NFowIwYJKoZIhvcNAQkEMRYEFHPj9h24OVqhhSgnCFio F9o9PN6qMF8GCSqGSIb3DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBowYJ KwYBBAGCNxAEMYGVMIGSMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UE AxMvU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAVUw gaUGCyqGSIb3DQEJEAILMYGVoIGSMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4 MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQg Q0ECAVUwDQYJKoZIhvcNAQEBBQAEggEAh6Jt8hQ2KJz2yNrHbSF0tIi/NjzetZXOaYjlceFe UPfxO/4F98Rm5NxOisFt8FQ9oOvHjXGlpcWisyD+dUThdZSMm4bx68Bu6j5Lvr6X/7AJ3pOO swa/m4qTVe6WiJqmJgAy8l4qRXzVCAhpsPPhXa2i4CTqiXUeGMXDwf9NlfzlPjqo8fIHSeqt Gsq0P/ibt2bpONwc3B+XzDVEimwD5SrwZb7zgChZY7rUhHJEMu2RB4yC/0iUJWd8+lVP+fDA 4UwY9jcPVz501KxAH1XylRqAysCON4LXvI9u3JeLpzyUFWVJhoWNXZIvi45xxzmEqCkyQ4G8 m5httWYkEXxH+gAAAAAAAA== --------------ms040603030409010605010303-- 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 19:06:05 -0000 From: Josh Howlett Message-Id: <200305122255.h4CMt1U02501@example.com> To: RANDOM_USER@example.com Subject: Re: SAML RADIUS Binding Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Scott wrote: > If the semantics are such that the assertion=20 > was delivered as part of that conversation, one possibility=20 > would be to deliver it as an assertion reference, not an=20 > artifact, and just dereference it using the Assertion lookup=20 > profile that's already in the spec, via HTTP. It really=20 > depends on the security semantics in play. 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. > One point to make is that if there's no AuthnRequest, there=20 > probably doesn't need to be a Response. So this is probably=20 > just an Assertion anyway. I was originally quite keen to model this exchange as a SAML binding (i.e. a vehicle for SAML request and response messages) in the hope that we might define something of utility beyond this proposal. I guess there is an argument that, given the idiosyncracies of the transport, dressing this up as a binding that is semantically equivalent to those defined in SAML2Bindings is something of a stretch and the Response therefore doesn't add anything, as you say. 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, 18 Feb 2010 14:32:29 -0500 From: Scott Cantor Message-Id: <200305122255.h4CMt1U02501@example.com> To: RANDOM_USER@example.com Organization: The Ohio State University MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit 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: 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 From: Scott Cantor Message-Id: <200305122255.h4CMt1U02501@example.com> To: RANDOM_USER@example.com Organization: The Ohio State University MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit 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 10:17:22 -0000 From: Mark O\'Leary Message-Id: <200305122255.h4CMt1U02501@example.com> To: RANDOM_USER@example.com Subject: Re: SAML RADIUS Binding Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable > EAP doesn't have any size constraints, but RADIUS (a common EAP > transport) does. A RADIUS message is (essentially arbitarily, AFAICT) > limited to 4kb. I think this dates back to the early days of dialup networking hardware, when 'large' memory buffers for assembling the packets weren't cheap. It underlines quite how old RADIUS is, and the compromises required to accommodate modern scenarios. DIAMETER really should have gained more traction, but we hold onto RADIUS like an arthritic, blind and incontinent family dog... Then again, DIAMETER really should have been a bit better at first release... M. 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, 18 Feb 2010 09:53:55 -0000 From: Josh Howlett Message-Id: <200305122255.h4CMt1U02501@example.com> To: RANDOM_USER@example.com Subject: Re: SAML RADIUS Binding Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable > So as I suspected, this is about message size? XML =3D=3D bad fit=20 > 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.=20 =20 > > We discussed various alternative strategies, including=20 > Diameter, XMPP=20 > > messaging, a lightweight XML schema over HTTP, or the use of WS-=20 > > Securitybinary tokens. Stefan is leaning towards XML over HTTP, but=20 > > XMPP looks more interesting to me. >=20=20 > It might be more interesting, but are there compelling=20 > functional advantages? I think these are the desirable technical properties & abstractions of the inter trust authority EAP transport protocol: - reliable transport. - mutual authentication of transport peers, ideally using GSS. - request / response message framing with multiple round-trips over a constant transport. - message types that can hold EAP packets, EAP keys & channel bindings and SAML request/response messages (by value). - message source/destination semantics. - message routing over multiple hops. - a conversation abtraction between peers seperated by multiple hops using multiple message round-trips - message and/or conversation and/or transport integrity & confidentiality. - message extensibility I believe that all of the strategies listed above have (or could be feasibility extended to have) these properties. I am presently leaning towards XMPP because (as I understand it) the base protocol (and perhaps also extensions like In-Band Bytestreams) gets us these properties without significant further profiling required (c.f. use of WS-Security & binary security tokens, where very significant profiling would be required). 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, 18 Feb 2010 00:01:18 -0500 From: Scott Cantor Message-Id: <200305122255.h4CMt1U02501@example.com> To: RANDOM_USER@example.com Subject: Re: SAML RADIUS Binding Content-Type: multipart/mixed; boundary="--16076f72871b14ef2a2f" This is a multi-part message in MIME format. ----16076f72871b14ef2a2f Content-Type: text/html; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable =26gt=3B Josh previously wrote=3A=3CBR=3E=26gt=3B =26gt=3B Bad news=2E A= s I suspected=2C it is a requirement that the=26nbsp=3Bcall-back used to= =3CBR=3E=26gt=3B =26gt=3B the resolve the artifact is authenticated at t= he transport layer=2E=3CBR=3E=26nbsp=3B=3CBR=3EWell=2C it doesn=27t have= to be the transport layer=2E=2E=2Eyou can sign the messages=2C for exam= ple=2E But the protocol as designed is for two SAML peers to interact an= d authenticate each other during the exchange so that the artifact is co= nsumed by the intended party and the message can be trusted=2E=3CBR=3E=3C= BR=3E=26gt=3B =26gt=3B Scott=27s advice was to avoid artifact resolution= =22at all=26nbsp=3Bcosts=22=2E=3CBR=3E=26nbsp=3B=3CBR=3ESpecifically=2C= if possible avoid passing messages by reference instead of value=2C or = if you must use references=2C start by figuring out your requirements an= d designing the exchange=2C and only at that point would I start worryin= g about whether it=27s the same or different from current artifacts=2E=3C= BR=3E=26nbsp=3B=3CBR=3E=26gt=3B =26gt=3B 1=2E Ignore the RADIUS spec=27s= MTU requirement=2E=2E=2E=3CBR=3E=26nbsp=3B=3CBR=3ESo as I suspected=2C = this is about message size=3F XML =3D=3D bad fit for size constrained=26= nbsp=3Bprotocols=2E=3CBR=3E=3CBR=3E=26gt=3B We discussed various alterna= tive strategies=2C including Diameter=2C XMPP=3CBR=3E=26gt=3B messaging=2C= a lightweight XML schema over HTTP=2C or the use of WS-=3CBR=3E=26gt=3B= Securitybinary tokens=2E Stefan is leaning towards XML over HTTP=2C =3C= BR=3E=26gt=3B but XMPP looks more interesting to me=2E=3CBR=3E=26nbsp=3B= =3CBR=3EIt might be more interesting=2C but are there compelling functio= nal advantages=3F=3CBR=3E=26nbsp=3B=3CBR=3E-- Scott=3CBR=3E=26nbsp=3B ----16076f72871b14ef2a2f-- 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, 17 Feb 2010 22:45:21 -0000 From: Josh Howlett Message-Id: <200305122255.h4CMt1U02501@example.com> To: RANDOM_USER@example.com Subject: Re: SAML RADIUS Binding Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Josh previously wrote: > Bad news. As I suspected, it is a requirement that the=20 > call-back used to > the resolve the artifact is authenticated at the transport layer. > Scott's advice was to avoid artifact resolution "at all costs". I see > two possible options: >=20 > 1. Ignore the RADIUS spec's MTU requirement... > > 2. TAS and TAC derive a new key for the artifact call-back from the > established AAA context... We discussed this issue at the Vienna meeting today. Stefan Winter was clear that he thought that using RADSEC was a bad idea, and that it would be cleaner to use another EAP lower layer for transporting EAP between trust authorities. He believes that attempting to manage the legacy RADIUS issues (primarily RADIUS MTU and attribute size limitations) would result in major headaches. We discussed various alternative strategies, including Diameter, XMPP messaging, a lightweight XML schema over HTTP, or the use of WS-Security binary tokens. Stefan is leaning towards XML over HTTP, but XMPP looks more interesting to me. Could we model this by using XMPP and the EAP GSS mechanism to establish the trust relationship between TAS and TAC, and within this XMPP session transport EAP messages (plus SAML messages, and derived EAP key and channel bindings) between C and TAC? Unfortunately I don't enough about XMPP to understand whether it would make a good EAP lower layer. I can't see why not in principle, but I suspect there are aesthetic issues at the very least. In addition, from an implementation perspective, ease of integration with FreeRADIUS is probably the most critical consideration (for access to the EAP machinery), but adding XMPP functionality to FreeRADIUS does not seem a natural extension. I don't believe we want to gateway between XMPP and RADIUS, as we introduce the issues of using RADIUS. 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: Sat, 13 Feb 2010 16:58:55 -0000 From: Josh Howlett Message-Id: <200305122255.h4CMt1U02501@example.com> To: RANDOM_USER@example.com Subject: Re: SAML RADIUS Binding Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Sam wrote: > > Ah! My terminology failure. Can we include a hash of the SAML=20 > > message in the artifact or along side the artifact to get=20 > authenticity=20 > > of the SAML message? Josh wrote: > Probably. I've discovered an issue in the specification which=20 > might prevent this (there is a requirement to "authenticate"=20 > the issuer, which to me implies a demonstration of authority=20 > to wield a name; whereas in this instance we only need to=20 > demonstrate authority to wield a SAML message). I've emailed=20 > the SSTC list for clarification. 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's advice was to avoid artifact resolution "at all costs". I see two possible options: 1. Ignore the RADIUS spec's MTU requirement, and use RadSec to transport the SAML message by value over TCP. The argument for doing this is that the RADIUS MTU makes sense for UDP, but not for TCP, and being dogmatic about the RADIUS spec is going to significantly increase complexity. There are sufficiently few RadSec implementations at the moment that we're realistically unlikely to cause any actual harm. Most importantly, it is also simple and robust. The argument for not doing this is that we're abusing the RADIUS spec. 2. TAS and TAC derive a new key for the artifact call-back from the established AAA context. TAS replicates a copy to S with the Access-Accept, together with the artifact. S uses the key and the artifact to resolve the SAML message. Any other ideas? 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: Fri, 12 Feb 2010 23:12:52 -0000 From: Josh Howlett Message-Id: <200305122255.h4CMt1U02501@example.com> To: RANDOM_USER@example.com Subject: Re: Actors Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable > There we're in complete agreement. However, I view the need=20 > to support this sort of trust path discovery as very much a=20 > next stage issue. The rest of the project seems squarely in=20 > the category of engineering work. Agreed. It would be nice to have a story for 3 to 5 years hence, but as you say it is important that we focus on engineering solutions to demonstrable problems of today. I will try to control my enthusiasm for fixing tomorrow's poorly-defined problems :-) 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: Fri, 12 Feb 2010 22:10:50 -0000 From: Josh Howlett Message-Id: <200305122255.h4CMt1U02501@example.com> To: RANDOM_USER@example.com Subject: Re: Actors Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable > I think we're on the same page regarding actors. I didn't=20 > see anything new in your definition of actors. That's good. What followed that is the brain dump, and so I'm not too surprised that you raise a number of issues with that. I understand, in particular, your skepticism concerning trust path discovery. I guess this boils down to personal opinion about the likely future scale of federated systems. You're probably right that we could live without trust path discovery purely within the European Higher Education community over the next 2 or 3 years. However - on the evidence of the adoption of federated identity within the HE community - I believe that we're in the early stages of exponential growth. While the absolute numbers are nowhere near Internet-scale at the moment, I believe that it's only a matter of time. It will escape the petri dishes of .gov, .edu, large .com, etc, and it I think it would be prudent to be prepared. 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: Fri, 12 Feb 2010 19:34:00 -0500 From: Sam Hartman Message-Id: <200305122255.h4CMt1U02501@example.com> To: RANDOM_USER@example.com Subject: Proposed bar BOF on federated authentication for non-web MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii 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: Fri, 12 Feb 2010 18:28:10 -0500 From: Sam Hartman Message-Id: <200305122255.h4CMt1U02501@example.com> To: RANDOM_USER@example.com Subject: Re: Actors MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii >>>>> "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 17:21:31 -0500 From: Sam Hartman Message-Id: <200305122255.h4CMt1U02501@example.com> To: RANDOM_USER@example.com Subject: Re: Actors MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii >>>>> "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: 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 From: Sam Hartman Message-Id: <200305122255.h4CMt1U02501@example.com> To: RANDOM_USER@example.com Subject: Re: Actors MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii 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: 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 From: Josh Howlett Message-Id: <200305122255.h4CMt1U02501@example.com> To: RANDOM_USER@example.com Subject: Re: SAML RADIUS Binding Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable > 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 From: Josh Howlett Message-Id: <200305122255.h4CMt1U02501@example.com> To: RANDOM_USER@example.com Subject: Actors (was RE: SAML RADIUS Binding) Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable > 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 From: Josh Howlett Message-Id: <200305122255.h4CMt1U02501@example.com> To: RANDOM_USER@example.com Subject: Re: SAML RADIUS Binding Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 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 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 08:44:45 -0500 From: Sam Hartman Message-Id: <200305122255.h4CMt1U02501@example.com> To: RANDOM_USER@example.com Subject: out until the call MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii I will be unavailable until our 1500 call. 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 08:44:23 -0500 From: Sam Hartman Message-Id: <200305122255.h4CMt1U02501@example.com> To: RANDOM_USER@example.com Subject: Re: SAML RADIUS Binding MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii >>>>> "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: 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 22:56:13 -0000 From: Josh Howlett Message-Id: <200305122255.h4CMt1U02501@example.com> To: RANDOM_USER@example.com Subject: Re: SAML RADIUS Binding Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Sam wrote: > >> 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. >=20 > 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=20 > be enforced > Josh> at any point along the trust graph so that if=20 > someone doesn't > Josh> want these entities talking, they can enforce that. >=20 > I thought you were proposing that TAS obtain a credential with TAC. That's where I started from. But I think that it is cleanest to fold TAS into S, and then use recursive discovery to walk the trust graph from the start. For example, if necessary S can walk to a local TA (for name authorisation) before exploring the trust graph outside of the local trust domain to find TAC. > What we need for artifact resolution is for S to obtain a=20 > credential with TAC. > So, S needs to be an X server, AAA client, artifact=20 > resolution client and key management client. Correct. I think the AAA client and SAML artifact resolver are implemented in the GSS library (and, of course, any downstream trust authorities that TAC walks to). I think the key management client is somehow invoked or implemented by the TA. We need to figure out an approach to the key management client that will cause minimum pain to application developers and deployers (think shared web hosting environments, etc). > 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? Yes, that would work fine. I think I still have a preference for the AAA approach for reasons pertaining to SAML aesthetics, but I'm struggling to articulate these, and your hashed-artifact approach is certainly cheaper. I'll sleep on it :-) Jumping back to where we started - the SAML RADIUS Binding - I think we can call the actual mechanism used to establish trust for artifact resolution out-of-scope for this spec. That's what the SAML specification does for the HTTP Artifact binding. We can then profile it in one of the higher-level specs. 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 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, 10 Feb 2010 21:36:57 -0000 From: Josh Howlett Message-Id: <200305122255.h4CMt1U02501@example.com> To: RANDOM_USER@example.com Subject: Re: SAML RADIUS Binding Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable > Josh> Given that we already have AAA credentials=20 > Josh> established, we can > Josh> derive a second credential which provides a PSK for TLS. >=20 > The acceptor has the credential shared with the TAS (trust=20 > authority near server for the archive). The artifact is=20 > being issued by the TAC (trust authority near client). > We could have the acceptor start conversing directly with TAC=20 > and use EAP-GSS to bootstrap a credential. Right. This is what I was proposing with "recursive discovery". TAS recurses through the trust graph until it finds TAC, and they converse directly. Policy can be enforced at any point along the trust graph so that if someone doesn't want these entities talking, they can enforce that. > However that means the server needs to act both as a server=20 > and a client. Do you mean a protocol X server and a AAA client? Wasn't that always the case? > That seems like a lot of complexity compared to transporting a hash. I was assuming that we would be doing this anyway, as a means to establish the AAA trust between TAC and TAS. If the credential for the artifact resolution falls out of that, then it looks really cheap. Perhaps we need to talk about the trust model again. Until we have a common view of that, I suspect we're going to have many other similar debates! =20 > Josh> How does the acceptor validate the responder's response? We > Josh> need mutual authentication, or another IdP could present an > Josh> arbitary response. >=20 > I'm not sure we need mutual authentication all the time. We=20 > need authentication from server to client. We only need=20 > authentication from client to server if we are concerned=20 > about some third party observing the artifact. I'm not concerned about the authenticity of the artifact; let us assume that we have satisfied that. I'm concerned about the authenticity of the SAML message that we obtain when we resolve the artifact. If the acceptor does not authenticate the IdP, it could be obtaining an assertion from an issuer who is not who they claim to be. > We could also just transport the hash or channel binding at=20 > the RADIUS level. True. 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: Wed, 10 Feb 2010 20:52:01 -0000 From: Josh Howlett Message-Id: <200305122255.h4CMt1U02501@example.com> To: RANDOM_USER@example.com Subject: Re: SAML RADIUS Binding MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Moving this to moonshot-community... On the possibility of expressing SAML assertion requirements to GSS-API, Sam wrote: > I think that required attributes could be a property of the=20 > acceptor name/credential for our mechanism. > I think we want to ask Nico about the general case though. >=20 > Josh> to require authorisation data through the GSS-API, I think > Josh> there are a couple of fall-back strategies: >=20 >=20 >=20 > Josh> 1. Express this in system configuration for the=20 > GSS mechanism > Josh> on a per-application basis (for initiator X and acceptor Y, > Josh> request attribute statement Z). >=20 > Well, the acceptor won't be in a position to make this depend=20 > on initiator because the acceptor needs to send the=20 > access-request Sorry, that was a dumb statement. I don't think this configuration requires a priori knowledge of the initiator's identity. > Josh> 2. Rely on the IdP to issue an unsolicited assertion. > I hope that we can use option 2 in a lot of cases. I expect we will. > >> I'm somewhat nervous about the artifact authentication. Are we > >> going to have credentials in common between the acceptor and > >> artifact issuer? I think the answer is no. >=20 > Josh> I hadn't thought of that wrinkle. However, I think=20 > we do have > Josh> common credentials. The artifact issuer is the SAML IdP that > Josh> the acceptor has a AAA relationship with.=20 >=20 > I thought the artifact issuer was the user's IDP, not the=20 > server's IDP. > How is the server's IDP in a position to know attributes=20 > about the user? I explained myself poorly. The user's IdP issues the artifact, and the server consumes it. The transfer of the artifact is performed over the SAML RADIUS binding, for which we already have an AAA trust established. Given that we already have AAA credentials established, we can derive a second credential which provides a PSK for TLS. > >> Does SAML allow us to include a hash of the response in the > >> artifact so we can avoid needing authentication at the artifact > >> resolution protocol level? >=20 > Josh> We could do that by defining a new artifact format, but we > Josh> lose TLS protection of the HTTP transport used to=20 > transfer the > Josh> resolved SAML message, unless we use anonymous DH. In that > Josh> case, we have to rely on the SAML signature to establish > Josh> trust. >=20 > I don't think that's true. First, if we have a hash of the=20 > artifact, I don't think we need TLS for anything except=20 > confidentiality. Just as with the metadata name, if we use=20 > the AAA infrastructure to tell us what artifact to expect, we=20 > don't need to trust the artifact transport. If for some=20 > reason we decide we want to trust TLS then instead/addition=20 > to transporting an artifact hash we could transport a TLS=20 > endpoint channel binding. How does the acceptor validate the responder's response? We need mutual authentication, or another IdP could present an arbitary response. Also, having consulted the spec, I was wrong about the possibility of defining a new artifact with these semantics. This would require a schema extension. This is a bit more invasive than I would like, but its not a deal breaker. josh.=20 JANET(UK) is a trading name of The JNT Association, a company limited by guarantee which is registered in England under No. 2881024=20 and whose Registered Office is at Lumen House, Library Avenue, Harwell Science and Innovation Campus, Didcot, Oxfordshire. OX11 0SG 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, 10 Feb 2010 18:16:55 -0500 From: Sam Hartman Message-Id: <200305122255.h4CMt1U02501@example.com> To: RANDOM_USER@example.com Subject: Re: SAML RADIUS Binding MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii >>>>> "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: 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 From: Sam Hartman Message-Id: <200305122255.h4CMt1U02501@example.com> To: RANDOM_USER@example.com Subject: Re: SAML RADIUS Binding MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii >>>>> "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: 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:11:59 -0500 From: Sam Hartman Message-Id: <200305122255.h4CMt1U02501@example.com> To: RANDOM_USER@example.com Subject: Re: SAML RADIUS Binding 10 Feb 2010 20:52:01 -0000") MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii >>>>> "Josh" == Josh Howlett writes: Josh> I explained myself poorly. The user's IdP issues the artifact, Josh> and the server consumes it. The transfer of the artifact is Josh> performed over the SAML RADIUS binding, for which we already Josh> have an AAA trust established. 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. However that means the server needs to act both as a server and a client. That seems like a lot of complexity compared to transporting a hash. >> >> Does SAML allow us to include a hash of the response in the >> >> artifact so we can avoid needing authentication at the artifact >> >> resolution protocol level? >> Josh> We could do that by defining a new artifact format, but we Josh> lose TLS protection of the HTTP transport used to >> transfer the Josh> resolved SAML message, unless we use anonymous DH. In that Josh> case, we have to rely on the SAML signature to establish Josh> trust. >> >> I don't think that's true. First, if we have a hash of the >> artifact, I don't think we need TLS for anything except >> confidentiality. Just as with the metadata name, if we use the >> AAA infrastructure to tell us what artifact to expect, we don't >> need to trust the artifact transport. If for some reason we >> decide we want to trust TLS then instead/addition to transporting >> an artifact hash we could transport a TLS endpoint channel >> binding. Josh> How does the acceptor validate the responder's response? We Josh> need mutual authentication, or another IdP could present an Josh> arbitary response. I'm not sure we need mutual authentication all the time. We need authentication from server to client. We only need authentication from client to server if we are concerned about some third party observing the artifact. So, how do we confirm that the artifact is genuine? We accept any artifact whose contents hashes to the hash value we have. We know that the hash is protected because we received it over the AAA channel and that's integrity-protected. The definition of a cryptographic hash function implies that no party can easily generate a second artifact with the same hash as the one we received over the integrity protected channel: that directly follows from second preimage resistance. Now, authenticating the client to the server is a non-trivial concern as well. There are cases--the data protection laws are such a case--where we want to avoid disclosing an artifact to the wrong party. If the artifact name is long enough then an attacker should not be able to guess it. Josh> Also, having consulted the spec, I was wrong about the Josh> possibility of defining a new artifact with these Josh> semantics. This would require a schema extension. This is a Josh> bit more invasive than I would like, but its not a deal Josh> breaker. We could also just transport the hash or channel binding at the RADIUS level. 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, 10 Feb 2010 13:58:05 -0500 From: Sam Hartman Message-Id: <200305122255.h4CMt1U02501@example.com> To: RANDOM_USER@example.com Subject: GSS and SAML attribute requests Content-Type: text/plain; charset=us-ascii Josh and I are looking at how to express the set of attributes an acceptor is interested in in GSS-API. In particular, we want a way to inform the GSS mechanism what attributes that the acceptor should request from the IDP. In our mechanism, the acceptor is in a position to interact with the IDP. (In our mechanism, the client actually turns out not to be in a position to interact with the IDP about attribute release.) Options I've thought of: 1) Use name attributes on the name that the acceptor passes into gss_acquire_cred. 2) Some other mechanism-specific or generic extension to the credentials. Do you have any thoughts on the best way to approach this? P.S. You may want to join the moonshot-community lis; I will be announcing it to kitten and ietf@ietf.org among other places soon. Return-Path: Received: (from root@localhost) by example.com (8.11.6/8.11.6/SuSE Linux 0.5) id h4CMt1U02501 for root; Mon, 12 May 2003 17:55:01 -0500 Date: Thu, 4 Feb 2010 16:04:17 -0000 From: Josh Howlett Message-Id: <200305122255.h4CMt1U02501@example.com> To: RANDOM_USER@example.com Subject: I forgot to mention... Content-Transfer-Encoding: quoted-printable The web interface for subscribing to this list is at: https://www.jiscmail.ac.uk/cgi-bin/webadmin?A0=3Dmoonshot-community To subscribe via email, send a message to listserv@jiscmail.ac.uk with the word subscribe in the body. 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, 4 Feb 2010 16:01:41 -0000 From: Josh Howlett Message-Id: <200305122255.h4CMt1U02501@example.com> To: RANDOM_USER@example.com Subject: Moonshot-community mailing list Content-Transfer-Encoding: quoted-printable Dear all, Sam suggested that we set up a list to support community discussion of Moonshot. That is the purpose of this list. JANET(UK) related project email should go to moonshot@jiscmail.ac.uk. The initial subscribers are: Josh Howlett, JANET(UK) Henry Hughes, JANET(UK) Louis Seachwell, JANET(UK) Mark O'Leary, JANET(UK) Mark Tysom, JANET(UK) Sam Hartman, Painless Security LLC=20 The mailing list archive is public and subscription is open. 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 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 11:17:02 -0500 Comments: To: nicolas.williams@sun.com Message-Id: <200305122255.h4CMt1U02501@example.com> To: abfab@ietf.org MIME-Version: 1.0 nico, I'm writing up the 00 draft of the moonshot mechanism based on a draft I received from Josh. Like Kerberos, moonshot needs to solve the host-to-realm mapping problem. It manifests differently though. There is likely to be a server AAA proxy near the server. That proxy is responsible for deciding whether the authentication request comes from the indicated host. The request eventually gets to an EAP server. The EAP server probably only has the identity of the visited realm of the server proxy [1]. So it must decide whether that visited realm is a reasonable realm to claim the hostname that the acceptor claims. In some ways that's easier than Kerberos. We probably also want a name form that includes a host, service and realm. Syntactically that's the same as a domain-based name. It's my opinion though that semantically it's not a domain-based name and thus we should not use that name type. Do you agree? [1] It's possible the EAP server may not know the visited realm. We can't actually make that case wrok from a security standpoint so we'll have to require the EAP server to know the visited realm. --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 19:05:32 -0500 Comments: cc: Thomas Hardjono Message-Id: <200305122255.h4CMt1U02501@example.com> To: abfab@ietf.org MIME-Version: 1.0 Sam, I plan to attend both. So it would be good to have them on separate times/days. cheers, /thomas/ > -----Original Message----- > From: Moonshot community list [mailto:MOONSHOT-COMMUNITY@JISCMAIL.AC.UK] On > Behalf Of Sam Hartman > Sent: Thursday, February 25, 2010 2:27 PM > To: MOONSHOT-COMMUNITY@JISCMAIL.AC.UK > Subject: Federated authentication bar bof probably Thursday evening > > 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: Mon, 22 Feb 2010 08:21:44 -0700 Comments: cc: Josh Howlett Message-Id: <200305122255.h4CMt1U02501@example.com> To: abfab@ietf.org MIME-Version: 1.0 This is a cryptographically signed message in MIME format. --------------ms040603030409010605010303 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 2/18/10 2:53 AM, Josh Howlett wrote: >> So as I suspected, this is about message size? XML =3D=3D bad fit=20 >> for size constrained protocols. >=20 > 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.=20 > =20 >>> We discussed various alternative strategies, including=20 >> Diameter, XMPP=20 >>> messaging, a lightweight XML schema over HTTP, or the use of WS-=20 >>> Securitybinary tokens. Stefan is leaning towards XML over HTTP, but=20 >>> XMPP looks more interesting to me. >> =20 >> It might be more interesting, but are there compelling=20 >> functional advantages? >=20 > I think these are the desirable technical properties & abstractions of > the inter trust authority EAP transport protocol: >=20 > - reliable transport. > - mutual authentication of transport peers, ideally using GSS. > - request / response message framing with multiple round-trips over a > constant transport. > - message types that can hold EAP packets, EAP keys & channel bindings > and SAML request/response messages (by value). > - message source/destination semantics. > - message routing over multiple hops. > - a conversation abtraction between peers seperated by multiple hops > using multiple message round-trips > - message and/or conversation and/or transport integrity & > confidentiality. > - message extensibility >=20 > I believe that all of the strategies listed above have (or could be > feasibility extended to have) these properties. >=20 > I am presently leaning towards XMPP because (as I understand it) the > base protocol (and perhaps also extensions like In-Band Bytestreams) > gets us these properties without significant further profiling required= > (c.f. use of WS-Security & binary security tokens, where very > significant profiling would be required). Hi Josh, You do have some XMPP experts on this list. :) Although naturally I am partial to XMPP, it's not always the best tool for the job. Here I think that it meets most or all of your needs, but to know for sure I'd need to know a bit more about what you mean in this context by "reliable transport", "framing", "multiple hops", "integrity", and "confidentiality". I'd be happy to have a chat with you and anyone else who's interested so that we can figure out what your requirements are and whether XMPP meets those requirements (or can be extended to do so). Perhaps we can set up a conference call in the near future? Peter --=20 Peter Saint-Andre https://stpeter.im/ --------------ms040603030409010605010303 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIWnDCC B1cwggY/oAMCAQICAVUwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQK Ew1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBT aWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRl IENsaWVudCBDQTAeFw0wOTA3MDYwMDAwMDFaFw0xMDA3MDYyMzU5NTlaMIHCMQswCQYDVQQG EwJVUzERMA8GA1UECBMIQ29sb3JhZG8xDzANBgNVBAcTBkRlbnZlcjEiMCAGA1UEChMZWE1Q UCBTdGFuZGFyZHMgRm91bmRhdGlvbjEsMCoGA1UECxMjU3RhcnRDb20gVHJ1c3RlZCBDZXJ0 aWZpY2F0ZSBNZW1iZXIxGjAYBgNVBAMTEVBldGVyIFNhaW50LUFuZHJlMSEwHwYJKoZIhvcN AQkBFhJzdHBldGVyQHN0cGV0ZXIuaW0wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCas7Mrnh02GakN8sft+HJpU4MwBxEgrGDZ2ZzUxDDt2sEhM+9Q74h955MtgMhK3TeBf6Hs hDh/8Z9G//k2qNA0M2S5rejTqrmW0Jabca/L7BUZ0GhnU2N/2zeciFUmuZ4A2l1T5IMX2ZVP XnNIaefBtbImJAbDz3T0vxkzTtcqgW3wL83PMDiqiuM+e1k+VPvOW4f5ZSGkPIhYCDpWqNE5 wZvjrLNMc8jZOPs9DrsYuIVwU72Vhy1tkEh+w6YpYHrdEUAe+eKe6TuxqZ60e9z3O36uiV// Ms274iD6PbA/IGazJgaAdg6tvPehwTYGJAGmv3PsJKkLGjgoh+RrrM1LAgMBAAGjggOKMIID hjAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUH AwQwHQYDVR0OBBYEFOyws3XWgIY9FP1POVqjdZP9Lu38MB0GA1UdEQQWMBSBEnN0cGV0ZXJA c3RwZXRlci5pbTCBqAYDVR0jBIGgMIGdgBR7iZySlyShhEcCy3T8LvSs3DLl86GBgaR/MH0x CzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUg RGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQDEyBTdGFydENvbSBDZXJ0aWZp Y2F0aW9uIEF1dGhvcml0eYIBDzCCAUcGA1UdIASCAT4wggE6MIIBNgYLKwYBBAGBtTcBAgAw ggElMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMDQG CCsGAQUFBwIBFihodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUucGRmMIG8 BggrBgEFBQcCAjCBrzAUFg1TdGFydENvbSBMdGQuMAMCAQEagZZMaW1pdGVkIExpYWJpbGl0 eSwgcmVhZCB0aGUgc2VjdGlvbiAqTGVnYWwgTGltaXRhdGlvbnMqIG9mIHRoZSBTdGFydENv bSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSBQb2xpY3kgYXZhaWxhYmxlIGF0IGh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwYwYDVR0fBFwwWjAroCmgJ4YlaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vY3J0dTMtY3JsLmNybDAroCmgJ4YlaHR0cDovL2NybC5zdGFydHNz bC5jb20vY3J0dTMtY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5BggrBgEFBQcwAYYtaHR0 cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFzczMvY2xpZW50L2NhMEIGCCsGAQUFBzAC hjZodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9jZXJ0cy9zdWIuY2xhc3MzLmNsaWVudC5jYS5j cnQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0GCSqGSIb3DQEBBQUA A4IBAQBgv4xFXZqDKSOtnPOVbqOh1brj7oxRaVYk7N0MJG7x9Y/wkO3iwRwizVLcC1bA+D/R gyFilXx6IQWE63Ge2tu+Y4w5QoHYwuUFQuBZuxvZpOa3ykdgPlBQaBM8m+Ien0skwNggaizA X9Pc/sMLpP3jkO1iSF4agy4r5Ed+4G10mP5X0zO3gQwq9Uj4F9tX+58kU+fM1P8Sh+BYR4r/ kSbKE3tWcMaKblWPGwX0nYD26Je7Qb+uX/J5lCgozBrHXQWq8N98iklASf2pv+32Oi1dEjmM UgAm/J2+YmxaI02+c+H6QH8+F3RUjCiRg9XqUNjcrNrnTFnm/iMMZADktsXPMIIHVzCCBj+g AwIBAgIBVTANBgkqhkiG9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcx ODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50 IENBMB4XDTA5MDcwNjAwMDAwMVoXDTEwMDcwNjIzNTk1OVowgcIxCzAJBgNVBAYTAlVTMREw DwYDVQQIEwhDb2xvcmFkbzEPMA0GA1UEBxMGRGVudmVyMSIwIAYDVQQKExlYTVBQIFN0YW5k YXJkcyBGb3VuZGF0aW9uMSwwKgYDVQQLEyNTdGFydENvbSBUcnVzdGVkIENlcnRpZmljYXRl IE1lbWJlcjEaMBgGA1UEAxMRUGV0ZXIgU2FpbnQtQW5kcmUxITAfBgkqhkiG9w0BCQEWEnN0 cGV0ZXJAc3RwZXRlci5pbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAJqzsyue HTYZqQ3yx+34cmlTgzAHESCsYNnZnNTEMO3awSEz71DviH3nky2AyErdN4F/oeyEOH/xn0b/ +Tao0DQzZLmt6NOquZbQlptxr8vsFRnQaGdTY3/bN5yIVSa5ngDaXVPkgxfZlU9ec0hp58G1 siYkBsPPdPS/GTNO1yqBbfAvzc8wOKqK4z57WT5U+85bh/llIaQ8iFgIOlao0TnBm+Oss0xz yNk4+z0Ouxi4hXBTvZWHLW2QSH7Dpilget0RQB754p7pO7GpnrR73Pc7fq6JX/8yzbviIPo9 sD8gZrMmBoB2Dq2896HBNgYkAaa/c+wkqQsaOCiH5GuszUsCAwEAAaOCA4owggOGMAkGA1Ud EwQCMAAwCwYDVR0PBAQDAgSwMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAdBgNV HQ4EFgQU7LCzddaAhj0U/U85WqN1k/0u7fwwHQYDVR0RBBYwFIESc3RwZXRlckBzdHBldGVy LmltMIGoBgNVHSMEgaAwgZ2AFHuJnJKXJKGERwLLdPwu9KzcMuXzoYGBpH8wfTELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs IENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5ggEPMIIBRwYDVR0gBIIBPjCCATowggE2BgsrBgEEAYG1NwECADCCASUwLgYI KwYBBQUHAgEWImh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUH AgEWKGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwgbwGCCsGAQUF BwICMIGvMBQWDVN0YXJ0Q29tIEx0ZC4wAwIBARqBlkxpbWl0ZWQgTGlhYmlsaXR5LCByZWFk IHRoZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRp ZmljYXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL3d3dy5zdGFy dHNzbC5jb20vcG9saWN5LnBkZjBjBgNVHR8EXDBaMCugKaAnhiVodHRwOi8vd3d3LnN0YXJ0 c3NsLmNvbS9jcnR1My1jcmwuY3JsMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9j cnR1My1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2Nz cC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMy9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczMuY2xpZW50LmNhLmNydDAjBgNV HRIEHDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBAGC/ jEVdmoMpI62c85Vuo6HVuuPujFFpViTs3QwkbvH1j/CQ7eLBHCLNUtwLVsD4P9GDIWKVfHoh BYTrcZ7a275jjDlCgdjC5QVC4Fm7G9mk5rfKR2A+UFBoEzyb4h6fSyTA2CBqLMBf09z+wwuk /eOQ7WJIXhqDLivkR37gbXSY/lfTM7eBDCr1SPgX21f7nyRT58zU/xKH4FhHiv+RJsoTe1Zw xopuVY8bBfSdgPbol7tBv65f8nmUKCjMGsddBarw33yKSUBJ/am/7fY6LV0SOYxSACb8nb5i bFojTb5z4fpAfz4XdFSMKJGD1epQ2Nys2udMWeb+IwxkAOS2xc8wggfiMIIFyqADAgECAgEP MA0GCSqGSIb3DQEBBQUAMH0xCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQu MSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQD EyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0wNzEwMjQyMTAzMzJaFw0x MjEwMjIyMTAzMzJaMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEr MCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMv U3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwggEiMA0G CSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC5o0luEj4gypQIp71Xi2TlXyLYrj9WkRy+d9BO 0FHPYnAsC99/jx/ibNRwIfAoFhZd+LDscdRSckvwuFSz0bKg3z+9o7cwlVAC9AwMWe8IM0Lx c+8etYxsX4WIamG9fjzzi5GAW5ESKzzIN3SxHSplyGCWFwx/pgf1f4y6O9/ym+4f6zaDYP6B x0r+SaJcr6eSGNm7X3EwX1v7XpRBY+aw019o7k72d0IX910F+XGt0OwNdM61Ff3FiTiexeUZ bWxCGm6GZl+SQVG9xYVIgHQaLXoQF+g2wzrmKCbVcZhqH+hrlRnD6PfCuEyX/BR6PlAPRDlQ 6f1u3wqik+LF5P15AgMBAAGjggNbMIIDVzAMBgNVHRMEBTADAQH/MAsGA1UdDwQEAwIBpjAd BgNVHQ4EFgQUe4mckpckoYRHAst0/C70rNwy5fMwgagGA1UdIwSBoDCBnYAUTgvvGqRAW6UX aYcwyjRoQ9BBrvKhgYGkfzB9MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzEpMCcGA1UE AxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHmCAQEwCQYDVR0SBAIwADA9Bggr BgEFBQcBAQQxMC8wLQYIKwYBBQUHMAKGIWh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2Nh LmNydDBgBgNVHR8EWTBXMCygKqAohiZodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvc2ZzY2Et Y3JsLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20vc2ZzY2EuY3JsMIIBXQYD VR0gBIIBVDCCAVAwggFMBgsrBgEEAYG1NwEBBDCCATswLwYIKwYBBQUHAgEWI2h0dHA6Ly9j ZXJ0LnN0YXJ0Y29tLm9yZy9wb2xpY3kucGRmMDUGCCsGAQUFBwIBFilodHRwOi8vY2VydC5z dGFydGNvbS5vcmcvaW50ZXJtZWRpYXRlLnBkZjCB0AYIKwYBBQUHAgIwgcMwJxYgU3RhcnQg Q29tbWVyY2lhbCAoU3RhcnRDb20pIEx0ZC4wAwIBARqBl0xpbWl0ZWQgTGlhYmlsaXR5LCBy ZWFkIHRoZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENl cnRpZmljYXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL2NlcnQu c3RhcnRjb20ub3JnL3BvbGljeS5wZGYwEQYJYIZIAYb4QgEBBAQDAgAHMFAGCWCGSAGG+EIB DQRDFkFTdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIEZyZWUgU1NMIEVt YWlsIENlcnRpZmljYXRlczANBgkqhkiG9w0BAQUFAAOCAgEAUpcEDdsKFRCxFBxcSm+8oMTT fpS7fbZkxWHx5fHDjvAgaBQ+oY0tk4xtbD6VxeHYjxI63+hj8jICnqeVXPe34Bu+XzekIn2T lrnPCQobKdQF2p52QgUvIxSURed0jcBaCBV22DSKaUqDOzD/Tx6VQy78zpblXjRH7OALE/+H jzJVmspdnBUUtQOLYgPo924xkxR25VDdgtEE5vAXa/g2oCeZhy0ZEO4NbgIayAYCJcJRDz0h dD2Ahec65Kw6LB3N7VXEjiRR5/WoKwH/QteRzPJbFDc1somrApjm2cyg+5nbm1RHeFIz+GxX luRrPztvhNcby0PtAjqwY1txi4sW0R6ZJPuZ2DZ1/dzckoFhyZgFyOX3SEkNXVLldjTzneFJ FnVSzDbc720vq184jR7pYoI9+f5QJ96a0iLxEAG8SJ5auBwXI/w2FmKmwmdMvJ8/17+B4sMC IRrXrDQl2xzpVXh/Qcmk5nf+w8HFmqATGy1OUAQbXga7AySAUaYhvvFk50u0bO5DiUGwzrJO 3TrwvaC2Ei4EFaBmIVgG7TfU5TaaY9IcJSCQ7AGUYE3RFSRpsLOoA3DsxP42YERgS/Nxw29+ YqZtPoO2QPbNpI7xnHVCfNBabx3oDIf438nFfv8spw5BQqBSbEF1izJA57eE64CzHnt7lB20 OFD11avYopwxggPKMIIDxgIBATCBkjCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcx ODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50 IENBAgFVMAkGBSsOAwIaBQCgggIMMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZI hvcNAQkFMQ8XDTEwMDIyMjE1MjE0NFowIwYJKoZIhvcNAQkEMRYEFHPj9h24OVqhhSgnCFio F9o9PN6qMF8GCSqGSIb3DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBowYJ KwYBBAGCNxAEMYGVMIGSMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UE AxMvU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAVUw gaUGCyqGSIb3DQEJEAILMYGVoIGSMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4 MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQg Q0ECAVUwDQYJKoZIhvcNAQEBBQAEggEAh6Jt8hQ2KJz2yNrHbSF0tIi/NjzetZXOaYjlceFe UPfxO/4F98Rm5NxOisFt8FQ9oOvHjXGlpcWisyD+dUThdZSMm4bx68Bu6j5Lvr6X/7AJ3pOO swa/m4qTVe6WiJqmJgAy8l4qRXzVCAhpsPPhXa2i4CTqiXUeGMXDwf9NlfzlPjqo8fIHSeqt Gsq0P/ibt2bpONwc3B+XzDVEimwD5SrwZb7zgChZY7rUhHJEMu2RB4yC/0iUJWd8+lVP+fDA 4UwY9jcPVz501KxAH1XylRqAysCON4LXvI9u3JeLpzyUFWVJhoWNXZIvi45xxzmEqCkyQ4G8 m5httWYkEXxH+gAAAAAAAA== --------------ms040603030409010605010303-- 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, 10 Feb 2010 20:52:01 -0000 Comments: To: Sam Hartman Message-Id: <200305122255.h4CMt1U02501@example.com> To: abfab@ietf.org MIME-Version: 1.0 Moving this to moonshot-community... On the possibility of expressing SAML assertion requirements to GSS-API, Sam wrote: > I think that required attributes could be a property of the=20 > acceptor name/credential for our mechanism. > I think we want to ask Nico about the general case though. >=20 > Josh> to require authorisation data through the GSS-API, I think > Josh> there are a couple of fall-back strategies: >=20 >=20 >=20 > Josh> 1. Express this in system configuration for the=20 > GSS mechanism > Josh> on a per-application basis (for initiator X and acceptor Y, > Josh> request attribute statement Z). >=20 > Well, the acceptor won't be in a position to make this depend=20 > on initiator because the acceptor needs to send the=20 > access-request Sorry, that was a dumb statement. I don't think this configuration requires a priori knowledge of the initiator's identity. > Josh> 2. Rely on the IdP to issue an unsolicited assertion. > I hope that we can use option 2 in a lot of cases. I expect we will. > >> I'm somewhat nervous about the artifact authentication. Are we > >> going to have credentials in common between the acceptor and > >> artifact issuer? I think the answer is no. >=20 > Josh> I hadn't thought of that wrinkle. However, I think=20 > we do have > Josh> common credentials. The artifact issuer is the SAML IdP that > Josh> the acceptor has a AAA relationship with.=20 >=20 > I thought the artifact issuer was the user's IDP, not the=20 > server's IDP. > How is the server's IDP in a position to know attributes=20 > about the user? I explained myself poorly. The user's IdP issues the artifact, and the server consumes it. The transfer of the artifact is performed over the SAML RADIUS binding, for which we already have an AAA trust established. Given that we already have AAA credentials established, we can derive a second credential which provides a PSK for TLS. > >> Does SAML allow us to include a hash of the response in the > >> artifact so we can avoid needing authentication at the artifact > >> resolution protocol level? >=20 > Josh> We could do that by defining a new artifact format, but we > Josh> lose TLS protection of the HTTP transport used to=20 > transfer the > Josh> resolved SAML message, unless we use anonymous DH. In that > Josh> case, we have to rely on the SAML signature to establish > Josh> trust. >=20 > I don't think that's true. First, if we have a hash of the=20 > artifact, I don't think we need TLS for anything except=20 > confidentiality. Just as with the metadata name, if we use=20 > the AAA infrastructure to tell us what artifact to expect, we=20 > don't need to trust the artifact transport. If for some=20 > reason we decide we want to trust TLS then instead/addition=20 > to transporting an artifact hash we could transport a TLS=20 > endpoint channel binding. How does the acceptor validate the responder's response? We need mutual authentication, or another IdP could present an arbitary response. Also, having consulted the spec, I was wrong about the possibility of defining a new artifact with these semantics. This would require a schema extension. This is a bit more invasive than I would like, but its not a deal breaker. josh.=20 JANET(UK) is a trading name of The JNT Association, a company limited by guarantee which is registered in England under No. 2881024=20 and whose Registered Office is at Lumen House, Library Avenue, Harwell Science and Innovation Campus, Didcot, Oxfordshire. OX11 0SG 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, 10 Feb 2010 16:11:59 -0500 Comments: To: Josh Howlett Message-Id: <200305122255.h4CMt1U02501@example.com> To: abfab@ietf.org 10 Feb 2010 20:52:01 -0000") >>>>> "Josh" == Josh Howlett writes: Josh> I explained myself poorly. The user's IdP issues the artifact, Josh> and the server consumes it. The transfer of the artifact is Josh> performed over the SAML RADIUS binding, for which we already Josh> have an AAA trust established. 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. However that means the server needs to act both as a server and a client. That seems like a lot of complexity compared to transporting a hash. >> >> Does SAML allow us to include a hash of the response in the >> >> artifact so we can avoid needing authentication at the artifact >> >> resolution protocol level? >> Josh> We could do that by defining a new artifact format, but we Josh> lose TLS protection of the HTTP transport used to >> transfer the Josh> resolved SAML message, unless we use anonymous DH. In that Josh> case, we have to rely on the SAML signature to establish Josh> trust. >> >> I don't think that's true. First, if we have a hash of the >> artifact, I don't think we need TLS for anything except >> confidentiality. Just as with the metadata name, if we use the >> AAA infrastructure to tell us what artifact to expect, we don't >> need to trust the artifact transport. If for some reason we >> decide we want to trust TLS then instead/addition to transporting >> an artifact hash we could transport a TLS endpoint channel >> binding. Josh> How does the acceptor validate the responder's response? We Josh> need mutual authentication, or another IdP could present an Josh> arbitary response. I'm not sure we need mutual authentication all the time. We need authentication from server to client. We only need authentication from client to server if we are concerned about some third party observing the artifact. So, how do we confirm that the artifact is genuine? We accept any artifact whose contents hashes to the hash value we have. We know that the hash is protected because we received it over the AAA channel and that's integrity-protected. The definition of a cryptographic hash function implies that no party can easily generate a second artifact with the same hash as the one we received over the integrity protected channel: that directly follows from second preimage resistance. Now, authenticating the client to the server is a non-trivial concern as well. There are cases--the data protection laws are such a case--where we want to avoid disclosing an artifact to the wrong party. If the artifact name is long enough then an attacker should not be able to guess it. Josh> Also, having consulted the spec, I was wrong about the Josh> possibility of defining a new artifact with these Josh> semantics. This would require a schema extension. This is a Josh> bit more invasive than I would like, but its not a deal Josh> breaker. We could also just transport the hash or channel binding at the RADIUS level. 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, 10 Feb 2010 13:58:05 -0500 Comments: To: nicolas.williams@sun.com Message-Id: <200305122255.h4CMt1U02501@example.com> To: abfab@ietf.org MIME-Version: 1.0 Josh and I are looking at how to express the set of attributes an acceptor is interested in in GSS-API. In particular, we want a way to inform the GSS mechanism what attributes that the acceptor should request from the IDP. In our mechanism, the acceptor is in a position to interact with the IDP. (In our mechanism, the client actually turns out not to be in a position to interact with the IDP about attribute release.) Options I've thought of: 1) Use name attributes on the name that the acceptor passes into gss_acquire_cred. 2) Some other mechanism-specific or generic extension to the credentials. Do you have any thoughts on the best way to approach this? P.S. You may want to join the moonshot-community lis; I will be announcing it to kitten and ietf@ietf.org among other places soon. Return-Path: Received: (from root@localhost) by example.com (8.11.6/8.11.6/SuSE Linux 0.5) id h4CMt1U02501 for root; Mon, 12 May 2003 17:55:01 -0500 Date: Thu, 4 Feb 2010 16:04:17 -0000 MIME-Version: 1.0 Message-Id: <200305122255.h4CMt1U02501@example.com> To: abfab@ietf.org Content-Type: text/plain; charset="us-ascii" The web interface for subscribing to this list is at: https://www.jiscmail.ac.uk/cgi-bin/webadmin?A0=3Dmoonshot-community To subscribe via email, send a message to listserv@jiscmail.ac.uk with the word subscribe in the body. 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, 4 Feb 2010 16:01:41 -0000 MIME-Version: 1.0 Message-Id: <200305122255.h4CMt1U02501@example.com> To: abfab@ietf.org Content-Type: text/plain; charset="us-ascii" Dear all, Sam suggested that we set up a list to support community discussion of Moonshot. That is the purpose of this list. JANET(UK) related project email should go to moonshot@jiscmail.ac.uk. The initial subscribers are: Josh Howlett, JANET(UK) Henry Hughes, JANET(UK) Louis Seachwell, JANET(UK) Mark O'Leary, JANET(UK) Mark Tysom, JANET(UK) Sam Hartman, Painless Security LLC=20 The mailing list archive is public and subscription is open. 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 Return-Path: Received: (from root@localhost) by example.com (8.11.6/8.11.6/SuSE Linux 0.5) id h4CMt1U02501 for root; Mon, 12 May 2003 17:55:01 -0500 Date: Thu, 4 Feb 2010 15:48:19 -0000 MIME-Version: 1.0 Message-Id: <200305122255.h4CMt1U02501@example.com> To: abfab@ietf.org Content-Type: text/plain; charset="us-ascii" Test JANET(UK) is a trading name of The JNT Association, a company limited by guarantee which is registered in England under No. 2881024=20 and whose Registered Office is at Lumen House, Library Avenue, Harwell Science and Innovation Campus, Didcot, Oxfordshire. OX11 0SG