To: [email-masked]
Date: Wed, 10 Feb 2010 22:56:13 -0000

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

Date: Wed, 10 Feb 2010 21:36:57 -0000
To: [email-masked]
> 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