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

Xueli <xueli@huawei.com> Wed, 09 July 2014 02:06 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 1F22B1A028E for <radext@ietfa.amsl.com>; Tue, 8 Jul 2014 19:06:27 -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 fZugeeGMnzih for <radext@ietfa.amsl.com>; Tue, 8 Jul 2014 19:06:24 -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 31DE01A0295 for <radext@ietf.org>; Tue, 8 Jul 2014 19:06:22 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml403-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BGX83718; Wed, 09 Jul 2014 02:06:20 +0000 (GMT)
Received: from NKGEML410-HUB.china.huawei.com (10.98.56.41) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 9 Jul 2014 03:06:19 +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:06:15 +0800
From: Xueli <xueli@huawei.com>
To: Alan DeKok <aland@deployingradius.com>
Thread-Topic: [radext] Gathering opinions on draft-xue-radext-key-management
Thread-Index: Ac+aU1q4YvahpQSJTAKpJucCQYvthf//fLkA//3wBSA=
Date: Wed, 9 Jul 2014 02:06:14 +0000
Message-ID: <01FE63842C181246BBE4CF183BD159B448FD32FF@nkgeml504-mbx.china.huawei.com>
References: <01FE63842C181246BBE4CF183BD159B448FD2EA1@nkgeml504-mbx.china.huawei.com> <53BB5816.90704@deployingradius.com>
In-Reply-To: <53BB5816.90704@deployingradius.com>
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_01FE63842C181246BBE4CF183BD159B448FD32FFnkgeml504mbxchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: http://mailarchive.ietf.org/arch/msg/radext/cIAbXug2IHrLv6aIapi1v0uj1qg
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:06:27 -0000

Hello Alan



Thanks for your comments.

>> 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.

>



Understand..

This scenario is the existing gap right now in WLAN network, also mentioned in other SDO.

We will think carefully this security issue.



Regards

Li



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

>From: radext [mailto:radext-bounces@ietf.org] On Behalf Of Alan DeKok

>Sent: Tuesday, July 08, 2014 10:32 AM

>To: Xueli

>Cc: radext@ietf.org

>Subject: Re: [radext] Gathering opinions on

>draft-xue-radext-key-management

>

>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