Re: [radext] FW: New Version Notification for draft-xue-radext-key-management-00.txt

Behcet Sarikaya <sarikaya2012@gmail.com> Fri, 29 March 2013 23:13 UTC

Return-Path: <sarikaya2012@gmail.com>
X-Original-To: radext@ietfa.amsl.com
Delivered-To: radext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 420C921F8ED4 for <radext@ietfa.amsl.com>; Fri, 29 Mar 2013 16:13:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.348
X-Spam-Level:
X-Spam-Status: No, score=-3.348 tagged_above=-999 required=5 tests=[AWL=0.250, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bSWosb4rpST5 for <radext@ietfa.amsl.com>; Fri, 29 Mar 2013 16:13:41 -0700 (PDT)
Received: from mail-lb0-f176.google.com (mail-lb0-f176.google.com [209.85.217.176]) by ietfa.amsl.com (Postfix) with ESMTP id 4D0DA21F859D for <radext@ietf.org>; Fri, 29 Mar 2013 16:13:41 -0700 (PDT)
Received: by mail-lb0-f176.google.com with SMTP id y8so612029lbh.7 for <radext@ietf.org>; Fri, 29 Mar 2013 16:13:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:reply-to:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=bAsMnzF9Pam0XwjbyRVGbBCNccdidH3GPyKvd8aqRXw=; b=EQMZEJ4KVGc187UrCAnnzx5SF7cyGmyQWa/xz/tI335UnBuZ+spmTov0bu7xvd45L0 XZ8IvFFv8GttUzQIZYfkStD0ArK0fNokZ75cWruV6x+CpqWRaycAw4R4a6NAGC1UA+62 rRV6j0pPzRfrm8v0N/lj1R8Z2Y2lSZPwnxEGxabGJ0Vq2ETWPz0Q/INEMGU32+1iYIa+ nhMV7MlGyeFxB7yEGLk9G+KBYqcIgFZ50kfSqiBwDgtxR1nHO4vfeeTZEJ4kBthvg3fE d4CID2KLb2A2o9fEKOJE4HCqcZeHcqz1Hqnq9t8nqsG1bwRgVOLrMLzT1cbTU3JyJHAu Yzkg==
MIME-Version: 1.0
X-Received: by 10.152.123.194 with SMTP id mc2mr1909555lab.7.1364598820106; Fri, 29 Mar 2013 16:13:40 -0700 (PDT)
Received: by 10.114.93.41 with HTTP; Fri, 29 Mar 2013 16:13:40 -0700 (PDT)
In-Reply-To: <BLU169-W85A8986E0763F33B71E88A93D30@phx.gbl>
References: <01FE63842C181246BBE4CF183BD159B4482A1371@NKGEML512-MBS.china.huawei.com> <515596D8.1000209@restena.lu> <BLU169-W85A8986E0763F33B71E88A93D30@phx.gbl>
Date: Fri, 29 Mar 2013 18:13:40 -0500
Message-ID: <CAC8QAcc05Ap+RMHC5aDsfzJx1Fd1xx=KNTwP=r_eszGUkkfWJQ@mail.gmail.com>
From: Behcet Sarikaya <sarikaya2012@gmail.com>
To: Bernard Aboba <bernard_aboba@hotmail.com>
Content-Type: multipart/alternative; boundary="f46d04426edaeef73504d9186b01"
Cc: Stefan Winter <stefan.winter@restena.lu>, "xueli@huawei.com" <xueli@huawei.com>, "radext@ietf.org" <radext@ietf.org>
Subject: Re: [radext] FW: New Version Notification for draft-xue-radext-key-management-00.txt
X-BeenThere: radext@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: sarikaya@ieee.org
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: Fri, 29 Mar 2013 23:13:42 -0000

Hi Stefan, Bernard,

This draft is not about split MAC, local MAC of CAPWAP protocol (in the
draft those are called Fit AP, Fat AP, quite strangely).

This draft is about the case where IEEE 802.11i authenticator is moved from
the AC of CAPWAP to the access router which is not at the same time the AC.

In that case the keys, e.g. PMK has to be transferred to the AC. The
solution is described in Section 5 which uses CoA type of signaling (as in
RFC3576).  This requires some RADIUS extensions

Hope this helps.

Regards,

Behcet


On Fri, Mar 29, 2013 at 4:35 PM, Bernard Aboba <bernard_aboba@hotmail.com>wrote:

> [BA] Also, RFC 5247 desribes the security issues that can arise when
> splitting the AP function.
>
> Stefan Winter said:
>
> "You attempt to split the role of the Access Point into several
> sub-entities. This is admirable, but by no means a novelty. There are
> many proprietary approaches to this, but there's also already a set of
> RFCs describing a standard way:"
>
>
> _______________________________________________
> radext mailing list
> radext@ietf.org
> https://www.ietf.org/mailman/listinfo/radext
>
>