Re: E2E and crypto-agility
Alan DeKok <aland@nitros9.org> Thu, 03 January 2008 23:27 UTC
Return-path: <owner-radiusext@ops.ietf.org>
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JAZTj-0006Ip-9z for radext-archive-IeZ9sae2@lists.ietf.org; Thu, 03 Jan 2008 18:27:59 -0500
Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JAZTi-0002Lc-Sv for radext-archive-IeZ9sae2@lists.ietf.org; Thu, 03 Jan 2008 18:27:59 -0500
Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from <owner-radiusext@ops.ietf.org>) id 1JAZQc-000GfZ-GB for radiusext-data@psg.com; Thu, 03 Jan 2008 23:24:46 +0000
X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com
X-Spam-Level:
X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.3
Received: from [216.240.42.17] (helo=deployingradius.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from <aland@nitros9.org>) id 1JAZQZ-000GfB-JO for radiusext@ops.ietf.org; Thu, 03 Jan 2008 23:24:45 +0000
Received: from [192.168.0.14] (pas38-1-82-67-71-238.fbx.proxad.net [82.67.71.238]) by deployingradius.com (Postfix) with ESMTP id 6D8C3A71A3; Thu, 3 Jan 2008 15:24:37 -0800 (PST)
Message-ID: <477D6E52.60602@nitros9.org>
Date: Fri, 04 Jan 2008 00:22:58 +0100
From: Alan DeKok <aland@nitros9.org>
User-Agent: Thunderbird 2.0.0.6 (X11/20071022)
MIME-Version: 1.0
To: Glen Zorn <glenzorn@comcast.net>
CC: Bernard_Aboba@hotmail.com, radiusext@ops.ietf.org
Subject: Re: E2E and crypto-agility
References: <tslabo4d851.fsf@mit.edu> <BAY117-W1792E6240C29062FF9B6F2935F0@phx.gbl> <47729414.9070608@nitros9.org> <BAY117-DS17BF5949D5EDD59B29614935B0@phx.gbl> <47737D1C.5050208@nitros9.org> <00b101c84e5c$f7e0c600$e7a25200$@net>
In-Reply-To: <00b101c84e5c$f7e0c600$e7a25200$@net>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
Sender: owner-radiusext@ops.ietf.org
Precedence: bulk
X-Spam-Score: -4.0 (----)
X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa
Glen Zorn wrote: > It's hard to see how this solves any known problem. We already know how te > secure the key on the wire; the only problem is with evil proxies. Um... if you don't trust the proxies, why are you letting them control access to your network? RADIUS authentication routing is *not* IPv4 packet routing. There are commercial agreements in place for RADIUS traffic between any two networks. This isn't true for IPv4. > Since in > the last step the end-user transmits K'' to the NAS (necessarily unencrypted > since the peer & NAS do not yet share any keying material) The NAS can prove to the peer that it knows the encrypted key. The peer can then send the NAS the decryption key, or any other key derivation function. > you have > basically divulged your key-encrypting key to the world, which of course > includes any RADIUS proxies that were in the forwarding path. So what does > this help? Giving a key to the NAS is equivalent to giving it to the local AAA server, because they are run by the same administrative entity. So *any* proposal that gives keying material to the NAS is vulnerable to this attack. If the desire is to protect against third-party proxies, such as roaming or interconnect providers, see my first set of comments. In addition, the local NAS (and AAA server) can choose to share that keying material with anyone else in the world, including RADIUS proxies. This is true today. The MPPE keys used for 802.1x keying today are shared in the clear with all RADIUS proxies. Is there a *real-world* problem we're trying to solve here, or a theoretical exercise that is made moot by real-world business realities? Alan DeKok. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://psg.com/lists/radiusext/>
- RE: [ Comments on automated key management and cr… Bernard Aboba
- Re: [ Comments on automated key management and cr… Alan DeKok
- RE: [ Comments on automated key management and cr… Glen Zorn
- Re: E2E and crypto-agility Bernard_Aboba
- Re: Comments on "practical deployments" Bernard_Aboba
- Re: Comments on "practical deployments" Alan DeKok
- RE: Comments on "practical deployments" Bernard Aboba
- RE: Comments on "practical deployments" Bernard Aboba
- RE: Comments on "practical deployments" jouni.korhonen
- Re: Comments on "practical deployments" Alan DeKok
- Re: Comments on "practical deployments" Alan DeKok
- Re: E2E and crypto-agility Alan DeKok
- RE: Comments on "practical deployments" David B. Nelson
- RE: Comments on "practical deployments" David B. Nelson
- Re: Comments on "practical deployments" Alan DeKok
- Re: Comments on "practical deployments" Alan DeKok
- RE: E2E and crypto-agility Glen Zorn
- Re: E2E and crypto-agility Alan DeKok
- RE: E2E and crypto-agility Glen Zorn
- Re: Comments on "practical deployments" Stefan Winter
- Re: Comments on "practical deployments" Stefan Winter
- Re: Comments on "practical deployments" Stefan Winter
- Re: E2E and crypto-agility Alan DeKok
- Re: E2E and crypto-agility Bernard_Aboba
- Re: E2E and crypto-agility Bernard_Aboba
- Re: E2E and crypto-agility Alan DeKok
- RE: E2E and crypto-agility Glen Zorn