IETF Logo Mail Archive

Re: [radext] Gathering opinions on draft-xue-radext-key-management

Xueli <xueli@huawei.com> Wed, 09 July 2014 02:07 UTC

Return-Path: <xueli@huawei.com>
X-Original-To: radext@ietfa.amsl.com
Delivered-To: radext@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 793B61A028B for <radext@ietfa.amsl.com>; Tue, 8 Jul 2014 19:07:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.851
X-Spam-Level:
X-Spam-Status: No, score=-4.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Uhn2AGaJZEqu for <radext@ietfa.amsl.com>; Tue, 8 Jul 2014 19:07:54 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 04F791A0277 for <radext@ietf.org>; Tue, 8 Jul 2014 19:07:53 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml405-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BGX83773; Wed, 09 Jul 2014 02:07:52 +0000 (GMT)
Received: from NKGEML410-HUB.china.huawei.com (10.98.56.41) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 9 Jul 2014 03:07:51 +0100
Received: from NKGEML504-MBX.china.huawei.com ([169.254.7.247]) by nkgeml410-hub.china.huawei.com ([10.98.56.41]) with mapi id 14.03.0158.001; Wed, 9 Jul 2014 10:07:48 +0800
From: Xueli <xueli@huawei.com>
To: Bernard Aboba <bernard_aboba@hotmail.com>, Alan DeKok <aland@deployingradius.com>
Thread-Topic: [radext] Gathering opinions on draft-xue-radext-key-management
Thread-Index: Ac+aU1q4YvahpQSJTAKpJucCQYvthf//fLkAgAAc9AD//gujIA==
Date: Wed, 09 Jul 2014 02:07:48 +0000
Message-ID: <01FE63842C181246BBE4CF183BD159B448FD330B@nkgeml504-mbx.china.huawei.com>
References: <01FE63842C181246BBE4CF183BD159B448FD2EA1@nkgeml504-mbx.china.huawei.com> <53BB5816.90704@deployingradius.com> <BLU406-EAS386A2680F97E72ECDE57CF2930C0@phx.gbl>
In-Reply-To: <BLU406-EAS386A2680F97E72ECDE57CF2930C0@phx.gbl>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.111.97.86]
Content-Type: multipart/alternative; boundary="_000_01FE63842C181246BBE4CF183BD159B448FD330Bnkgeml504mbxchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: http://mailarchive.ietf.org/arch/msg/radext/yE1aldxFrRh59T5ujY_l7qCy3zE
Cc: "radext@ietf.org" <radext@ietf.org>
Subject: Re: [radext] Gathering opinions on draft-xue-radext-key-management
X-BeenThere: radext@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: RADIUS EXTensions working group discussion list <radext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/radext>, <mailto:radext-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/radext/>
List-Post: <mailto:radext@ietf.org>
List-Help: <mailto:radext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/radext>, <mailto:radext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 09 Jul 2014 02:07:56 -0000

Thanks



>-----Original Message-----

>From: Bernard Aboba [mailto:bernard_aboba@hotmail.com]

>Sent: Tuesday, July 08, 2014 12:15 PM

>To: Alan DeKok

>Cc: Xueli; radext@ietf.org

>Subject: Re: [radext] Gathering opinions on

>draft-xue-radext-key-management

>

>RFC 5247 provides the Key Management model for EAP. It is standards track

>- and updates are outside the Charter of RADEXT WG.

>

>> On Jul 7, 2014, at 7:32 PM, "Alan DeKok" <aland@deployingradius.com>

>wrote:

>>

>> Xueli wrote:

>>> As you know, we presented the draft-xue-radext-key-management (new

>version http://tools.ietf.org/id/draft-xue-radext-key-management-03.txt  )

>>> Which defines the Radius extensions for key delivery between BNG and

>AC in some specific scenario.

>>

>>  I think the general consensus was that this was outside of the scope

>> of RADIUS.

>>

>>> Now the argument is that whether this item is the genuine

>Radius/RADEXT problem?

>>

>>  RADIUS is usually about end-users.  Authenticating them, authorizing

>> them, and performing accounting for them.  If you want a general

>purpose

>> "remote API" protocol, see Diameter.

>>

>>> Radius packet is proposed to resolve this issue because of following

>reasons:

>>> 1 transmit session authorization attributes

>>> (Key, which is produced during authentication and delivered by Radius

>from Server to NAS)

>>

>>  If the key is transmitted between a RADIUS client and server, then the

>> transmission can be done as part of a normal RADIUS conversation.  If

>> the key is transmitted somewhere else, then that's a *huge* security

>> problem.  And it doesn't fit the standard RADIUS model.

>>

>>> 2 unsolicited messages

>>> 3 It is not the issue of Radius, it may be the issue of EAP over Radius..

>>>

>>> At this stage, the authors appreciate your opinions very much for the

>next step of this draft.

>>> Can it be solved in RADEXT? If not, which WG could be the place?

>>

>>  I think this proposal would have a hard time finding traction anywhere

>> in the IETF.  The security problems with sharing keys are very serious.

>>

>>  Alan DeKok.

>>

>> _______________________________________________

>> radext mailing list

>> radext@ietf.org

>> https://www.ietf.org/mailman/listinfo/radext

v2.23.0 | Report a Bug | By Email