[vwrap] auth draft todo..

[Meadhbh Hamrick <[e-mail]>]

so... is it my imagination or is the auth draft starting to come together?

but there are still a few todo's left. i'm going to be working on them in
the near future, and will publish another draft after the f2f later this
month. (did we decide if there was going to be a VWRAP f2f this time
around???)

anyway... here's a list of things left to do on the auth draft:

1. add trust model section - mea culpa. i should have finished this earlier.
expect another email about the trust model. the linden grid, opensim grid +
services, standalone and tourist models are diverse enough, i want to make
sure that any trust model documentation supports each of these use cases.

2. make SHA384 an option for authenticators ??? - so if you google "suite
b", you can read about the two hash functions that the NSA thinks are
copacetic for non-top-secret but sensitive government use. these include
SHA-256 and SHA-384. right now the draft only says SHA-256. CNSSP-15 tells
us that SHA-384 is really only there to generate parameters for 384 bit ECC
crypto primitives. but i wonder if there's anyone out there in fed-space
that would require SHA-384 for virtual worlds use? if anyone out there knows
of such a requirement, please let me know and i'll add SHA-384 as an option
to this draft. otherwise, i recommend we support ONLY SHA256 until we're all
comfortable with it's implementation and deployment.

3. better description of the difference between transport and application
layer authentication - okay... this is something that kinda throws people,
so lemme mention it here. i would also like to write a blurb about it in the
next draft of the auth spec. ultimately what we're trying to do with user
auth is for a client to demonstrate their authorization to use sensitive
data regarding a user's virtual world agent. this usually involves
authentication; having the client prove they're in possession of a secret
shared between the client and the auth server.

so far, so good, right? i mean. no one disputes this, right?

where things get interesting is when we start to rely on transport-based
authentication. HTTP basic and digest auth identifies and authenticates a
user at the HTTP transport layer. but what if we wanted to carry some
sensitive payload over XMPP or RTP? we probably shouldn't rely on HTTP
digest auth in those cases (and besides, HTTP digest auth is essentially
broken unless carried over HTTPS.)

and speaking of TLS, what are we authenticating when we authenticate a cert
chain? you're not authenticating an authentication service, you're
authenticating the host it's running on. this is usually close enough, but
i'm nervous about when services move into the cloud and start migrating
around to different hosts. (besides TLS is usually only configured to
authenticate the server, not the client.)

in the "real world" client auth in TLS usually comes from doing HTTP auth or
some app layer something-or-other (like possession of session cookie) over
HTTP over TLS. or you can use client certificates. i love client certs, but
then again i used to work for a company that sold a cert issuing system.
while i would love to sell you a PKI system, i'll be the first to admit,
it's not the be-all, end-all to authentication that some peeps have said it
is in the last couple of decades. besides, client certs are generally used
to authenticate the client's host. so when the user moves to a new machine,
no more TLS client cert auth. unless they're using smart cards. don't get me
started about smart cards. we're not requiring people to use smart cards.

and then there's the issue of proxy authentication. a few of us use the
interwebs with proxies you have to provide credentials to. do a google
search on this! it's true! actually.. i think a lot of HTTP proxy
authentication is used in situations where services are composed over
primitive service busses and use proxy auth as a first line of defense or as
a way to integrate with legacy password / username systems.

but i guess what i'm saying is... it's entirely possible we'll be required
to authenticate a client to an authentication service in an environment
where HTTP(S) based auth is not appropriate. in these cases, we'll probably
find that the VWRAP message traffic is going over infrastructure where the
transport auth is used for some other purpose, or it's not available to the
developer (think of a web app fronted by a HTTPS accellerator that strips
out TLS and HTTP auth info.)

and this is why we have authentication info INSIDE the application layer
message flows. 'cause you're authenticating an application component (the
client) with another application component (the auth server.) sometimes you
get lucky and you can re-use your transport auth, but not always.

and this is kind of what i wanted to put in the draft... "sometimes you can
use previously established transport based authentication, but sometimes you
can't."

-cheers
-meadhbh
--
meadhbh hamrick * it's pronounced "maeve"
@OhMeadhbh * http://meadhbh.org/ * [e-mail]