Subject: [vwrap] authentication : remove reference to MD5

From: Meadhbh Hamrick <[email-masked]>
Date: Tue, 6 Apr 2010 07:19:56 -0700

okay.

if we're going to remove VWRAP from all current implementations, i
vote we remove MD5 from the auth spec and replace it with a MIC with
better security properties, like SHA224 or SHA256.

-cheers
-meadhbh

--
meadhbh hamrick * it's pronounced "maeve"
@OhMeadhbh * http://meadhbh.org/ * [email-masked]

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 06 Apr 2010 12:01:41 -0600

On 4/6/10 8:19 AM, Meadhbh Hamrick wrote:
> okay.
> 
> if we're going to remove VWRAP from all current implementations,

What does that mean? I thought we were trying to build VWRAP into
implementations, not rip it out. :)

> i

+1 to more secure authentication.

My quick reading of the authentication draft led me to think that it
needed a thorough review, but unfortunately I haven't had time to do
that yet.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Richard Barnes <[email-masked]>
Date: Tue, 6 Apr 2010 14:07:38 -0400

> implementations, not rip it out. :)

Right, I think the right approach is to think about adding a "VWRAP  
compatibility layer" to existing implementations, and keeping that  
layer as simple as possible (but no simpler!).

That raises the question of where changing hashes falls w.r.t.  
simplicity.  It might seem like you would want to keep MD5 so that the  
compatibility layer wouldn't have to re-hash things.  However, it  
already seems like there's going to be a need for the compatibility  
layer to translate names, which will (presumably) break signatures  
already.  So since there's already need to re-hash, it's not a big  
deal to re-hash with a different hash function.

--Richard

> _______________________________________________
> vwrap mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/vwrap

---

From: Meadhbh Hamrick <[email-masked]>
Date: Tue, 6 Apr 2010 11:29:45 -0700

i don't think we're proposing using digital signatures in the
authentication draft.

i would also point out that "simply adding a VWRAP compatibility
layer" would introduce non-zero engineering costs to both LL and the
OpenSim community. but what is worse, is that it would stray from our
charter.

the objective of this group is, if you will recall, to make standards
for interoperability between hosts that implement a type of virtual
experience we sometimes refer to as "second lifelike." it's not SL,
but something with a similar architecture. it is NOT a compatibility
layer for arbitrary virtual world protocols. we tried that with MMOX,
it did not work.

VWRAP != MMOX.

what i am mostly concerned about is, that if we don't have an idea for
how close we wish to stick to existing implementations, there's no
telling where we'll wind up.

-cheers
-meadhbh

On Tue, Apr 6, 2010 at 11:07 AM, Richard Barnes <[email-masked]> wrote:
> compatibility layer" to existing implementations, and keeping that layer as
> simple as possible (but no simpler!).
>
> That raises the question of where changing hashes falls w.r.t. simplicity.
>  It might seem like you would want to keep MD5 so that the compatibility
> layer wouldn't have to re-hash things.  However, it already seems like
> there's going to be a need for the compatibility layer to translate names,
> which will (presumably) break signatures already.  So since there's already
> need to re-hash, it's not a big deal to re-hash with a different hash
> function.
>
> --Richard
>
>
>
>
>>> i

---

From: Meadhbh Hamrick <[email-masked]>
Date: Tue, 6 Apr 2010 11:22:58 -0700

we need clarification about how much of the second life legacy
protocol will be used in VWRAP.

for instance. second life stores the MD5 hash of user passwords in the
user database and uses it to authenticate users when logging in.

but MD5 has some significant problems which were exacerbated several
years ago when there was a security breach of linden's servers.

so if we simply said "we're going to ditch MD5 in favor of SHA256"
there would be a problem with reverse compatibility of the
authentication data. this is because you can't generate the pre-image
from an MD5 MIC and then use it to generate a SHA256 MIC. (or you
can't do that in a way that insures that your MD5 pre image is the
same as the password.)

so in other words, there is an action we could take in this group that
COULD make it very difficult for linden and presumably existing
OpenSim instances to use the authentication protocol.

so the question is, to which degree do we add an engineering burden to
existing implementations that would like to adopt this group's output?
the question of the two string identifier is a good one. linden could
probably make systems that adhere to all sorts of different changes.
but to what degree to we make it easy for existing implementers vs.
the desires of people who have yet to build and implementation?

-cheers
-meadhbh

---

From: Barry Leiba <[email-masked]>
Date: Tue, 6 Apr 2010 17:25:01 -0400

> can't do that in a way that insures that your MD5 pre image is the

The usual way to handle this is with a migration process.  Credentials
are re-hashed with the new algorithm when they're changed, over time.
After a time, there's a cutoff and users are forced to change their
credentials the next time they log in.  The old login has to be
supported as long as there are users who have not yet changed... or
until someone decides to toss those users.

Barry

---

From: Meadhbh Hamrick <[email-masked]>
Date: Tue, 6 Apr 2010 15:01:18 -0700

yes. but until the migration is complete for all users, do we
implement the new spec with SHA256? do well tell users they have until
a certain date to login and regenerate the hash?

it would be nice if we could have SOME reverse compatibility so we
could use the maintenance facility to do the rehashing. so you could:

1. on a certain date, stop returning seed caps from a successful login
with MD5, but include a maintenance cap with an URL pointing to a page
users can use to rehash their password.

2. at the web page, users re-enter their password, it's hashed with
SHA256 and it's stored in the database.

3. the next time that user logs in, they hash their password with
SHA256 instead of MD5 and avoid having to go through the process
again.

4. at some point in the future, you disable logins for people with
only MD5 hashed passwords (maybe).

what we would need to make this work would be:

a. a way to log in with MD5 until you can use VWRAP to carry the
SHA256 password.

b. a way to figure out which hashed password to send (MD5 or SHA256).

in the case of second life, you probably COULD get away with using MD5
with the legacy protocol. i can't remember if the current legacy
protocol supports maintenance caps. if it does you could use a
maintenance cap. if not, you simply fail and wait for the user to call
the support line. this would be pretty costly, but if we really want
to avoid legacy in the new protocol, we're probably going to see a
number of issues like this.

if we had just enough legacy in the new protocol to support MD5, we
could use the maintenance capability as described above. if we added a
return value from the auth request that had the meaning of
"unsupported algorithm" the client would know to retry the MD5 request
with SHA256.

just my $0.02.

-cheers
-meadhbh

---

From: Meadhbh Hamrick <[email-masked]>
Date: Tue, 6 Apr 2010 15:11:04 -0700

but ultimately, the question is, "how much legacy are we willing to
support?" i don't think it was answered here, and i think we really
should make some attempt to address it.

the OpenSim grids and SL use radically similar protocols to do auth
now. if we decided we didn't want to define a protocol with enough
legacy to handle the MD5 based auth, then LL would likely use a
technique that was proprietary. sure, the OpenSim people would reverse
engineer it (i mean, after all, the viewer source is GPL licensed and
pushed out the door with sufficient regularity.)

or we could simply define reverse compatibility as part of the
standard and allow deployers to start the migration on their time
frame.

removing MD5 auth from the spec is a bad idea because it forces people
to deploy proprietary mechanisms to bring their systems in line with
VWRAP when they COULD just as easily do the same thing with an open
spec.

what is definitely a good idea is to add the text "MD5 is provided for
reverse compatibility and should not be used for new implementations"
if it's not there already.

-cheers
-meadhbh

---

From: "Patnad Babii" <[email-masked]>
Date: Tue, 6 Apr 2010 19:18:40 -0400

I think if someday LL ask me to change my password because they made their 
security system better i would really not mind. So typing a password take 1 
minute for changing it.

Same for all opensim grid if they someday ask me to change my password 
because they enforced security i'd be more than happy to provide them with a 
new one.

I don't think people will leave SL just because you "forced" them to change 
a password honestly.

--------------------------------------------------
From: "Meadhbh Hamrick" <[email-masked]>
Sent: Tuesday, April 06, 2010 2:22 PM
To: "Peter Saint-Andre" <[email-masked]>
Cc: <[email-masked]>
Subject: Re: [vwrap] authentication : remove reference to MD5

---

From: Meadhbh Hamrick <[email-masked]>
Date: Tue, 6 Apr 2010 20:34:53 -0700

actually. that does bring up a good point. LL _could_ just invalidate
everyone's password and make them go through password reset.

i agree, patnad, i would do it too, but it may be difficult to
convince everyone to do it, and i'm not sure it's the kind of thing a
standards organization should require of one of it's implementers.

just my $0.02, but yeah, i'll let the lindens speak for themselves.
--
meadhbh hamrick * it's pronounced "maeve"
@OhMeadhbh * http://meadhbh.org/ * [email-masked]

---

From: Sean Hennessee <[email-masked]>
Date: Wed, 07 Apr 2010 09:58:51 -0700

If VWRAP has no legacy support, can't the implementors still have mixed 
mode support as long as they decide to? Just because an implementor 
supports VWRAP, (with no legacy support), doesn't necessarily mean they 
can't support legacy protocols as well. Eventually one would hope all 
would transition to only VWRAP, but implementors are really the 
determining factor of how long that transition takes. Even many web 
browsers continue to support old versions of the HTML spec while still 
supporting newer versions.

Perhaps VWRAP should include a protocol negotiation protocol allowing 
services to determine what protocols and versions of protocols are 
supported on each end. "Sorry, your client is not supported on this sim" 
should be an option. I see (saw) it often when connecting to SL after 
major client/server updates.

Peace,
Sean

-- 

Sean Hennessee
Central Computing Support
Office of Information Technology
UC Irvine

... . .- -. /  .... . -. -. . ... ... . .

---

From: Carlo Wood <[email-masked]>
Date: Fri, 9 Apr 2010 15:38:03 +0200

> the desires of people who have yet to build and implementation?

I think that the worst we can do is to make a standard that isn't
as good as it could have been.

In other words, we don't want a "legacy" bug in the protocol.

However,
nothing, absolutely nothing, cannot be solved by adding protocol
negotiation to VWRAP.

For example, we define the standard to use SHA256. But Linden Lab
adds an extension, negotiated with the client at connection, to
use an MD5 hash. Surely you're not afraid that viewer developers
will refuse to support that ;).

Lets have a look at the effects of my protocol negotation proposal again:

1) It will allow us to make mistakes now, and fix them entirely in the future.
2) It will allow us to make a start with the protocol, and complete it in the future.
3) It will allow easy transitions of legacy protocols to the standard over an
   arbitrary period of backwards compatibility.
4) It might, hopefully, lead to protocol evolution, where good changes of the protocol
   are copied by everyone; causing the Virtual World protocol to evolve into
   a better and better protocol without limits, without becoming a legacy burden.

Think about it: ALREADY Linden Lab is complaining that VWRAP can't do
this and should do that because it's hard for them to implement it otherwise.
THAT WILL ONLY GET *MUCH* WORSE! Once we have hunderds of grids, thousands
of viewers and ten millions of users, it will be IMPOSSIBLE to change
the protocol. It will be become one big legacy nightmare with no possibility
to fix things.

Don't think for a second that we are capable of designing the perfect
protocol right now, before anything like all this exists (and don't
tell me that Linden Labs current protocol is the perfect protocol
already).

---

Recap of the TECHNICAL DETAILS:

The protocol negotiation system exists of two equally important parts:

1) Negotiation of "Features".
2) Documentation of "Features".

Lets forget the documentation part of a moment, just assume that
it is possible to easily find how to implement any feature.
Then the protocol negotiation boils down to negotiations of booleans:
Yes or No this feature.

There are two types of features: mandatory (M) features and optional (O) features.
For each connection between two hosts, there is a protocol negotiation
and thus there are two sides (A and B) that both can have mandatory or optional
features. The total number of possibly combinations for any given feature
are therefore:
X: unknown or not implemented (non-existant)
O: Optional
M: Mandatory

A B	result

X X	not used
X O	not used
X M	incompatible
O X	not used
O O	used (or not?)
O M	used
M X	incompatible
M O	used
M M	used

There is another level of compatibility however, besides whether a mandatory
feature is available on both sides: compatiblity of the negotiation itself.

Namely, in order to be able to "shift the origin" of the protocol, it must
be possible to make a mandatory option part of the "base" of the protocol
(for which no negotiation is needed).

In otherwords, a feature has four states:

				Protocol version p
X: non-eXistent			     p < V
N: Not implemented		V <= p < W
O: Optional			V <= p < W
M: Mandatory (negotiated)	V <= p < W
B: Base protocol		W < p

Negotiation of such a feature will fail if one side assumes the feature
is in the Base (assumed mandatory), while the other side doesn't even
know of it's existance (X). This is where the (negotiation) compatibility
version comes in: if a new feature is introduced in an implementation
Foo at version V, then implementations made for Foo of an earlier version
does not know about that feature. That is not a problem however, until
that feature is made a part of the Base protocol in version W > V.

Thus, each side tells eachother their "protocol version", and the side
with the largest version decides if they are compatible by comparing
the smaller version with the "compatibility version" V (in the case
above the "compatibility version" of W is V).

How does one determine the "compatibility version"? This is simple:
it is the smallest version where every feature that is part of the base
protocol in the current version still existed (and did exist in all
versions in between).

This simple compare then takes care of (B,X) and (X,B) pairs: they
won't exist if the smaller version is larger or equal than then
the compatiblity version of the larger version.

Each implementation contains two version numbers (only) thus.
After comparing versions, X and N collapse into X as used in the first table.

EXAMPLE

Implementation of Linden Lab server protocol 100, with compatiblity
version 40. Viewer connects (supporting the "Linden Lab" protocol)
with protocol version 50. Negotiation is allowed since 50 is not
less than 40.

The server tells the viewer that feature MD5HASH is mandatory.
The viewer knows about this, because this feature was already
part of the protocol since version 1. It has this feature as
optional, and the negotiation results in it being used.

The factual messages needed upon connect are:

client connects
client --> server: PROT		(this requests protocol negotiation, without it, the legacy protocol is used)
                   (possible other base protocol start up messages)
server --> client: GRID LINDENLAB 100 40		(possible other LABEL CURVERSION COMPATVERSION triplets can be appended)
client --> server: PROT REQ LINDENLAB 50 ENCRYPTION	(ENCRYPTION is known *optional* in version 50)
server --> client: PROT SET LINDENLAB 50 MD5HASH	(server rejects ENCRYPTION because it is now version 100 and demands MD5HASH)
  (server switches to feature set for outgoing messages here)
client --> server: PROT ACK LINDENLAB 50 MD5HASH	(client agrees, and signals it switches protocol here)
  (client switches to feature set for outgoing messages here)

Now suppose that somewhere in the (far) future Linden Lab manages to 
switch to SHA256 passwords (ie, by having everyone register again),
and they add the optional feature SHA256LOGIN in version 1000.
Every client can still connect, because it is only optional.
However, again a few years later when all viewers caught up with
the new feature, it is made mandatory in version 1100 (say).
Then the protocol negotiation could look as follows:

client --> server: PROT		(without this, viewer is rejected as being incompatible)
server --> client: GRID LINDENLAB 1100 1000 OPENSIM 878 512 CABLEBEACH 1250 733
client --> server: PROT REQ LINDENLAB 1050 OGRE LIPSYNC
server --> client: PROT SET LINDENLAB 1040 OGRE
client --> server: PROT ACK LINDENLAB 1040 OGRE

and the MD5HASH legacy feature has completely vanished
from the negotiation: the protocol has now shifted truely
to the standard (or rather, to LINDENLAB version 1000).

-- 
Carlo Wood <[email-masked]>

---

From: Sean Hennessee <[email-masked]>
Date: Fri, 09 Apr 2010 09:31:05 -0700

+1 to protocol negotiation in VWRAP

IMAP and POP3 have similar protocol negotiation tools, IMAP uses the 
CAPABILITY command and POP3 uses the CAPA command. These commands allow 
client and server to negotiate things like whether clear text logins are 
allowed, or if StartTLS is required, (essentially the same type of thing 
we were discussing wrt SHA256 vs MD5.) Considering VWRAP will be a 
fairly complicated protocol compared to IMAP and POP, some sort of 
capabilities tool or protocol negotiation will be indispensable.

POP/IMAP stuff here: http://www.faqs.org/rfcs/rfc2595.html
(Search for 'capability' for examples.)

Peace,
Sean

-- 

Sean Hennessee

---

From: Morgaine <[email-masked]>
Date: Sat, 10 Apr 2010 09:07:35 +0100

+1 for feature negotiation.

+1 for protocol negotiation.

Really there is no good alternative to feature negotiation when a single
client application has to work with countless worlds in a huge metaverse.
Diversity among worlds is inevitable, not only because of progress, but also
because product differentiation drives business.  The client and server
endpoints are likely to have fully identical feature sets only by rare
coincidence in a metaverse of interop.

Likewise for protocol negotiation, it is needed to cope with protocol
evolution among countless worlds, services, and clients.  It is not viable
for each evolutionary protocol change to have to revisit this working
group.  At best we are providing an initial framework and a launching pad
for what VWRAP will become.

Protocol negotiation will be required for two reasons, first because all
protocol options will not always be available, and second because the base
protocol must be able to evolve as well.  We have many times stated that
VWRAP is to be an extensible protocol, and what this means in practice is
that both protocol options and the base protocol need to be negotiated.
Endpoints will need to detect protocol variation and adapt, otherwise broad
interop will be nothing but a wish.

Carlo's points are well stated.  While the actual mechanism and details of
feature and protocol negotiation are a matter for much more analysis,
providing negotiation machinery isn't really optional if the protocol is to
be of value to numerous worlds and applications that evolve far beyond the
current legacy generation.

Morgaine.

=======================================

On Fri, Apr 9, 2010 at 2:38 PM, Carlo Wood <[email-masked]> wrote:

> server --> client: GRID LINDENLAB 100 40                (possible other
> LABEL CURVERSION COMPATVERSION triplets can be appended)
> server --> client: PROT SET LINDENLAB 50 MD5HASH        (server rejects
> ENCRYPTION because it is now version 100 and demands MD5HASH)