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

Lakshminath Dondeti <ldondeti@qualcomm.com> Fri, 11 January 2008 06:48 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 1JDDgj-0003RF-Qu; Fri, 11 Jan 2008 01:48:21 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JDDgi-0003PR-7M for hokey@ietf.org; Fri, 11 Jan 2008 01:48:20 -0500
Received: from wolverine01.qualcomm.com ([199.106.114.254]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JDDgh-0007RT-Fv for hokey@ietf.org; Fri, 11 Jan 2008 01:48:19 -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=Y2l33F5zW+DOXd3tLjjZ37Oj6yjjmAQCw6ane4YCS76DobHBV+laycwN Tq6O6HyZwqJcBRBEXkukPTFBFGjrZTaZhVig1EB2gJYL5pGfoq+L3RgeW NiL7zTjub5RDej6hD2IYWfdCRpPNVQ0FGCIuQVHOCRN47scrB9QzlRxyt s=;
X-IronPort-AV: E=McAfee;i="5100,188,5204"; a="476735"
Received: from numenor.qualcomm.com ([129.46.51.58]) by wolverine01.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 10 Jan 2008 22:48:18 -0800
Received: from msgtransport01.qualcomm.com (msgtransport01.qualcomm.com [129.46.61.148]) by numenor.qualcomm.com (8.14.1/8.12.5/1.0) with ESMTP id m0B6mHtK013668 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 10 Jan 2008 22:48:18 -0800
Received: from [10.50.69.138] (qconnect-10-50-69-138.qualcomm.com [10.50.69.138]) by msgtransport01.qualcomm.com (8.14.1/8.14.2/1.0) with ESMTP id m0B6mGDl030752 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 10 Jan 2008 22:48:17 -0800
Message-ID: <4787112E.3060801@qualcomm.com>
Date: Thu, 10 Jan 2008 22:48:14 -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: 82c9bddb247d9ba4471160a9a865a5f3
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

Huh!  Weird misunderstanding then.  I was just losing my mind over this. 
  Oh well.  Let's try again then :).

I'll try your example.

Requirement: DSRKs are necessary
* Why?
 > Several reasons: Have a key in each domain to do local services. 
Reauthentication being one of them.  The USRK/rRK would provide such 
services at home; is not sent out of the home domain, so let's keep it 
that way.  Derive a key per domain and send it.
* Huh!  Let's say we trust proxies.  Why do I need to send a separate 
key per domain?
 > Well, there are reasons to do it.  <........> {Wrote that in another 
email}
* I don't want to do it.  I want to make things simple.
 > Ok, fine.  Let's have both options.  If you don't want to do it, just 
send a DSRK, the same one to any domain that asks for it.
* Why can't I send my USRK to all domains?
 > Well, the problem is for each service the key needs to be requested. 
  A one-time request is more efficient.

Is that a fair enough compromise?

Sorry if I used harsh words earlier.  I was really taken by the PAP 
references.

thanks,
Lakshminath

On 1/10/2008 10:34 PM, Alan DeKok wrote:
> Narayanan, Vidya wrote:
>> You are not serious that we should be basing our future designs on how
>> PAP works, are you? 
> 
>   <sigh>  No.  I was trying to use analogy and reference.
> 
>   To repeat the discussion in short form:
> 
>  - DSRK's are necessary
>  * Why?
>  - to avoid exposing credentials across domains and proxies
>  * So?
>  - it would be catastrophic!
>  * No, it's accepted practice in many areas, and has zero problems
>  - you're proposing that we use PAP?
>  * Huh?
> 
>   All of the arguments for "security" of the re-authentication keys are
> to protect against attacks that no one cares about.  I referred to
> existing practices as proof that those arguments were unfounded.  I did
> NOT propose that we replace EAP with PAP, and it's fairly annoying that
> my comments were read that way.
> 
>   Alan DeKok.
> 

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