Artifact Binding Re: specs Digest, Vol 36, Issue 1

[John Bradley]

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, openid-specs-request at lists.openid.net wrote:

> Date: Thu, 20 Aug 2009 11:16:23 -0700
> From: Allen Tom <atom at yahoo-inc.com>
> Subject: Re: Artifact Binding Re: specs Digest, Vol 36, Issue 1
> To: "openid-specs at lists.openid.net" <openid-specs at lists.openid.net>
> Message-ID: <4A8D92F7.1000808 at yahoo-inc.com>
> 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
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs/attachments/20090820/112bf1b8/attachment.htm>