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

Xueli <xueli@huawei.com> Tue, 08 July 2014 02:21 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 001781B29EC for <radext@ietfa.amsl.com>; Mon, 7 Jul 2014 19:21:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.852
X-Spam-Level:
X-Spam-Status: No, score=-4.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 3tPGK12A-wjd for <radext@ietfa.amsl.com>; Mon, 7 Jul 2014 19:21:47 -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 29A1A1B29E9 for <radext@ietf.org>; Mon, 7 Jul 2014 19:21:47 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml404-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BGW85745; Tue, 08 Jul 2014 02:21:45 +0000 (GMT)
Received: from NKGEML406-HUB.china.huawei.com (10.98.56.37) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 8 Jul 2014 03:21:45 +0100
Received: from NKGEML504-MBX.china.huawei.com ([169.254.7.247]) by nkgeml406-hub.china.huawei.com ([10.98.56.37]) with mapi id 14.03.0158.001; Tue, 8 Jul 2014 10:21:42 +0800
From: Xueli <xueli@huawei.com>
To: "radext@ietf.org" <radext@ietf.org>
Thread-Topic: Gathering opinions on draft-xue-radext-key-management
Thread-Index: Ac+aU1q4YvahpQSJTAKpJucCQYvthQ==
Date: Tue, 8 Jul 2014 02:21:42 +0000
Message-ID: <01FE63842C181246BBE4CF183BD159B448FD2EA1@nkgeml504-mbx.china.huawei.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: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: http://mailarchive.ietf.org/arch/msg/radext/CEIbcy1F2ew8AkUMJyavZs-PRaU
Cc: Stefan Winter <stefan.winter@restena.lu>, Jouni Korhonen <jouni.nospam@gmail.com>
Subject: [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: Tue, 08 Jul 2014 02:21:49 -0000

Hello all

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.

In practice, operators prefer to deploy BNG as Authenticator while AC is as much as simple for AP management.
In this scenario, an standard approach is required to help the WTP to obtain the PMK, especially, when AC and BNG are deployed by different vendors.. 
This work tries to discuss the issues related with this topic and proposes a RADIUS extension to address the problem.
As before we discussed in the meeting, the scenario is already clear and reasonable. 

Now the argument is that whether this item is the genuine Radius/RADEXT problem? 
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)
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?

Thanks in advance

Li On co-authors' behalf