Re: [vwrap] authentication : remove reference to MD5

Sean Hennessee <sean@uci.edu> Wed, 07 April 2010 16:59 UTC

Return-Path: <sean@uci.edu>
X-Original-To: vwrap@core3.amsl.com
Delivered-To: vwrap@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 586093A69A5 for <vwrap@core3.amsl.com>; Wed, 7 Apr 2010 09:59:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E61tU01tfDPI for <vwrap@core3.amsl.com>; Wed, 7 Apr 2010 09:59:02 -0700 (PDT)
Received: from smtp2.es.uci.edu (smtp2.es.uci.edu [128.200.80.28]) by core3.amsl.com (Postfix) with ESMTP id CA38928C12E for <vwrap@ietf.org>; Wed, 7 Apr 2010 09:58:58 -0700 (PDT)
Received: from [128.200.62.123] (sean.nac.uci.edu [128.200.62.123]) (authenticated bits=0) by smtp2.es.uci.edu (8.13.1/8.13.1) with ESMTP id o37Gwslp032381 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 7 Apr 2010 09:58:55 -0700
X-UCInetID: sean
Message-ID: <4BBCB9CB.1000608@uci.edu>
Date: Wed, 07 Apr 2010 09:58:51 -0700
From: Sean Hennessee <sean@uci.edu>
Organization: NACS CCS
User-Agent: Thunderbird 2.0.0.24 (Windows/20100228)
MIME-Version: 1.0
To: Meadhbh Hamrick <ohmeadhbh@gmail.com>
References: <v2zb325928b1004060719nadbc4f76h1be1c4463578fc4a@mail.gmail.com> <4BBB7705.4060206@stpeter.im> <u2vb325928b1004061122u36b2d85cs2a243f2de9231505@mail.gmail.com> <BAY136-DS4DA33BAEC1C8B7F2E09C4DC180@phx.gbl> <u2rb325928b1004062034n384838e1vc91d03e1ece1977b@mail.gmail.com>
In-Reply-To: <u2rb325928b1004062034n384838e1vc91d03e1ece1977b@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: vwrap@ietf.org
Subject: Re: [vwrap] authentication : remove reference to MD5
X-BeenThere: vwrap@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Virtual World Region Agent Protocol - IETF working group <vwrap.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/vwrap>, <mailto:vwrap-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/vwrap>
List-Post: <mailto:vwrap@ietf.org>
List-Help: <mailto:vwrap-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/vwrap>, <mailto:vwrap-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 07 Apr 2010 16:59:03 -0000

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

Meadhbh Hamrick wrote:
> 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/ * OhMeadhbh@gmail.com
> 
> 
> 
> On Tue, Apr 6, 2010 at 4:18 PM, Patnad Babii <djshag@hotmail.com> wrote:
>> 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" <ohmeadhbh@gmail.com>
>> Sent: Tuesday, April 06, 2010 2:22 PM
>> To: "Peter Saint-Andre" <stpeter@stpeter.im>
>> Cc: <vwrap@ietf.org>
>> Subject: Re: [vwrap] authentication : remove reference to MD5
>>
>>> 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
>>>
>>>
>>> --
>>> meadhbh hamrick * it's pronounced "maeve"
>>> @OhMeadhbh * http://meadhbh.org/ * OhMeadhbh@gmail.com
>>>
>>>
>>>
>>> On Tue, Apr 6, 2010 at 11:01 AM, Peter Saint-Andre <stpeter@stpeter.im>
>>> wrote:
>>>> 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
>>>>> vote we remove MD5 from the auth spec and replace it with a MIC with
>>>>> better security properties, like SHA224 or SHA256.
>>>> +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/

-- 

Sean Hennessee
Central Computing Support
Office of Information Technology
UC Irvine


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