IETF Logo Mail Archive

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

Alan DeKok <aland@deployingradius.com> Fri, 11 January 2008 16:16 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 1JDMYK-0001vo-KP; Fri, 11 Jan 2008 11:16:16 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JDMYJ-0001vi-1W for hokey@ietf.org; Fri, 11 Jan 2008 11:16:15 -0500
Received: from www.deployingradius.com ([216.240.42.17] helo=deployingradius.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JDMYH-0007fJ-8p for hokey@ietf.org; Fri, 11 Jan 2008 11:16:15 -0500
Received: from [10.0.1.49] (alexander.quiconnect.net [213.30.156.62]) by deployingradius.com (Postfix) with ESMTP id 19147A704E; Fri, 11 Jan 2008 08:16:09 -0800 (PST)
Message-ID: <478795DB.8080105@deployingradius.com>
Date: Fri, 11 Jan 2008 17:14:19 +0100
From: Alan DeKok <aland@deployingradius.com>
User-Agent: Thunderbird 2.0.0.6 (X11/20071022)
MIME-Version: 1.0
To: "Narayanan, Vidya" <vidyan@qualcomm.com>
Subject: Re: [HOKEY] Review of draft-gaonkar-radext-erp-attrs-02.txt
References: <477D1029.2060502@deployingradius.com> <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> <C24CB51D5AA800449982D9BCB9032513CF4999@NAEX13.na.qualcomm.com>
In-Reply-To: <C24CB51D5AA800449982D9BCB9032513CF4999@NAEX13.na.qualcomm.com>
X-Enigmail-Version: 0.95.0
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2
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

Narayanan, Vidya wrote:
> I'm really confused.  If there are no security issues with PAP and if
> exposing the actual credentials to all proxies is just fine, why would
> we need EAP?  Why is PAP not good enough? 

  Because it exposes credentials in the clear to *untrusted* parties.

  The first step of WiFi authentication using PAP is insecure (user ->
AP).  But after that, PAP authentication via *trusted* AAA proxies is
secure.  Existing AAA protocols ensure that the PAP credentials are
secured from *untrusted* parties.

  And no, I am *not* proposing that hokey uses PAP.

> I'm sorry that you find it annoying to have this discussion.  If it is
> any consolation, I find it equally annoying that we would use PAP as an
> analogy and say that exposing credentials are fine. 

  To *trusted* parties.  My example was about proxies with established
business relationships, *not* about exposing credentials to everyone.

  If you do not trust the proxies with the user's credentials, then you
have no reason to have a business relationship with them.  Businesses
exchange clear-text credentials all of the time (e.g. credit card
details).  This is NOT a technical problem, and it has NEVER been a
technical problem.  There are commercial and legal remedies to the theft
or abuse of credentials by trusted parties.

  If you do not trust the local server with the user's credentials, then
you do not trust it to cache the DSRK (almost by definition).   At that
point hokey becomes irrelevant.

  Alan DeKok.

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

v2.23.0 | Report a Bug | By Email