Bitfrost's P_SERVER_AUTH

[Martin Langhoff]

On Mon, May 19, 2008 at 6:45 PM, Martin Langhoff
<martin.langhoff at gmail.com> wrote:
> are there any further notes about how you intended the P_SERVER_AUTH
> stuff to work? Was this envisioned to be an ident-style service that
> responds to a crypto challenge (a safe variation of "show you have the
> private key by signing this token")? How do we make the challenge safe
> for the client?

Had a serendipitous bump w Ivan and Rob McQueen on irc, and we
discussed this. Possible plans of action

 - SRP (RFC 2945) reaching out to the XS (triggered when we spot an XS).
 - HTTP over SSH.
 - HTTPS with the XO SSH keys wrapped as an SSL client cert.

 Mostly unedited IRC log follows

<neuralis> the basic idea was to detect a school server, prove key
possession to it which would authenticate you to the openid idp
running on there
<neuralis> you don't have to trust the server for that, so it's no big
deal if someone lies to you
<neuralis> the bigger problems are conceptual: what happens when
you're not in your school, what happens when your xs is down, etc
<martin_xsa> yes, my concern is how to prove the key possession in a
crypto-safe manner, and with minimal impact on the browser activity...
<neuralis> martin_xsa: srp
<neuralis> from not within the browser
<neuralis> rfc 2945 or 2954, i don't recall right now
<martin_xsa> ident-like service?
<martin_xsa> ok, SRP, will read up on that
<neuralis> yeah, a mini-daemon that sits on dbus waiting for network
notifications, then looks at something like arp or another heuristic
to sniff out an xs it knows
<neuralis> then initiates srp auth to it
<dilinger> i haven't heard anything about srp in ages
<martin_xsa> and somehow the xs assumes that the identity of the srp
process extends to the webbrowser process
<martin_xsa> (which is reaching us from a different port...)
<neuralis> martin_xsa: well, it assumes that the identity of the srp
ip is the same as of the web browser running on that ip
<neuralis> so you're vulnerable to certain kinds of attacks on your
local network
<martin_xsa> neuralis, so if we infer that from srp, we assume we don't do NAT
<neuralis> on the way from xo to xs? correct
<neuralis> i mean, if you wanted to solve this more intelligently, you
could look into just tunneling everything through ssh with an
inexpensivish cipher
<neuralis> which also deals with nat
<neuralis> and isn't vulnerable to many of the local-net attacks
<martin_xsa> I thought of negotiating a cookie over ssh or similar ;-)
<neuralis> there are lots of nice things about doing all web traffic
over ssh opportunistically
<martin_xsa> and then continuing use over plain http
<martin_xsa> but it's a ton of work to support transparently
<neuralis> how so?
<martin_xsa> I yearn for something simple
<neuralis> transparent ssh is trivial nowadays
<neuralis> you know about -D, right?
<martin_xsa> yes, and we could force a proxy on the browse activity
<neuralis> correct
<martin_xsa> but it breaks assumptions and we'll get in trouble later
<neuralis> what kind of concerns do you have, specifically?
<martin_xsa> first - I don't know in what state the plugin world is -
do plugins use the browser's http machinery, or do they do their own?
They used to do their own.
<martin_xsa> second - the "we have a proxy" machinery within the
browser is built to have a concept of "local network traffic,
nonproxied" and "external traffic, proxied". Our model would be
different from that, and I don't think it will fit well. And it's a
huge codebase to deal with (ed: if we wanted to tweak the behaviour).
<Robot101> martin_xsa: if it's helpful, we can use the XMPP connection
from the laptop to do some stuff which results in an authentication
cookie becoming available to the browser/others
<Robot101> martin_xsa: it'd be good to hook XMPP in to use the same
auth you're talking about here
<martin_xsa> and third - it's not what the browser is built to do, so
we are guaranteed to bump into corner cases that don't do what we'd
expect at first blush.
<martin_xsa> So in short, I think we could show a
proof-of-concept/mostly-works easily, but delivering a polished
experience would be very involved.
<martin_xsa> Robot101, that sounds reasonable. Does our XMPP layer
have any crypto guarantees? (they don't have to be perfect...)
<Robot101> martin_xsa: currently no, we do a SSL negotiation with no
key checking, purely to obtain DEFLATE
<Robot101> martin_xsa: but it's SSL - you can add checking of keys in
either direction
<martin_xsa> hmmm.
<martin_xsa> what if...
<martin_xsa> can our browser do ssl?
<Robot101> yes
<Robot101> you can give the browser a client certificate to present to
web sites as authentication
<martin_xsa> exacto! if we can get the "self-signed-cert" dialogue
problem resolved somehow, we are go
<Robot101> ok, well gecko can do that in general, obviously it's not
exposed in Browse's UI, but it's there
<martin_xsa> we can pre-generate it when we generate the ssh keys, and
transfer it to the xs during registration
<Robot101> so I kinda jumped in half way through, who's authing who to who here?
<martin_xsa> and voila!
<martin_xsa> ah, I want to be able to authenticate XO to XS
<martin_xsa> the XO gets to say "I'm the same machine that registered
with you a while ago, remember?"
<martin_xsa> not particularly strong identity, but it's what we have ;-)
<Robot101> right
<Robot101> would be nice if we could tighten up XMPP similarly
<Robot101> by way of avoiding extra keys, its probably possible to
mangle the XO's key into something usable as a client cert
<martin_xsa> can we use RSA/DSA keys as SSL client certs?
<Robot101> well, the SSL certs are just RSA/DSA keys with X.509 gumph on top
<martin_xsa> I might have to read up on that, then ;-)
<Robot101> so yes, seems eminently doable
<Robot101> and to solve the certificate nag, the XS can deliver a
self-signed certificate (for just it's hostname) which can be added on
the XO
<Robot101> (not as a CA, just as an "recognised for this site" cert)
<martin_xsa> Hmmm. We could do that (XS tell XO about the self-signed
cert) during registration too then.
<martin_xsa> Sounds like a good plan.

cheers,


m
-- 
 martin.langhoff at gmail.com
 martin at laptop.org -- School Server Architect
 - ask interesting questions
 - don't get distracted with shiny stuff - working code first
 - http://wiki.laptop.org/go/User:Martinlanghoff