Allen,
Sending the artifact unencrypted in the indirect request and response
allows an eavesdropper to intercept it in both directions.
If the artifact is not encrypted in the indirect channel then the OP
must validate the direct request somehow.
The options for that are:
1. Mutual TLS
2. Direct request signed by the private key of the RP, the cert needs
to be sent so the return_to can be validated. This would also use
normal TLS.
3. Encrypt the entire response in the direct channel with the public
key from RP discovery
4. The RP must sign the request with the shared association secret.
The same association handle needs to be used for direct and indirect
communications.
I need to think about 4 a bit but it may work.
John B.
On 20-Aug-09, at 1:18 PM, [email protected] wrote:
Date: Thu, 20 Aug 2009 11:16:23 -0700
From: Allen Tom <[email protected]>
Subject: Re: Artifact Binding Re: specs Digest, Vol 36, Issue 1
To: "[email protected]" <[email protected]>
Message-ID: <[email protected]>
Content-Type: text/plain; charset="windows-1252"; Format="flowed"
In the interest of improving security, would it make sense to require
the RP to sign the request when exchanging the Artifact for the
response? If the request was signed, then even if the artifact was
easedropped, possession of the artifact by itself does not allow the
attacker to get the data.
Given that many RPs don't use HTTPS, it's very likely that Artifacts
will be passed around in the clear. Although requiring the RP to sign
the request when exchanging the artifact for the assertion would
increase the complexity, it might be worth it.
Allen
_______________________________________________
specs mailing list
[email protected]
http://lists.openid.net/mailman/listinfo/openid-specs
