On Mon, May 19, 2008 at 6:45 PM, Martin Langhoff <[EMAIL PROTECTED]> 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 -- [EMAIL PROTECTED] [EMAIL PROTECTED] -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff _______________________________________________ Server-devel mailing list Server-devel@lists.laptop.org http://lists.laptop.org/listinfo/server-devel