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

Nat Sakimura sakimura at gmail.com
Thu Aug 20 22:51:57 UTC 2009


In the spirit of OpenID, it probably is option 4.
However, there are use cases for 2 and 3 as well in a slightly
different context.

For returning assertion in compliance with NIST SP800-63, we either have to do

(1) Digitally Sign the Assertion OR
(2) obtain directly from a trusted entity where trusted entity (verifier/OP)
     is cryptographically authenticated and protects assertion. (e.g., TLS)

In SP800-63 Digital Signature is defined as:

An asymmetric key operation where the private key is used to digitally
sign an electronic document and the public key is used to verify the
signature.  Digital signatures provide authentication and integrity
protection. }

so, we need 2 in reverse direction.

I also like the idea of signing the request by relying party by its
private key.

Public Keys can be discovered in XRD/S.

If performance permits, we can skip association when request/response are
signed by private keys of each party.

FYI, CX does 2, 3, and 4.

=nat

On Fri, Aug 21, 2009 at 3:30 AM, John Bradley<jbradley at mac.com> wrote:
> 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
>
>
>
>
> _______________________________________________
> specs mailing list
> specs at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs
>
>



-- 
Nat Sakimura (=nat)
http://www.sakimura.org/en/


More information about the specs mailing list