IETF Logo Mail Archive

Re: [HOKEY] Review of draft-gaonkar-radext-erp-attrs-02.txt

Lakshminath Dondeti <ldondeti@qualcomm.com> Fri, 11 January 2008 06:58 UTC

Return-path: <hokey-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JDDqV-00006a-EL; Fri, 11 Jan 2008 01:58:27 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JDDqU-00006T-Jn for hokey@ietf.org; Fri, 11 Jan 2008 01:58:26 -0500
Received: from wolverine01.qualcomm.com ([199.106.114.254]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JDDqS-0007Na-CS for hokey@ietf.org; Fri, 11 Jan 2008 01:58:26 -0500
DomainKey-Signature: s=qcdkim; d=qualcomm.com; c=nofws; q=dns; h=X-IronPort-AV:Received:Received:Received:Message-ID:Date: From:User-Agent:MIME-Version:To:CC:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=EfynmbptgK0jD0+OuZIip7xuki9u+0+NTWLRjm0ZWUXEaT5WA+xPua40 QRDqdnvOFNhq1a5Yje6z/EEiUjePF9IFL1aLT5/Np3G/ppsACHllF6B9f sOvGVBCSPy1jrpXQQ9gqoDltNEYo2RlYTzNalIF46W7RrFHV8gTQW/Jpv Q=;
X-IronPort-AV: E=McAfee;i="5100,188,5204"; a="476794"
Received: from ithilien.qualcomm.com ([129.46.51.59]) by wolverine01.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 10 Jan 2008 22:58:23 -0800
Received: from hamtaro.qualcomm.com (hamtaro.qualcomm.com [129.46.61.157]) by ithilien.qualcomm.com (8.14.1/8.12.5/1.0) with ESMTP id m0B6wMPE010059 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 10 Jan 2008 22:58:23 -0800
Received: from [10.50.69.138] (qconnect-10-50-69-138.qualcomm.com [10.50.69.138]) by hamtaro.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id m0B6wLnE014791 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 10 Jan 2008 22:58:22 -0800 (PST)
Message-ID: <4787138B.70508@qualcomm.com>
Date: Thu, 10 Jan 2008 22:58:19 -0800
From: Lakshminath Dondeti <ldondeti@qualcomm.com>
User-Agent: Thunderbird 2.0.0.9 (Windows/20071031)
MIME-Version: 1.0
To: Alan DeKok <aland@deployingradius.com>
Subject: Re: [HOKEY] Review of draft-gaonkar-radext-erp-attrs-02.txt
References: <477D1029.2060502@deployingradius.com> <477ED21D.9010301@qualcomm.com> <1608.69.12.173.8.1199495480.squirrel@www.trepanning.net> <C24CB51D5AA800449982D9BCB9032513C22802@NAEX13.na.qualcomm.com> <4062.69.12.173.8.1199655622.squirrel@www.trepanning.net> <C24CB51D5AA800449982D9BCB9032513C22A67@NAEX13.na.qualcomm.com> <47843CFD.3040900@deployingradius.com> <C24CB51D5AA800449982D9BCB9032513CF47ED@NAEX13.na.qualcomm.com> <4785467D.1050607@deployingradius.com> <C24CB51D5AA800449982D9BCB9032513CF486 9@NAEX13.na. qualcomm.com> <7105.216.31.249.246.1199927549.squirrel@www.trepanning.net> <C24CB51D5AA800449982D9BCB9032513CF488D@NAEX13.na.qualcomm.com> <4785DEDC.7070707@deployingradius.com> <47867277.3040206@qualcomm.com> <4786FFA8.9010208@deployingradius.com> <C24CB51D5AA800449982D9BCB9032513CF4990@NAEX13.na.qualcomm.com> <478708BE.102080 5@deployingradius.com> <C24CB51D5AA800449982D9BCB9032513CF4991@NAEX13.na.qualcom! m.com> <47870DE9.7000505@deployingradius.com>
In-Reply-To: <47870DE9.7000505@deployingradius.com>
Content-Type: text/plain; charset="ISO-8859-15"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464
Cc: hokey@ietf.org
X-BeenThere: hokey@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: HOKEY WG Mailing List <hokey.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/hokey>, <mailto:hokey-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/hokey>
List-Post: <mailto:hokey@ietf.org>
List-Help: <mailto:hokey-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/hokey>, <mailto:hokey-request@ietf.org?subject=subscribe>
Errors-To: hokey-bounces@ietf.org


On 1/10/2008 10:34 PM, Alan DeKok wrote:

>   All of the arguments for "security" of the re-authentication keys are
> to protect against attacks that no one cares about.  

  BTW, I am fine with proxies.  In fact, that's been my argument against 
mandating 3-party protocols etc.  On the other hand, I am not opposed to 
people developing them.  If people want to non-disruptively design 
protocols for a different threat model, I think we should let them. 
This is the IETF after all.  However, it would be good to prioritize for 
more immediate and practical needs: designing with proxies in mind is 
one example.  So, I also believe it is perfectly alright to design under 
a less than perfect threat model as long as we point out what could go 
wrong.  Along the way, it would also be good to design in a way that 
does not force us to redesign a lot when things change.

Along the way, we need to find a balance between all these design 
principles (and possible others).  It is hard work of course.

I am also a bit of a sucker for elegance.  Madjid said in one of his 
emails "I did
argue "who cares if the hierarchy looks ugly". "  Well, I have the 
opposite take.  I like pretty things :).

best,
Lakshminath


>   Alan DeKok.
> 

_______________________________________________
HOKEY mailing list
HOKEY@ietf.org
https://www1.ietf.org/mailman/listinfo/hokey

v2.23.0 | Report a Bug | By Email