To: [email-masked]
Date: Thu, 18 Feb 2010 19:06:05 -0000

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

Date: Thu, 18 Feb 2010 10:17:22 -0000
To: [email-masked]
> 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

Date: Thu, 18 Feb 2010 09:53:55 -0000
To: [email-masked]
> 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

Date: Thu, 18 Feb 2010 00:01:18 -0500
To: [email-masked]

----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--