IETF Logo Mail Archive

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

Sam Hartman <hartmans@painless-security.com> Tue, 08 July 2014 12:02 UTC

Return-Path: <hartmans@painless-security.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 8B8011B2810 for <radext@ietfa.amsl.com>; Tue, 8 Jul 2014 05:02:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.551
X-Spam-Level:
X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] 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 bxeS8am0xR9E for <radext@ietfa.amsl.com>; Tue, 8 Jul 2014 05:02:20 -0700 (PDT)
Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 52EC81B2ABA for <radext@ietf.org>; Tue, 8 Jul 2014 05:02:04 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mail.painless-security.com (Postfix) with ESMTP id 9EA0E20744; Tue, 8 Jul 2014 07:58:11 -0400 (EDT)
Received: from mail.painless-security.com ([127.0.0.1]) by localhost (mail.suchdamage.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5-FQCYBZrGGc; Tue, 8 Jul 2014 07:58:11 -0400 (EDT)
Received: from carter-zimmerman.suchdamage.org (c-50-177-27-27.hsd1.ma.comcast.net [50.177.27.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.painless-security.com (Postfix) with ESMTPS; Tue, 8 Jul 2014 07:58:11 -0400 (EDT)
Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 3349581BA5; Tue, 8 Jul 2014 08:01:59 -0400 (EDT)
From: Sam Hartman <hartmans@painless-security.com>
To: Xueli <xueli@huawei.com>
References: <01FE63842C181246BBE4CF183BD159B448FD2EA1@nkgeml504-mbx.china.huawei.com>
Date: Tue, 08 Jul 2014 08:01:59 -0400
In-Reply-To: <01FE63842C181246BBE4CF183BD159B448FD2EA1@nkgeml504-mbx.china.huawei.com> (xueli@huawei.com's message of "Tue, 8 Jul 2014 02:21:42 +0000")
Message-ID: <tslvbr85aa0.fsf@mit.edu>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain
Archived-At: http://mailarchive.ietf.org/arch/msg/radext/YbMrPbeSIHEJYXDXZTK4T5oApvI
Cc: "radext@ietf.org" <radext@ietf.org>, Jouni Korhonen <jouni.nospam@gmail.com>, Stefan Winter <stefan.winter@restena.lu>
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: Tue, 08 Jul 2014 12:02:24 -0000

>>>>> "Xueli" == Xueli  <xueli@huawei.com> writes:

    Xueli> Hello all As you know, we presented the
    Xueli> draft-xue-radext-key-management (new version
    Xueli> http://tools.ietf.org/id/draft-xue-radext-key-management-03.txt
    Xueli> ) Which defines the Radius extensions for key delivery
    Xueli> between BNG and AC in some specific scenario.

    Xueli> In practice, operators prefer to deploy BNG as Authenticator
    Xueli> while AC is as much as simple for AP management.  As before
    Xueli> we discussed in the meeting,
    Xueli> the scenario is already clear and reasonable.

With respect, when I consider this scenario I find myself confused and
I'm hoping that if you decide  to continue this  work you will spend
significantly more effort clarifying the scenario and working with the
community to evaluate whether it is reasonable.

As I understand it, operators would like to deploy with a model
different than that described by RFC 5247.  We spent a long time
developing RFC 5247, working within the IETF to make sure our protocols
support it, and working within the IEEE to make sure that their
re-authentication and other protocols work within this model.

When we hear that work is wrong, we feel skeptical

Also, when I read this document I am concerned, because the security
model is different than that proposed by RFC 5247.  I do not wish to see
the security of wireless access decreased, and I'd like to understand
whether this proposed solution  does that.

I would request that you:

* Approach this as an architectural issue at the RFC 5247 level rather
  than a RADIUS issue

* Focus on clearly describing the scenario and having a discussion with
  the IETF community about whether this scenario is reasonable.

* Discuss with the IETF community about whether a solution to this
  scenario is desirable.

This is a much bigger change than one RADIUS attribute.

Thanks for your consideration,

Sam Hartman
Painless Security, LLC

v2.23.0 | Report a Bug | By Email