Improving OpenIDs use of cryptography 1 - using a MAC

[Brad Fitzpatrick]

On Thu, 2 Jun 2005, Paul Crowley wrote:

> Brad Fitzpatrick wrote:
> > How is that secret exchanged without encryption?
>
> How is the DSA key exchanged without authentication?
>
> OpenID already assumes that an attacker can't actively interfere with
> the connection between consumer and server.  If they can, they can
> replace the DSA key and thus forge identities.  I'm making the slightly
> stronger assumption that they can't even snoop on it.  Since forging
> such connections on the public Internet is currently *easier* than
> snooping them, this isn't really any stronger an assumption.

True.  In addition to the proof token/check scheme, I did also diagram
out a shared secret scheme... I'm trying to remember now why I came to
dislike it.  I think it was like:

Ignoring snooping (which we've already agreed is unlikely), how do you get
the shared secret from identity server to consumer?  Obviously not through
an HTTP redirect, because then the user and WiFi is involved. It can't be
a publicly accessible URL on the ID server that the consmer can GET,
otherwise anybody could get it.  (obviously can't trust the source IP).
So it has to be the identity server POSTing it to the consumer site.  Now
imagine a consumer site absorbing an identity for the first time and
having to do one HTTP request to the identity server asking for the
identity server to POST back to it.

    Consumer ------> 1. POST /send-me-secret?num=234234 --->  ID Server

         Consumer <------ 2. POST /here-is-secret?num=234234 <---  ID Server

         Consumer ------> 3. OK (got secret!)                --->  ID Server

    Consumer <------ 4. OK (sent secret!)              <----  ID Server

Where 1 and 4 are one transaction, and 2 and 3 are another.

It's just kinda convuluted, and [just to be a whiny sysadmin] requires two
HTTP connections (processes, likely) tied up doing the secret exchange.

I don't think DSA is /that/ hard, especially considering we've seen people
bust out the PHP and Java versions so quickly.  It only needs to be done
once per language, anyway.

Hmm.  I'll think about it more.

> If both consumer and server are in colos and secure against eg DNS
> poisoning, most attackers will have no opportunity to do either to them.
> In practice, they will have much better luck trying to snoop on or
> interfere with the "first hop" between the user agent and everyone else,
> by for example listening in on wireless IP packets.  I'll discuss the
> implications of that later.
>
> > LJ::secret works because LJ is the only party involved... twice.  It knows
> > its own secrets.  (right?)
>
> Right.  But LJ::get_secret is just a carefully implemented way to offer
> many secrets while storing few, so it works for this application too.
> (It's possible I'm misunderstanding how LJ::get_secret works, in which
> case I'll outline what I'm imagining as a good way to solve this problem).

You understand LJ::get_secret.

- Brad