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 MIME-Version: 1.0 Message-Id: <200305122255.h4CMt1U02501@example.com> To: abfab@ietf.org Content-Type: text/plain; charset="us-ascii" 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 10:17:22 -0000 MIME-Version: 1.0 Message-Id: <200305122255.h4CMt1U02501@example.com> To: abfab@ietf.org Content-Type: text/plain; charset="us-ascii" > 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 MIME-Version: 1.0 Message-Id: <200305122255.h4CMt1U02501@example.com> To: abfab@ietf.org Content-Type: text/plain; charset="us-ascii" > 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 MIME-Version: 1.0 Message-Id: <200305122255.h4CMt1U02501@example.com> To: abfab@ietf.org Content-Type: multipart/mixed; boundary="--16076f72871b14ef2a2f" ----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--