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 MIME-Version: 1.0 Message-Id: <200305122255.h4CMt1U02501@example.com> To: abfab@ietf.org Content-Type: text/plain; charset="us-ascii" 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 MIME-Version: 1.0 Message-Id: <200305122255.h4CMt1U02501@example.com> To: abfab@ietf.org Content-Type: text/plain; charset="us-ascii" > 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