From diameter-admin@frascone.com Fri Oct 1 05:14:31 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA08802 for ; Fri, 1 Oct 2004 05:14:30 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id A715A2139E for ; Fri, 1 Oct 2004 05:14:14 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 2C2112257A for ; Fri, 1 Oct 2004 05:11:25 -0400 (EDT) Date: Fri, 01 Oct 2004 05:11:25 -0400 Message-ID: <20041001091125.20202.70749.Mailman@xavier> Subject: frascone.com mailing list memberships reminder From: mailman-owner@wolverine.cnri.reston.va.us To: capwap-archive@ietf.org X-No-Archive: yes X-Ack: no Sender: diameter-admin@frascone.com Errors-To: diameter-admin@frascone.com X-BeenThere: diameter@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) This is a reminder, sent out once a month, about your frascone.com mailing list memberships. It includes your subscription info and how to use it to change it or unsubscribe from a list. You can visit the URLs to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on. In addition to the URL interfaces, you can also use email to make such changes. For more info, send a message to the '-request' address of the list (for example, capwap-request@frascone.com) containing just the word 'help' in the message body, and an email message will be sent to you with instructions. If you have questions, problems, comments, etc, send them to mailman-owner@wolverine. Thanks! Passwords for capwap-archive@lists.ietf.org: List Password // URL ---- -------- capwap@frascone.com xakour http://mail.frascone.com/mailman/options/capwap/capwap-archive%40lists.ietf.org From capwap-admin@frascone.com Fri Oct 8 12:23:06 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08445 for ; Fri, 8 Oct 2004 12:23:05 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 23FAB22A78; Fri, 8 Oct 2004 12:23:06 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id E49AB22148; Fri, 8 Oct 2004 12:23:02 -0400 (EDT) Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id E14CC22A71 for ; Fri, 8 Oct 2004 12:22:39 -0400 (EDT) Received: from tiere.net.avaya.com (tiere.net.avaya.com [198.152.12.100]) by mail.frascone.com (Postfix) with ESMTP id C4DDD22148 for ; Fri, 8 Oct 2004 12:22:37 -0400 (EDT) Received: from tiere.net.avaya.com (localhost [127.0.0.1]) by tiere.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id i98GKpZp022790 for ; Fri, 8 Oct 2004 12:20:52 -0400 (EDT) Received: from cof110avexu1.global.avaya.com (h135-9-6-16.avaya.com [135.9.6.16]) by tiere.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id i98GJkZp021649 for ; Fri, 8 Oct 2004 12:20:07 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message-ID: Thread-Topic: Refined recharter proposal. Thread-Index: AcStUtY8wlapwDseTd2h5/mgIKdQWw== From: "Mani, Mahalingam (Mahalingam)" To: X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [Capwap] Refined recharter proposal. Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Fri, 8 Oct 2004 10:21:20 -0600 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: quoted-printable The following recharter proposal is sent to IESG. It has included considerations discussed in the IETF60 meeting and in the WG list - hopefully. Comments are welcome. -Mani, Dorothy =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =3D=3D The original CAPWAP WG charter included drafting a problem statement and a taxonomy of architectures. The new charter of the CAPWAP WG proposes building upon the original charter and developing a CAPWAP protocol to provide interoperability among WLAN backend architectures. The intent of the CAPWAP protocol is to facilitate control, management and provisioning of WLAN Termination Points (WTPs) specifying the services, functions and resources relating to 802.11 WLAN Termination Points in order to allow for interoperable implementations of WTPs and ACs. The revised CAPWAP WG will reference two classes of the Centralized WLAN Architecture family, namely the Local MAC and the Split MAC, as described in the CAPWAP Architecture Taxonomy draft. The protocol will define the CAPWAP control plane including the primitives to control data access. An effective Centralized CAPWAP Architecture impacts how WLAN data traffic is managed over the backend network. This implies the abiltiy to control how data is forwarded by negotiating exisitng data encapsulation mechanisms and specifing data payload formats in order to ensure intoperability between CAPWAP vendors. No other specifications of the CAPWAP data plane are within the scope of this charter. The CAPWAP WG will strive for extensibility in the protocol design to favor future applicability to other access technologies. However, this is not a requirement. The charter's focus is to address the WLAN architectures based on the IEEE 802.11 Standard. In summary, the primary goals of the group will be: 1. Defining a set of Objectives based on the architecture taxonomy work that lists the requirements for an interoperable CAPWAP protocol. In addition, the WG will incorporate requirements derived from the inputs provided by Enterprise and (hotspot) Providers based on the WLAN deployment challenges addressed by CAPWAP architecture. This document will: a. include objectives to address problems described in the CAPWAP Problem statement work b. Describe each objective, its benefit to the protocol and how it satisfies the problem statement. c. Prioritize and classify the objectives into 3 categories: i. Mandatory and Accepted ii. Desirable iii. Rejected d. Undergo review in IEEE as needed This should result in the first WG last call for Objectives draft. To avoid requirements bloat and stalemate, the WG has an imposed hard deadline on the Objectives phase. The WG MUST reach WG consensus on the objectives draft by Feb 2005. This is for several reasons: * We must send this for review to IEEE at that time. * We must have a reasonably stable set of objectives so that candidate submissions are aware of the objectives to be met. The 2nd WG Last Call (in April) for the objectives draft is to ensure that the WG has consensus on any changes that may result from IEEE and expert review. So it is not the intention that the WG keeps adding new Objectives after Feb 2005. If the WG cannot reach concensus on the Objectives draft by the May 05 milestone to the IESG, the WG will close. 2. Evaluating a set of candidate proposals that include existing IETF protocols and any proposals leading to the selection of a protocol on which to base the CAPWAP standard. 3. Developing a CAPWAP protocol standard that meets the Mandatory and Accepted objectives from the Evaluation draft and contains the minimal set of feature needed to control and provision WLAN Access Points. Specifically The CAPWAP protocol document will address the following considerations: a. Architecture b. Operations c. Security d. Network Management e. Scalability f. Performance 4. A MIB Document to support the CAPWAP protocol. In addition, the CAPWAP WG will maintain its Liaison with the IEEE to ensure consistency of its work with the IEEE 802.11 Standard. Deliverables: * Objectives/Criteria Document for CAPWAP protocol * Protocol evaluation and base protocol selection document * CAPWAP Protocol standard * MIB support standard Goals and Milestones: Nov 04: Issue first Internet-Draft of CAPWAP Objectives document Feb 05: First WGLC for CAPWAP Objectives Draft Feb 05: Submit CAPWAP Objectives to IEEE/IETF experts review Mar 05: Deadline to submit candidate protocol proposals to the WG Apr 05: Second WGLC for CAPWAP Objectives Draft May 05: Submit CAPWAP Objectives draft to IESG as Informational RFC May 05: Shutdown WG if CAPWAP Objectives have not finalized, otherwise continue with next milestones. Jun 05: Issue first Internet-Draft of CAPWAP Evaluation draft Aug 05: WGLC for CAPWAP Evaluation draft Sep 05: Submit CAPWAP Evaluation draft to IESG as Information RFC Oct 05: Issue first Internet Draft of CAPWAP protocol Nov 05: Issue first Internet-Draft of CAPWAP MIB. Dec 05: WGLC for CAPWAP protocol Jan 06: Submit CAPWAP protocol to IESG as Proposed Standard RFC Jan 06: WGLC for CAPWAP MIB Mar 06: Submit CAPWAP MIB to IESG as Proposed Standard RFC _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Tue Oct 19 09:47:07 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25736 for ; Tue, 19 Oct 2004 09:47:06 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 866561FC0E; Tue, 19 Oct 2004 09:47:06 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id B3EE31FC10; Tue, 19 Oct 2004 09:47:02 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 1D7701FC10 for ; Tue, 19 Oct 2004 09:46:53 -0400 (EDT) Received: from tiere.net.avaya.com (tiere.net.avaya.com [198.152.12.100]) by mail.frascone.com (Postfix) with ESMTP id 65A3E1FC0E for ; Tue, 19 Oct 2004 09:46:50 -0400 (EDT) Received: from tiere.net.avaya.com (localhost [127.0.0.1]) by tiere.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id i9JDj2Zp016057 for ; Tue, 19 Oct 2004 09:45:02 -0400 (EDT) Received: from cof110avexu1.global.avaya.com (h135-9-6-16.avaya.com [135.9.6.16]) by tiere.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id i9JDhHZp014000 for ; Tue, 19 Oct 2004 09:43:56 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C4B5E1.D41930CA" Message-ID: Thread-Topic: A draft on Objectives. Thread-Index: AcS14dBcS86W7fWpRsGYieswb4xFQg== X-Priority: 1 Priority: Urgent Importance: high From: "Mani, Mahalingam (Mahalingam)" To: X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [Capwap] A draft on Objectives. Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Tue, 19 Oct 2004 07:45:00 -0600 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) This is a multi-part message in MIME format. ------_=_NextPart_001_01C4B5E1.D41930CA Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Saravanan Govindan has submitted a draft in response to a call for Objectives (in connection with the recharter discussions in ietf60 @San Diego and on the list). =20 I have had it placed in the capwap website: http://www.capwap.org/draft-govindan-capwap-objectives-00.txt =20 Note that with this being out of scope for this phase of WG (and this phase having drawn/drawing=20 to a close) this is a courtesy posting to facilitate discussions. =20 [It arrived too late for submission as an individual -00 I-D to IETF repository]. =20 Feel free to review & comment. =20 -mani =20 ------_=_NextPart_001_01C4B5E1.D41930CA Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Saravanan Govindan has submitted a draft in response = to a call for Objectives (in connection with

the recharter discussions in ietf60 @San Diego and on = the list).

 

I have had it placed in the capwap = website:

ht= tp://www.capwap.org/draft-govindan-capwap-objectives-00.txt

 

Note that with this being out of scope for this phase = of WG (and this phase having drawn/drawing

to a close) this is a courtesy posting to facilitate discussions.

 

[It arrived too late for submission as an individual = -00 I-D to IETF repository].

 

Feel free to review & = comment.

 

-mani

 

------_=_NextPart_001_01C4B5E1.D41930CA-- _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Wed Oct 20 14:41:17 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08255 for ; Wed, 20 Oct 2004 14:41:17 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 403261FCC0; Wed, 20 Oct 2004 14:41:06 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id D96171FCB4; Wed, 20 Oct 2004 14:41:02 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 818091FCB4 for ; Wed, 20 Oct 2004 14:40:55 -0400 (EDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by mail.frascone.com (Postfix) with ESMTP id 7C9211FC67 for ; Wed, 20 Oct 2004 14:40:53 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08212; Wed, 20 Oct 2004 14:40:46 -0400 (EDT) Message-Id: <200410201840.OAA08212@ietf.org> From: The IESG To: IETF-Announce@ietf.org Cc: capwap@frascone.com, Mahalingam Mani , Dorothy Gellert Reply-To: iesg@ietf.org X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [Capwap] WG Review: Recharter of Control and Provisioning of Wireless Access Points (capwap) Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Wed, 20 Oct 2004 14:40:46 -0400 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) A modified charter has been submitted for the Control and Provisioning of Wireless Access Points (capwap) working group in the Operations and Management Area of the IETF. The IESG has not made any determination as yet. The following description was submitted, and is provided for informational purposes only. Please send your comments to the IESG mailing list (iesg@ietf.org) by October 27th. Control and Provisioning of Wireless Access Points (capwap) ----------------------------------------------------------- Current Status: Active Working Group Description: The original CAPWAP WG charter included drafting a problem statement and a taxonomy of architectures. The new charter of the CAPWAP WG proposes building upon the original charter and developing a CAPWAP protocol to provide interoperability among WLAN backend architectures. The intent of the CAPWAP protocol is to facilitate control, management and provisioning of WLAN Termination Points (WTPs) specifying the services, functions and resources relating to 802.11 WLAN Termination Points in order to allow for interoperable implementations of WTPs and ACs. The revised CAPWAP WG will reference two classes of the Centralized WLAN Architecture family, namely the Local MAC and the Split MAC, as described in the CAPWAP Architecture Taxonomy draft. The protocol will define the CAPWAP control plane including the primitives to control data access. An effective Centralized CAPWAP Architecture impacts how WLAN data traffic is managed over the backend network. This implies the abilitiy to control how data is forwarded by negotiating existng data encapsulation mechanisms and specifying data payload formats in order to ensure interoperability between CAPWAP vendors. No other specifications of the CAPWAP data plane are within the scope of this charter. The CAPWAP WG will strive for extensibility in the protocol design to favor future applicability to other access technologies, especially IEEE 802.16. While accommodation of any access technology other than IEEE 802.11 is not required for successful completion, there are clear deployment advantages if a wide range of access technologies are accommodated. In summary, the primary goals of the group will be: 1. Defining a set of Objectives based on the architecture taxonomy work that lists the requirements for an interoperable CAPWAP protocol. In addition, the WG will incorporate requirements derived from the inputs provided by Enterprise and (hotspot) Providers based on the WLAN deployment challenges addressed by CAPWAP architecture. This document will: a. include objectives to address problems described in the CAPWAP Problem statement document b. Describe each objective, its benefit to the protocol and how it satisfies the problem statement. c. Prioritize and classify the objectives into 3 categories: i. Mandatory and Accepted ii. Desirable iii. Rejected d. Undergo review in IEEE 802 as needed This should result in the first WG Last Call for Objectives draft. To avoid requirements bloat and stalemate, the WG has a hard deadline on the Objectives phase. The WG MUST reach WG consensus on the objectives draft by Feb 2005. This is for several reasons: * We must send this for review to IEEE at that time. * We must have a reasonably stable set of objectives so that candidate submissions are aware of the objectives to be met. The 2nd WG Last Call (in April) for the objectives draft is to ensure that the WG has consensus on any changes that may result from IEEE and expert review. So it is not the intention that the WG keeps adding new Objectives after Feb 2005. If the WG cannot reach consensus on the Objectives draft by the May 2005 milestone to the IESG, the WG will close. 2. Evaluating a set of candidate proposals that include existing IETF protocols and any proposals leading to the selection of a protocol on which to base the CAPWAP standard. 3. Developing a CAPWAP protocol standard that meets the Mandatory and Accepted objectives from the Evaluation draft and contains the minimal set of feature needed to control and provision WLAN Access Points. Specifically The CAPWAP protocol document will address the following considerations: a. Architecture b. Operations c. Security d. Network Management e. Scalability f. Performance 4. A MIB Document to support the CAPWAP protocol. In addition, the CAPWAP WG will maintain its Liaison with the IEEE to ensure consistency of its work with the IEEE 802.11 Standard. Deliverables: * Objectives/Criteria Document for CAPWAP protocol * Protocol evaluation and base protocol selection document * CAPWAP Protocol standard * MIB support standard _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Wed Oct 20 19:02:06 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA10332 for ; Wed, 20 Oct 2004 19:02:05 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 4F67C1FC67; Wed, 20 Oct 2004 19:02:06 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 9D75F1FCB7; Wed, 20 Oct 2004 19:02:02 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 0CB4C1FC67 for ; Wed, 20 Oct 2004 19:01:22 -0400 (EDT) Received: from orsfmr001.jf.intel.com (fmr12.intel.com [134.134.136.15]) by mail.frascone.com (Postfix) with ESMTP id 3106F1FCB7 for ; Wed, 20 Oct 2004 19:01:19 -0400 (EDT) Received: from petasus.jf.intel.com (petasus.jf.intel.com [10.7.209.6]) by orsfmr001.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-outer.mc,v 1.15 2004/01/30 18:16:28 root Exp $) with ESMTP id i9KN1tUX029291 for ; Wed, 20 Oct 2004 23:01:55 GMT Received: from orsmsxvs041.jf.intel.com (orsmsxvs041.jf.intel.com [192.168.65.54]) by petasus.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.11 2004/07/29 22:51:53 root Exp $) with SMTP id i9KN3tUn007419 for ; Wed, 20 Oct 2004 23:04:55 GMT Received: from orsmsx332.amr.corp.intel.com ([192.168.65.60]) by orsmsxvs041.jf.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004102016011804024 for ; Wed, 20 Oct 2004 16:01:18 -0700 Received: from orsmsx408.amr.corp.intel.com ([192.168.65.52]) by orsmsx332.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 20 Oct 2004 16:01:18 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C4B6F8.B4EFE588" Message-ID: <2AF68A477DD44C4EBCBE338C24E7A9EE018370CA@orsmsx408> Thread-Topic: Important: please provide input on comment resolution for CAPWAP Taxonomy draft Thread-Index: AcS2+LTpfFYIsmvtQNec7tpGPzBYXQ== From: "Yang, Lily L" To: X-OriginalArrivalTime: 20 Oct 2004 23:01:18.0268 (UTC) FILETIME=[B546D7C0:01C4B6F8] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [Capwap] Important: please provide input on comment resolution for CAPWAP Taxonomy draft Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Wed, 20 Oct 2004 16:01:17 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) This is a multi-part message in MIME format. ------_=_NextPart_001_01C4B6F8.B4EFE588 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Inderpreet sent this out to the list earlier but it has not shown up yet, so I am trying to resend here. Please provide input ASAP as we want to resolve this so we can submit v06 by Monday morning. Thanks! Lily ----------the following is from Inderpreet ----- Hi all, We have received the following comment on the security section of v05 --------------------begin Russ's comment:-------------------------=20 Section 4.8.1 says: : : If the PMK (Pairwise Master Key) is reused across multiple : WTPs, then requiring a 4-way handshake for each WTP that the station : associates to, followed by the transfer of that PTK from the AC to : the WTP, would ensure that a different PTK is used at each WTP. : I believe that each WTP has its own MAC address. So, each WTP looks like a full-blown AP to the STA. The STA is sheltered from the WTP/AC separation, and it cannot tell that PMK is not being reused across truly different APs. To the STA, the share PMK looks like a compromised PMK. In order for the PMK to be shared, there needs some way for the STA to securely learn the MAC addresses of the different WTPs that are legitimately sharing the PMK.=20 ------------------------end of Russ's comment ---------------------=20 In response I wanted to make the following clarifications and solicit input on how to resolve this paragraph. I understand there to be three different kinds of implementations: 1. 802.11i is fully implemented in the AC 2. 802.11i is distributed between AC and WTP a. WTP is solely involved in the 4 way handshake and generation of PTK (EAPoL messages are "proxied" to the RADIUS server via the AC). The PMK is unique per WTP. b. AC is involved in the 4 way handshake and the generation of the PTK. EAP state machine is terminated on the AC, and AC is involved in PMK is the same for all WTPs. This is where I think Russ is questioning the security and or feasibility of this implementation given the current 802.11i standard's requirement for unique MAC per=20 In my opinion - #1 and #2a is what was intended in this section. #2b is problematic because of the non-uniqueness of the WTP's MAC addresses and I don't recall which vendor has that kind of implementation? Thanks, looking forward to people's input on this. There are other comments that I think Lily has taken care of. --- Inderpreet Singh Chantry Networks isingh@chantrynetworks.com Cell: 416-831-3705 ------_=_NextPart_001_01C4B6F8.B4EFE588 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Important: please provide input on comment resolution for CAPWAP = Taxonomy draft

Inderpreet sent this = out to the list earlier but it has not shown up yet, so I am trying to = resend here.
Please provide input = ASAP as we want to resolve this so we can submit v06 by Monday morning. = Thanks!
Lily
----------the = following is from Inderpreet -----

Hi all,
We have received the = following comment on the security section of v05
--------------------begin Russ's = comment:-------------------------
Section 4.8.1 says:
:
: If the PMK (Pairwise Master Key) is reused across multiple
: WTPs, then requiring a 4-way handshake for each WTP that the = station
: associates to, followed by the transfer of that PTK from the AC to
: the WTP, would ensure that a different PTK is used at each WTP.
:
I believe that each WTP has its own MAC address. So, each WTP looks
like a full-blown AP to the STA. The STA is sheltered from the = WTP/AC
separation, and it cannot tell that PMK is not being reused across
truly different APs. To the STA, the share PMK looks like a
compromised PMK.

In order for the PMK to be shared, there needs some way for the STA = to
securely learn the MAC addresses of the different WTPs that are
legitimately sharing the PMK.
------------------------end of = Russ's comment ---------------------
In response I wanted = to make the following clarifications and solicit input on how to resolve = this paragraph.
I understand there = to be three different kinds of implementations:
1. 802.11i is fully implemented = in the AC
2. 802.11i is distributed between = AC and WTP
a. WTP is solely involved in the = 4 way handshake and generation of PTK (EAPoL messages are = “proxied” to the RADIUS server via the AC). The PMK is = unique per WTP.

b. AC is involved in the 4 way = handshake and the generation of the PTK. EAP state machine is terminated = on the AC, and AC is involved in PMK is the same for all WTPs. This is = where I think Russ is questioning the security and or feasibility of = this implementation given the current 802.11i standard’s = requirement for unique MAC per

In my opinion - #1 = and #2a is what was intended in this section. #2b is problematic because = of the non-uniqueness of the WTP’s MAC addresses and I don’t = recall which vendor has that kind of implementation?

Thanks, looking = forward to people’s input on this. There are other comments that I = think Lily has taken care of.
---
Inderpreet = Singh
Chantry = Networks
isingh@chantrynetworks.com
Cell: = 416-831-3705

------_=_NextPart_001_01C4B6F8.B4EFE588-- _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Wed Oct 20 19:11:11 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA13042 for ; Wed, 20 Oct 2004 19:11:07 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 8FF871FCC1; Wed, 20 Oct 2004 19:11:08 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id AC8681FC67; Wed, 20 Oct 2004 19:11:04 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 25B991FC64 for ; Tue, 19 Oct 2004 17:15:11 -0400 (EDT) Received: from orsfmr001.jf.intel.com (fmr12.intel.com [134.134.136.15]) by mail.frascone.com (Postfix) with ESMTP id E81A51FC0E for ; Tue, 19 Oct 2004 17:15:08 -0400 (EDT) Received: from talaria.jf.intel.com (talaria.jf.intel.com [10.7.209.7]) by orsfmr001.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-outer.mc,v 1.15 2004/01/30 18:16:28 root Exp $) with ESMTP id i9IH6IL6017403; Mon, 18 Oct 2004 17:06:18 GMT Received: from orsmsxvs041.jf.intel.com (orsmsxvs041.jf.intel.com [192.168.65.54]) by talaria.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.11 2004/07/29 22:51:53 root Exp $) with SMTP id i9IGxP74010192; Mon, 18 Oct 2004 16:59:35 GMT Received: from orsmsx331.amr.corp.intel.com ([192.168.65.56]) by orsmsxvs041.jf.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004101810052729462 ; Mon, 18 Oct 2004 10:05:27 -0700 Received: from orsmsx408.amr.corp.intel.com ([192.168.65.52]) by orsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.0); Mon, 18 Oct 2004 10:05:26 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C4B534.A8A0A249" Message-ID: <2AF68A477DD44C4EBCBE338C24E7A9EE026EBA19@orsmsx408> X-MS-Has-Attach: yes Thread-Topic: submission Thread-Index: AcS1M7nnvLuq7q0TS8ykN4rNkSZI9QAAL6vA From: "Yang, Lily L" To: Cc: , "Dang Meimei" , "Li, Guojing" , , , "Zou, Ning" , "Zhonghui Yao" , X-OriginalArrivalTime: 18 Oct 2004 17:05:26.0945 (UTC) FILETIME=[AA120110:01C4B534] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [Capwap] RE: submission Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Mon, 18 Oct 2004 10:05:24 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) This is a multi-part message in MIME format. ------_=_NextPart_001_01C4B534.A8A0A249 Content-Type: multipart/alternative; boundary="----_=_NextPart_002_01C4B534.A8A0A249" ------_=_NextPart_002_01C4B534.A8A0A249 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Oops ... I forgot the attachment last time. Here it is. =20 ________________________________ From: Yang, Lily L=20 Sent: Monday, October 18, 2004 9:59 AM To: 'Internet-Drafts@ietf.org' Cc: capwap@frascone.com; Dang Meimei; Li, Guojing; huangyuhong@chinamobile.com; lilianyuan@chinamobile.com; Zou, Ning; Zhonghui Yao; wang.dong@zte.com.cn Subject: submission =20 Hi,=20 =20 We have a joint submission for CAPWAP Objectives document. Due to some technical difficulties, we are 4 hours behind the cut-off deadline for v00 documents. But we hope you will still accept it into the repository. We would also like the CAPWAP WG to review and provide comments. =20 Thanks, Lily =20 ------_=_NextPart_002_01C4B534.A8A0A249 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Oops … I = forgot the attachment last time.

Here it = is.

 <= /span>

From: Yang, Lily L
Sent: Monday, October 18, = 2004 9:59 AM
To: 'Internet-Drafts@ietf.org'
Cc: capwap@frascone.com; = Dang Meimei; Li, Guojing; huangyuhong@chinamobile.com; lilianyuan@chinamobile.com; Zou, Ning; Zhonghui Yao; wang.dong@zte.com.cn
Subject: = submission

 

Hi,

 

We have a joint submission for CAPWAP Objectives document. Due to some = technical difficulties, we are 4 hours behind the cut-off deadline for v00 = documents. But we hope you will still accept it into the repository. We would also like = the CAPWAP WG to review and provide comments.

 

Thanks,

Lily=

 

------_=_NextPart_002_01C4B534.A8A0A249-- ------_=_NextPart_001_01C4B534.A8A0A249 Content-Type: text/plain; name="draft-zhou-capwap-objectives-00.txt" Content-Transfer-Encoding: base64 Content-Description: draft-zhou-capwap-objectives-00.txt Content-Disposition: attachment; filename="draft-zhou-capwap-objectives-00.txt" Content-Transfer-Encoding: base64 DQoNCkNBUFdBUCBXb3JraW5nIEdyb3VwICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICBXZW5odWkgWmhvdQ0KSW50ZXJuZXQgRHJhZnQgICAgICAgICAgICAgICAgICAgIENo aW5hIE1vYmlsZSBDb21tdW5pY2F0aW9uIENvcnBvcmF0aW9uICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgWmhvbmdodWkgWWFvDQpEb2N1bWVu dDogT2JqZWN0aXZlcyBmb3IgQ29udHJvbCBhbmQgICAgICAgICAgICAgICAgIEh1YXdlaSBUZWNo bm9sb2dpZXMNClByb3Zpc2lvbmluZyBvZiBXaXJlbGVzcyBBY2Nlc3MgUG9pbnRzICAgICAgICAg ICAgICAgICAgICAgICAgIExpbHkgWWFuZw0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIEludGVsIENvcnBvcmF0aW9uDQogICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgTWVpbWVpIERh bmcNCiAgICAgICAgCQkgICAgIFRyYW5zbWlzc2lvbiBhbmQgQWNjZXNzIFJlc2VhcmNoIERlcGFy dG1lbnQNCgkJCQkJCQkgICAgICAgRG9uZyBXYW5nDQoJCQkJCQkJCSAgWlRFICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg CQkJCQkJCSAgICBaVEUNCkV4cGlyZXM6IE1hcmNoIDIwMDUgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIE9jdG9iZXIgMjAwNA0KDQogICAgIE9iamVjdGl2ZXMgZm9yIENv bnRyb2wgYW5kIFByb3Zpc2lvbmluZyBvZiBXaXJlbGVzcyBBY2Nlc3MgUG9pbnRzIA0KICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAoQ0FQV0FQKSBQcm90b2NvbA0KICAgICAgICAgICAgICAg ICAgICBkcmFmdC16aG91LWNhcHdhcC1vYmplY3RpdmVzLTAwLnR4dCANCg0KQWJzdHJhY3QNCg0K ICAgVGhpcyBkb2N1bWVudCBwcmVzZW50cyBhIHNldCBvZiBvYmplY3RpdmVzIG9yIHJlcXVpcmVt ZW50cyBmb3IgdGhlIA0KICAgQ29udHJvbCBhbmQgUHJvdmlzaW9uaW5nIG9mIFdpcmVsZXNzIEFj Y2VzcyBQb2ludHMgKENBUFdBUCkgcHJvdG9jb2wuIA0KICAgSXQgcHJlc2VudHMgdGhlIHJlcXVp cmVtZW50cyBmcm9tIGRpZmZlcmVudCBhc3BlY3RzIGluY2x1ZGluZyANCiAgIGFyY2hpdGVjdHVy ZSwgdXNlciAoY2xpZW50KSBhY2Nlc3MsIHNlcnZpY2UsIGNvbnRyb2wsIG1hbmFnZW1lbnQgYW5k IA0KICAgc2VjdXJpdHkuDQoNCg0KMS4gIERlZmluaXRpb25zDQoNCjEuMSAgQ29udmVudGlvbnMg dXNlZCBpbiB0aGlzIGRvY3VtZW50DQoNCiAgIFRoZSBrZXkgd29yZHMgIk1VU1QiLCAiTVVTVCBO T1QiLCAiUkVRVUlSRUQiLCAiU0hBTEwiLCAiU0hBTEwgTk9UIiwgDQogICAiU0hPVUxEIiwgIlNI T1VMRCBOT1QiLCAiUkVDT01NRU5ERUQiLCAgIk1BWSIsIGFuZCAiT1BUSU9OQUwiIGluIHRoaXMg DQogICBkb2N1bWVudCBhcmUgdG8gYmUgaW50ZXJwcmV0ZWQgYXMgZGVzY3JpYmVkIGluIFJGQy0y MTE5IFsgXS4NCg0KMS4yICBUZXJtaW5vbG9neSBVc2VkIGluIHRoaXMgRG9jdW1lbnQNCg0KICAg Q0FQV0FQIC0gQ29udHJvbCBhbmQgUHJvdmlzaW9uaW5nIG9mIFdpcmVsZXNzIEFjY2VzcyBQb2lu dHMuDQoNCiAgIENBUFdBUCBGdW5jdGlvbnMgLSBhIHNldCBvZiBXTEFOIGNvbnRyb2wgZnVuY3Rp b25zIHRoYXQgYXJlIG5vdCANCiAgIGRpcmVjdGx5IGRlZmluZWQgYnkgSUVFRSA4MDIuMTEgU3Rh bmRhcmRzLCBidXQgZGVlbWVkIGVzc2VudGlhbCANCiAgIGZvciBlZmZlY3RpdmUgY29udHJvbCwg Y29uZmlndXJhdGlvbiBhbmQgbWFuYWdlbWVudCBvZiA4MDIuMTEgV0xBTiANCiAgIGFjY2VzcyBu ZXR3b3Jrcy4NCg0KICAgV2lyZWxlc3MgVGVybWluYXRpb24gUG9pbnQgKFdUUCkgLSAgdGhlIHBo eXNpY2FsIG9yIG5ldHdvcmsgZW50aXR5IA0KICAgdGhhdCBjb250YWlucyBSRiBhbnRlbm5hIGFu ZCA4MDIuMTEgUEhZIHRvIHRyYW5zbWl0IGFuZCByZWNlaXZlIA0KICAgc3RhdGlvbiB0cmFmZmlj cyBmb3IgdGhlIElFRUUgODAyLjExIFdMQU4gYWNjZXNzIG5ldHdvcmtzLiAgU3VjaCANCiAgIHBo eXNpY2FsIGVudGl0aWVzIGFyZSBvZnRlbiBjYWxsZWQgIkFjY2VzcyBQb2ludHMiIChBUCkgcHJl dmlvdXNseSwgDQogICBidXQgIkFQIiBjYW4gYWxzbyBiZSB1c2VkIHRvIHJlZmVyIHRvIGxvZ2lj YWwgZW50aXR5IHRoYXQgDQogICBpbXBsZW1lbnRzIDgwMi4xMXNlcnZpY2VzLiBTbyB3ZSByZWNv bW1lbmQgdXNpbmcgIldUUCIgaW5zdGVhZCB0byANCiAgIGV4cGxpY2l0bHkgcmVmZXIgdG8gdGhl IHBoeXNpY2FsIGVudGl0eS4NCg0KDQpXZW5odWkgWmhvdSAgICAgICAgICAgICAgRXhwaXJlcyAt IE1hcmNoIDIwMDUgICAgICAgICAgICAgICAgICAgW1BhZ2UgMV0NCgwNCkludGVybmV0LURyYWZ0 ICAgICAgIENBUFdBUCBQcm90b2NvbCBPYmplY3RpdmVzICAgICAgICAgICAgIE9jdG9iZXIgMjAw NA0KDQogICBDZW50cmFsaXplZCBXTEFOIEFyY2hpdGVjdHVyZSAtIHRoZSBXTEFOIGFjY2VzcyBu ZXR3b3JrIA0KICAgYXJjaGl0ZWN0dXJlIGZhbWlseSBpbiB3aGljaCB0aGUgbG9naWNhbCBmdW5j dGlvbnMsIGluY2x1ZGluZyBib3RoIA0KICAgSUVFRSA4MDIuMTEgYW5kIENBUFdBUCBmdW5jdGlv bnMgKHdoZXJldmVyIGFwcGxpY2FibGUpLCBhcmUgDQogICBpbXBsZW1lbnRlZCBhY3Jvc3MgYSBo aWVyYXJjaHkgb2YgbmV0d29yayBlbnRpdGllcy4gIEF0IHRoZSBsb3cgDQogICBsZXZlbCBvZiBz dWNoIGhpZXJhcmNoeSBhcmUgdGhlIFdUUHMgd2hpbGUgYXQgdGhlIGhpZ2hlciBsZXZlbCBhcmUg DQogICB0aGUgQWNjZXNzIENvbnRyb2xsZXJzKEFDcyksIHdoaWNoIGFyZSByZXNwb25zaWJsZSB0 byBjb250cm9sLCANCiAgIGNvbmZpZ3VyZSBhbmQgbWFuYWdlIHRoZSBlbnRpcmUgV0xBTiBhY2Nl c3MgbmV0d29ya3MuDQoNCiAgIEFjY2VzcyBDb250cm9sbGVyIChBQykgLSBUaGUgbmV0d29yayBl bnRpdHkgaW4gdGhlIENlbnRyYWxpemVkIFdMQU4gDQogICBhcmNoaXRlY3R1cmVzIHRoYXQgcHJv dmlkZSBXVFBzIGFjY2VzcyB0byB0aGUgY2VudHJhbGl6ZWQgDQogICBoaWVyYXJjaGljYWwgbmV0 d29yayBpbmZyYXN0cnVjdHVyZSwgZWl0aGVyIGluIHRoZSBkYXRhIHBsYW5lLCANCiAgIGNvbnRy b2wgcGxhbmUsIG9yIG1hbmFnZW1lbnQgcGxhbmUsIG9yIGEgY29tYmluYXRpb24gdGhlcmVpbi4N Cg0KICAgTG9jYWwgTUFDIEFyY2hpdGVjdHVyZSAtIEEgc3ViLWdyb3VwIG9mIHRoZSBDZW50cmFs aXplZCBXTEFOIA0KICAgQXJjaGl0ZWN0dXJlLCB3aGVyZSB0aGUgbWFqb3JpdHkgb3IgZW50aXJl IHNldCBvZiA4MDIuMTEgTUFDIA0KICAgZnVuY3Rpb25zIChpbmNsdWRpbmcgbW9zdCBvZiB0aGUg ODAyLjExIG1hbmFnZW1lbnQgZnJhbWUgDQogICBwcm9jZXNzaW5nKSBhcmUgaW1wbGVtZW50ZWQg YXQgdGhlIFdUUC4gVGhlcmVmb3JlLCB0aGUgODAyLjExIE1BQyANCiAgIHN0YXlzIGludGFjdCBh bmQgbG9jYWwgaW4gdGhlIFdUUCwgYWxvbmcgd2l0aCBQSFkuDQoNCiAgIFNwbGl0IE1BQyBBcmNo aXRlY3R1cmUgLSBBIHN1Yi1ncm91cCBvZiB0aGUgQ2VudHJhbGl6ZWQgV0xBTiANCiAgIEFyY2hp dGVjdHVyZSwgd2l0aCB0aGUgY2hhcmFjdGVyaXN0aWMgdGhhdCBXVFBzIGluIHN1Y2ggV0xBTiAN CiAgIGFjY2VzcyBuZXR3b3JrcyBvbmx5IGltcGxlbWVudCB0aGUgZGVsYXkgc2Vuc2l0aXZlIE1B QyBzZXJ2aWNlcyAgDQogICAoaW5jbHVkaW5nIGFsbCBjb250cm9sIGZyYW1lcyBhbmQgc29tZSBt YW5hZ2VtZW50IGZyYW1lcykgZm9yIElFRUUgDQogICA4MDIuMTEsIHdoaWxlIHR1bm5lbGluZyBh bGwgdGhlIHJlbWFpbmluZyBtYW5hZ2VtZW50IGFuZCBkYXRhIA0KICAgZnJhbWVzIHRvIEFDIGZv ciBjZW50cmFsaXplZCBwcm9jZXNzaW5nLlRoZSBJRUVFIDgwMi4xMSBNQUMgYXMgDQogICBkZWZp bmVkIGJ5IElFRUUgODAyLjExIFN0YW5kYXJkcyBpcyBlZmZlY3RpdmVseSBzcGxpdCBiZXR3ZWVu IHRoZSANCiAgIFdUUCBhbmQgQUMuDQoNCg0KMi4gIEludHJvZHVjdGlvbg0KDQogICBBcyBJRUVF IDgwMi4xMSBXaXJlbGVzcyBMQU4gKFdMQU4pIHRlY2hub2xvZ3kgbWF0dXJlcywgbGFyZ2Ugc2Nh bGUgDQogICBkZXBsb3ltZW50IG9mIFdMQU4gbmV0d29ya3MgaXMgaGlnaGxpZ2h0aW5nIGNlcnRh aW4gdGVjaG5pY2FsIA0KICAgY2hhbGxlbmdlcyBpbmNsdWRpbmcgbWFuYWdlbWVudCwgbW9uaXRv cmluZyBhbmQgY29udHJvbCBvZiBsYXJnZSANCiAgIG51bWJlciBvZiBBY2Nlc3MgUG9pbnRzIChB UHMpLiBEaXN0cmlidXRpbmcgYW5kIG1haW50YWluaW5nIGEgDQogICBjb25zaXN0ZW50IGNvbmZp Z3VyYXRpb24gdGhyb3VnaG91dCB0aGUgZW50aXJlIHNldCBvZiBBUHMgaW4gdGhlIFdMQU4gDQog ICBpcyBhIGRpZmZpY3VsdCB0YXNrLiAgVGhlIHNoYXJlZCBhbmQgZHluYW1pYyBuYXR1cmUgb2Yg dGhlIHdpcmVsZXNzIA0KICAgbWVkaXVtIGFsc28gZGVtYW5kcyBlZmZlY3RpdmUgY29vcmRpbmF0 aW9uIGFtb25nIHRoZSBBUHMgdG8gbWluaW1pemUgDQogICByYWRpbyBpbnRlcmZlcmVuY2UgYW5k IG1heGltaXplIG5ldHdvcmsgcGVyZm9ybWFuY2UuIEZ1cnRoZXJtb3JlLCANCiAgIHZlbmRvcnMg aW1wbGVtZW50IG5vdCBvbmx5IHRoZSBzZXJ2aWNlcyBkZWZpbmVkIGluIHRoZSBJRUVFIDgwMi4x MSANCiAgIHN0YW5kYXJkLCBidXQgYWxzbyBhIHZhcmlldHkgb2YgdmFsdWUtYWRkZWQgc2Vydmlj ZXMgb3IgZnVuY3Rpb25zLCANCiAgIGxpa2UgbG9hZCBiYWxhbmNpbmcgc3VwcG9ydCwgUW9TLCBz dGF0aW9uIG1vYmlsaXR5IHN1cHBvcnQsIHJvZ3VlIEFQIA0KICAgZGV0ZWN0aW9uLCBldGMuDQog ICANCiAgIFRoZSBDZW50cmFsaXplZCBXTEFOIEFyY2hpdGVjdHVyZSBmYW1pbHksIGFzIGRlc2Ny aWJlZCBpbiBbMl0sIGlzIA0KICAgYW4gaW5ub3ZhdGl2ZSBhcmNoaXRlY3R1cmFsIHNvbHV0aW9u IGludGVuZGVkIHRvIGFkZHJlc3MgdGhlIA0KICAgYWZvcmVtZW50aW9uZWQgcHJvYmxlbXMuIFR3 byBjbGFzc2VzIG9mIHRoZSBDZW50cmFsaXplZCBXTEFOIA0KICAgQXJjaGl0ZWN0dXJlIGZhbWls eSwgbmFtZWx5IHRoZSBMb2NhbCBNQUMgYW5kIHRoZSBTcGxpdCBNQUMsIHdpbGwgYmUgDQogICBz dXBwb3J0ZWQgYnkgdGhlIENBUFdBUCBwcm90b2NvbCB0byByZWFsaXplIGludGVyb3BlcmFiaWxp dHkgb2YgdGhlIA0KICAgQUMtV1RQIGludGVyZmFjZSBhbW9uZyB2ZW5kb3JzLiBUaGlzIGRvY3Vt ZW50IHB1dHMgZm9ydGggdGhlIA0KDQoNCldlbmh1aSBaaG91ICAgICAgICAgICAgICBFeHBpcmVz IC0gTWFyY2ggMjAwNSAgICAgICAgICAgICAgICAgICBbUGFnZSAyXQ0KDA0KSW50ZXJuZXQtRHJh ZnQgICAgICAgQ0FQV0FQIFByb3RvY29sIE9iamVjdGl2ZXMgICAgICAgICAgICAgT2N0b2JlciAy MDA0DQoNCg0KICAgcmVxdWlyZW1lbnRzIGZvciBDQVBXQVAgcHJvdG9jb2wgYmV0d2VlbiB0aGUg QUMgYW5kIFdUUC4gDQoNCjIuMSAgQ2VudHJhbGl6ZWQgV0xBTiBBcmNoaXRlY3R1cmUNCg0KICAg RmlndXJlIDEgc2hvd3MgYSBkaWFncmFtIG9mIHRoZSBDZW50cmFsaXplZCBXTEFOIEFyY2hpdGVj dHVyZSBmcm9tIA0KICAgWzJdLiBJbiB0aGUgQ2VudHJhbGl6ZWQgV0xBTiBBcmNoaXRlY3R1cmUs IHRoZXJlIGlzIG9uZSBvciBtb3JlIA0KICAgY2VudHJhbGl6ZWQgY29udHJvbGxlcnMgZm9yIG1h bmFnaW5nIGEgbGFyZ2UgbnVtYmVyIG9mIFdUUCBkZXZpY2VzLiAgDQogICBUaGUgY2VudHJhbGl6 ZWQgY29udHJvbGxlciBpcyBjb21tb25seSByZWZlcnJlZCB0byBhcyBhbiBBY2Nlc3MgDQogICBD b250cm9sbGVyIChBQyksIHdob3NlIG1haW4gZnVuY3Rpb24gaXMgdG8gbWFuYWdlLCBjb250cm9s IGFuZCANCiAgIGNvbmZpZ3VyZSB0aGUgV1RQIGRldmljZXMgdGhhdCBhcmUgcHJlc2VudCBpbiB0 aGUgbmV0d29yay4gIEluIA0KICAgYWRkaXRpb24gdG8gYmVpbmcgYSBjZW50cmFsaXplZCBlbnRp dHkgZm9yIHRoZSBjb250cm9sIGFuZCBtYW5hZ2VtZW50IA0KICAgcGxhbmUsIGl0IG1heSBhbHNv IGJlY29tZSBhIG5hdHVyYWwgYWdncmVnYXRpb24gcG9pbnQgZm9yIHRoZSBkYXRhIA0KICAgcGxh bmUsIHNpbmNlIGl0IGlzIHR5cGljYWxseSBzaXR1YXRlZCBpbiBhIGNlbnRyYWxpemVkIGxvY2F0 aW9uIGluIA0KICAgdGhlIHdpcmVsZXNzIGFjY2VzcyBuZXR3b3JrLiBUaGUgQUMgaXMgb2Z0ZW4g Y28tbG9jYXRlZCB3aXRoIGFuIEwyIA0KICAgYnJpZGdlLCBhIHN3aXRjaCwgb3IgYW4gTDMgcm91 dGVyLCBhbmQgaGVuY2UgbWF5IGJlIHJlZmVycmVkIHRvIGFzIA0KICAgQWNjZXNzIEJyaWRnZSwg b3IgQWNjZXNzIFJvdXRlciBpbiB0aG9zZSBwYXJ0aWN1bGFyIGNhc2VzLiAgVGhlcmVmb3JlLCAN CiAgIGFuIEFjY2VzcyBDb250cm9sbGVyIGNvdWxkIGJlIGVpdGhlciBhbiBMMyBvciBMMiBkZXZp Y2UsIGFuZCBBY2Nlc3MgDQogICBDb250cm9sbGVyIGlzIHRoZSBnZW5lcmljIHRlcm1pbm9sb2d5 IHdlIHVzZSB0aHJvdWdob3V0IHRoaXMgZG9jdW1lbnQuICANCiAgIEl0IGlzIGFsc28gcG9zc2li bGUgdGhhdCBtdWx0aXBsZSBBQ3MgYXJlIHByZXNlbnQgaW4gYSBuZXR3b3JrIGZvciANCiAgIHB1 cnBvc2VzIG9mIHJlZHVuZGFuY3ksIGxvYWQgYmFsYW5jaW5nLCBldGMuICBUaGlzIGFyY2hpdGVj dHVyZSANCiAgIGZhbWlseSBoYXMgc2V2ZXJhbCBkaXN0aW5jdCBjaGFyYWN0ZXJpc3RpY3MgdGhh dCBhcmUgd29ydGggbm90aW5nLiAgDQogICBGaXJzdCBvZiBhbGwsIHRoZSBoaWVyYXJjaGljYWwg YXJjaGl0ZWN0dXJlIGFuZCB0aGUgY2VudHJhbGl6ZWQgQUMgDQogICBhZmZvcmQgbXVjaCBiZXR0 ZXIgbWFuYWdlYWJpbGl0eSBmb3IgdGhlIGxhcmdlIHNjYWxlIG5ldHdvcmtzLiAgDQogICBTZWNv bmRseSwgc2luY2UgdGhlIElFRUUgODAyLjExIGZ1bmN0aW9ucyBhbmQgdGhlIENBUFdBUCBjb250 cm9sIA0KICAgZnVuY3Rpb25zIGFyZSBwcm92aWRlZCBieSB0aGUgV1RQIGRldmljZXMgYW5kIHRo ZSBBQyB0b2dldGhlciwgdGhlIA0KICAgV1RQIGRldmljZXMgdGhlbXNlbHZlcyBtYXkgbm90IGlt cGxlbWVudCB0aGUgZnVsbCA4MDIuMTEgZnVuY3Rpb25zIGFzIA0KICAgZGVmaW5lZCBpbiB0aGUg c3RhbmRhcmRzIGFueSBtb3JlLiBUaGVyZWZvcmUsIGl0IGNhbiBiZSBzYWlkIHRoYXQgdGhlIA0K ICAgZnVsbCA4MDIuMTEgZnVuY3Rpb25zIGFyZSBpbXBsZW1lbnRlZCBhY3Jvc3MgbXVsdGlwbGUg cGh5c2ljYWwgDQogICBuZXR3b3JrIGRldmljZXMsIG5hbWVseSwgdGhlIFdUUHMgYW5kIEFDcy4g IFNpbmNlIHRoZSBXVFAgZGV2aWNlcyANCiAgIG9ubHkgaW1wbGVtZW50IGEgcG9ydGlvbiBvZiB0 aGUgZnVuY3Rpb25zIHRoYXQgc3RhbmRhbG9uZSBBUHMgDQogICBpbXBsZW1lbnQsIFdUUCBkZXZp Y2VzIGluIHRoaXMgYXJjaGl0ZWN0dXJlIGFyZSBzb21ldGltZXMgcmVmZXJyZWQgdG8gDQogICBh cyBsaWdodCB3ZWlnaHQgb3IgdGhpbiBBUHMgYnkgc29tZSB2ZW5kb3JzLg0KDQoNCg0KDQoNCg0K DQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQpXZW5odWkgWmhvdSAgICAgICAgICAgICAgRXhwaXJl cyAtIE1hcmNoIDIwMDUgICAgICAgICAgICAgICAgICAgW1BhZ2UgM10NCgwNCkludGVybmV0LURy YWZ0ICAgICAgIENBUFdBUCBQcm90b2NvbCBPYmplY3RpdmVzICAgICAgICAgICAgIE9jdG9iZXIg MjAwNA0KDQoNCiAgIEFzIHNob3duIGluIEZpZ3VyZSAxLCBDQVBXQVAgcHJvdG9jb2wgaXMgdGhl IHByb3RvY29sIGJldHdlZW4gV1RQIGFuZCANCiAgIEFDIHRoYXQgd2lsbCBwcm92aWRlIHZlbmRv ciBpbnRlcm9wZXJhYmlsaXR5IHdoZW4gaXQgaXMgc3RhbmRhcmRpemVkLg0KICAgVGhpcyBwcm90 b2NvbCBtYXkgcnVuIG9uIGRpZmZlcmVudCBpbnRlcmNvbm5lY3Rpb24gdGVjaG5vbG9neS4gDQoN CqGhoaErLS0tLS0tLS0tLS0tLS0tLSsgICAgICstLS0tLS0tLS0tLS0tLS0rICAgICArLS0tLS0t LS0tLS0tLS0tKw0KICAgIHwgIDgwMi4xMSBCU1MgMSB8ICAgICB8ICA4MDIuMTEgQlNTIDIgfCAg ICAgfCAgODAyLjExIEJTUyAzIHwNCiAgICB8ICAuLi4gICAgICAgICAgfCAgICAgfCAgLi4uICAg ICAgICAgIHwgICAgIHwgIC4uLiAgICAgICAgICB8DQogICAgfCAgICArLS0tLS0tLSsgIHwgICAg IHwgICAgKy0tLS0tLS0rICB8ICAgICB8ICAgICstLS0tLS0tKyAgfA0KICAgICstLS0tfCAgV1RQ ICB8LS0rICAgICArLS0tLXwgIFdUUCAgfC0tKyAgICAgKy0tLS18ICBXVFAgIHwtLSsNCiAgICAg ICAgICstLS0rLS0tKyAgICAgICAgICAgICArLS0tKy0tLSsgICAgICAgICAgICAgKy0tLSstLS0r DQogICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAgICAg ICB8DQogICAgICAgICAgICAgKy0tLS0tLS0tLS0tLS0tLS0tLSsgIHwgICArLS0tLS0tLS0tLS0t LS0tLS0rDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwgIHwuLi58DQogICAgICAg ICAgICAgICAgICAgICAgICAgICArLS0tLSstLSstLS0rLS0tLS0tLS0rDQogICAgICAgICAgICAg ICAgICAgICAgICAgICB8ICBDQVBXQVAgUHJvdG9jb2wgICB8DQogICAgICAgICAgICAgICAgICAg ICAgICAgICArLS0tLSstLSstLS0rLS0tLS0tLS0rDQogICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIHwNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfA0KICAgICAg ICAgICAgICAgICAgICAgICAgICAgICArLS0tLS0rLS0tLSsNCiAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgfCAgICBBQyAgICB8DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICstLS0t LS0tLS0tKw0KDQogICAgICAgICAgICBGaWd1cmUgMTogQ2VudHJhbGl6ZWQgV0xBTiBBcmNoaXRl Y3R1cmUgRGlhZ3JhbQ0KDQoyLjIgIExvY2FsIE1BQw0KDQogICBUaGUgbWFpbiBtb3RpdmF0aW9u IG9mIExvY2FsIE1BQyBhcmNoaXRlY3R1cmUgbW9kZWwgaXMgdG8gb2ZmbG9hZCANCiAgIG5ldHdv cmsgYWNjZXNzIHBvbGljaWVzIGFuZCBtYW5hZ2VtZW50IGZ1bmN0aW9ucyAoQ0FQV0FQIGZ1bmN0 aW9ucyANCiAgIGRlc2NyaWJlZCBpbiBbMl0pIHRvIHRoZSBBQywgd2l0aG91dCBzcGxpdHRpbmcg dGhlIDgwMi4xMSBNQUMgDQogICBmdW5jdGlvbmFsaXR5IGJldHdlZW4gV1RQcyBhbmQgQUMuIFRo ZSB3aG9sZSA4MDIuMTEgTUFDIHJlc2lkZXMgb24gDQogICB0aGUgV1RQcyBsb2NhbGx5LCBpbmNs dWRpbmcgYWxsIHRoZSA4MDIuMTEgbWFuYWdlbWVudCBhbmQgY29udHJvbCANCiAgIGZyYW1lIHBy b2Nlc3NpbmcgZm9yIHRoZSBTVEFzOyBvbiB0aGUgb3RoZXIgaGFuZCwgaW5mb3JtYXRpb24gcmVs YXRlZCANCiAgIHRvIG1hbmFnZW1lbnQgYW5kIGNvbmZpZ3VyYXRpb24gb2YgdGhlIFdUUCBkZXZp Y2VzIGlzIGNvbW11bmljYXRlZCANCiAgIHdpdGggYSBjZW50cmFsaXplZCBBQywgdG8gZmFjaWxp dGF0ZSBtYW5hZ2VtZW50IG9mIHRoZSBuZXR3b3JrLCBhbmQgDQogICBtYWludGFpbiBhIGNvbnNp c3RlbnQgbmV0d29yay13aWRlIGNvbmZpZ3VyYXRpb24gZm9yIHRoZSBXVFAgZGV2aWNlcy4NCg0K Mi4zICBTcGxpdCBNQUMNCg0KICAgVGhlIG1haW4gaWRlYSBiZWhpbmQgdGhlIFNwbGl0IE1BQyBh cmNoaXRlY3R1cmUgaXMgdG8gaW1wbGVtZW50IHBhcnQgDQogICBvZiB0aGUgODAyLjExIE1BQyBm dW5jdGlvbmFsaXR5IG9uIGEgY2VudHJhbGl6ZWQgQUMgaW5zdGVhZCBvZiB0aGUgDQogICBXVFBz LCBpbiBhZGRpdGlvbiB0byB0aGUgc2VydmljZXMgcmVxdWlyZWQgZm9yIG1hbmFnaW5nIGFuZCAN CiAgIG1vbml0b3JpbmcgdGhlIFdUUCBkZXZpY2VzLiBVc3VhbGx5LCB0aGUgZGVjaXNpb24gb2Yg d2hpY2ggZnVuY3Rpb25zIA0KICAgb2YgdGhlIDgwMi4xMSBNQUMgbmVlZCB0byBiZSBwcm92aWRl ZCBieSB0aGUgQUMgaXMgYmFzZWQgb24gdGhlIHRpbWUtDQogICBjcml0aWNhbGl0eSBvZiB0aGUg c2VydmljZXMgY29uc2lkZXJlZC4NCg0KICAgSW4gdGhlIFNwbGl0IE1BQyBhcmNoaXRlY3R1cmUs IHRoZSBXVFAgdGVybWluYXRlcyB0aGUgDQogICBpbmZyYXN0cnVjdHVyZSBzaWRlIG9mIHRoZSB3 aXJlbGVzcyBwaHlzaWNhbCBsaW5rLCBwcm92aWRlcyByYWRpby0NCiAgIHJlbGF0ZWQgbWFuYWdl bWVudCwgYW5kIGFsc28gaW1wbGVtZW50cyBhbGwgdGltZS1jcml0aWNhbCANCg0KDQoNCldlbmh1 aSBaaG91ICAgICAgICAgICAgICBFeHBpcmVzIC0gTWFyY2ggMjAwNSAgICAgICAgICAgICAgICAg ICBbUGFnZSA0XQ0KDA0KSW50ZXJuZXQtRHJhZnQgICAgICAgQ0FQV0FQIFByb3RvY29sIE9iamVj dGl2ZXMgICAgICAgICAgICAgT2N0b2JlciAyMDA0DQoNCg0KICAgZnVuY3Rpb25hbGl0eSBvZiB0 aGUgODAyLjExIE1BQy4gSW4gYWRkaXRpb24sIHRoZSBub24gcmVhbC10aW1lIA0KICAgbWFuYWdl bWVudCBmdW5jdGlvbnMgYXJlIGhhbmRsZWQgYnkgYSBjZW50cmFsaXplZCBBQywgYWxvbmcgd2l0 aCANCiAgIGhpZ2hlci1sZXZlbCBzZXJ2aWNlcywgc3VjaCBhcyBjb25maWd1cmF0aW9uLCBRb1Ms IHBvbGljaWVzIGZvciBsb2FkLQ0KICAgYmFsYW5jaW5nLCBhY2Nlc3MgY29udHJvbCBsaXN0cywg ZXRjLiAgVGhlIHN1YnRsZSBidXQga2V5IGRpc3RpbmN0aW9uIA0KICAgYmV0d2VlbiBMb2NhbCBN QUMgYW5kIFNwbGl0IE1BQyByZWxhdGVzIHRvIHRoZSBub24gcmVhbC10aW1lIA0KICAgZnVuY3Rp b25zOiBpbiBTcGxpdCBNQUMgYXJjaGl0ZWN0dXJlLCB0aGUgQUMgdGVybWluYXRlcyA4MDIuMTEg bm9uIA0KICAgcmVhbC10aW1lIGZ1bmN0aW9ucywgd2hlcmVhcyBpbiBMb2NhbCBNQUMgYXJjaGl0 ZWN0dXJlIHRoZSBXVFAgDQogICB0ZXJtaW5hdGVzIHRoZSA4MDIuMTEgbm9uIHJlYWwtdGltZSBm dW5jdGlvbnMgYW5kIGNvbnNlcXVlbnRseSBzZW5kcyANCiAgIGFwcHJvcHJpYXRlIG1lc3NhZ2Vz IHRvIHRoZSBBQy4NCg0KICAgVGhlcmUgYXJlIHNldmVyYWwgbW90aXZhdGlvbnMgZm9yIHRha2lu ZyB0aGUgU3BsaXQgTUFDIGFwcHJvYWNoLiAgDQogICBUaGUgZmlyc3QgaXMgdG8gb2ZmbG9hZCB0 byB0aGUgV1RQIGZ1bmN0aW9uYWxpdHkgdGhhdCBpcyBzcGVjaWZpYyBhbmQgDQogICByZWxldmFu dCBvbmx5IHRvIHRoZSBsb2NhbGl0eSBvZiBlYWNoIEJTUywgaW4gb3JkZXIgdG8gYWxsb3cgdGhl IEFDIA0KICAgdG8gc2NhbGUgdG8gYSBsYXJnZSBudW1iZXIgb2YgJ2xpZ2h0IHdlaWdodCcgV1RQ IGRldmljZXMuIE1vcmVvdmVyLCANCiAgIHJlYWwtdGltZSBmdW5jdGlvbmFsaXR5IGlzIHN1Ympl Y3QgdG8gbGF0ZW5jeSBjb25zdHJhaW50cyBhbmQgY2Fubm90IA0KICAgdG9sZXJhdGUgZGVsYXlz IGR1ZSB0byB0cmFuc21pc3Npb24gb2YgODAyLjExIENvbnRyb2wgZnJhbWVzIChvciANCiAgIG90 aGVyIHJlYWwtdGltZSBpbmZvcm1hdGlvbikgb3ZlciBtdWx0aXBsZS1ob3BzLiBUaGUgbGF0dGVy IHdvdWxkIA0KICAgbGltaXQgdGhlIGF2YWlsYWJsZSBjaG9pY2VzIGZvciB0aGUgY29ubmVjdGl2 aXR5IGJldHdlZW4gdGhlIEFDIGFuZCANCiAgIHRoZSBXVFAsIGhlbmNlIHRoZSByZWFsLXRpbWUg Y3JpdGVyaW9uIGlzIHVzdWFsbHkgZW1wbG95ZWQgdG8gDQogICBzZXBhcmF0ZSBNQUMgc2Vydmlj ZXMgYmV0d2VlbiB0aGUgZGV2aWNlcy4gIEFub3RoZXIgY29uc2lkZXJhdGlvbiBpcyANCiAgIGNv c3QgcmVkdWN0aW9uIG9mIHRoZSBXVFAgdG8gbWFrZSBpdCBhcyBjaGVhcCBhbmQgc2ltcGxlIGFz IHBvc3NpYmxlLiANCiAgIExhc3QgYnV0IG5vdCBsZWFzdCwgbW92aW5nIGZ1bmN0aW9ucyBsaWtl IGVuY3J5cHRpb24gYW5kIGRlY3J5cHRpb24gDQogICB0byB0aGUgQUMgcmVkdWNlcyB2dWxuZXJh YmlsaXRpZXMgZnJvbSBhIGNvbXByb21pc2VkIFdUUCwgc2luY2UgdXNlciANCiAgIGVuY3J5cHRp b24ga2V5cyBubyBsb25nZXIgcmVzaWRlIG9uIHRoZSBXVFAuICBBcyBhIHJlc3VsdCwgYW55IA0K ICAgYWR2YW5jZW1lbnRzIGluIHNlY3VyaXR5IHByb3RvY29scyBhbmQgYWxnb3JpdGhtcyBkZXNp Z24gZG8gbm90IA0KICAgbmVjZXNzYXJpbHkgb2Jzb2xldGUgdGhlIFdUUHM7IHRoZSBBQ3MgaW1w bGVtZW50IHRoZSBuZXcgc2VjdXJpdHkgDQogICBzY2hlbWVzIGluc3RlYWQsIGFuZCB0aGUgbWFu YWdlbWVudCBhbmQgdXBkYXRlIHRhc2sgaXMgdGhlcmVmb3JlIA0KICAgc2ltcGxpZmllZC4gQWRk aXRpb25hbGx5LCB0aGUgbmV0d29yayBpcyBwcm90ZWN0ZWQgYWdhaW5zdCBMQU4tc2lkZSANCiAg IGVhdmVzZHJvcHBpbmcuDQoNCjMuICBBcmNoaXRlY3R1cmFsIHJlcXVpcmVtZW50cw0KDQogICBU aGUgZm9sbG93aW5nIGFyZSB0aGUgYXJjaGl0ZWN0dXJhbCByZXF1aXJlbWVudHMgZm9yIENBUFdB UCBwcm90b2NvbDoNCg0KICAgMSkgQm90aCBsb2NhbCBNQUMgYW5kIHNwbGl0IE1BQyB0ZWNobm9s b2dpZXMgYmFzZWQgcHJvZHVjdHMsIGkuZS4sIA0KICAgQUNzIG9yIFdUUHMgbXVzdCBiZSBhYmxl IHRvIGNvLWV4aXN0IGFuZCBpbnRlci1vcGVyYXRlIGluIG9uZSBXTEFOIA0KICAgYWNjZXNzIG5l dHdvcmsuDQoNCiAgIDIpIEFDcyBhbmQgV1RQcyBNVVNUIGJlIGFibGUgdG8gY29ubmVjdCBieSBh IHZhcmlldHkgb2YgaW50ZXJjb25uZWN0IA0KICAgdGVjaG5vbG9naWVzLiBDQVBXQVAgcHJvdG9j b2wgc2hvdWxkIGJlIHRyYW5zbWl0dGVkIHRyYW5zcGFyZW50bHkgDQogICByZWdhcmRsZXNzIG9m IGxvd2VyIHRlY2hub2xvZ2llcy4gRXhhbXBsZXMgb2YgaW50ZXJjb25uZWN0IA0KICAgdGVjaG5v bG9naWVzIHVzZWQgaW4gY3VycmVudCBhcmNoaXRlY3R1cmVzIGluY2x1ZGUgRXRoZXJuZXQsIGJ1 cyANCiAgIGJhY2twbGFuZXMsIGFuZCBBVE0gKGNlbGwpIGZhYnJpY3MuIEV0aGVybmV0IGFyY2hp dGVjdHVyZSBpcyBtb3N0IA0KICAgd2lkZWx5IHVzZWQgYW5kIHNob3VsZCBiZSByZWNvbW1lbmRl ZC4gDQoNCiAgIDMpIENBUFdBUC1zdXBwb3J0ZWQgV1RQcyBzaG91bGQgYmUgYWJsZSB0byBjby1l eGlzdCB3aXRoIG5vbi1DQVBXQVAgDQogICBXVFBzIGluIG9uZSBXTEFOIGFjY2VzcyBuZXR3b3Jr Lg0KDQoNCg0KDQpXZW5odWkgWmhvdSAgICAgICAgICAgICAgRXhwaXJlcyAtIE1hcmNoIDIwMDUg ICAgICAgICAgICAgICAgICAgW1BhZ2UgNV0NCgwNCkludGVybmV0LURyYWZ0ICAgICAgIENBUFdB UCBQcm90b2NvbCBPYmplY3RpdmVzICAgICAgICAgICAgIE9jdG9iZXIgMjAwNA0KDQoNCjQuICBV c2VyIChjbGllbnQpIGFjY2VzcyByZXF1aXJlbWVudHMNCg0KICAgVGhlcmUgc2hvdWxkbid0IGJl IGFueSBpbXBhY3Qgb24gdGhlIGNsaWVudCAoYm90aCBoYXJkd2FyZSBhbmQgDQogICBzb2Z0d2Fy ZSBwbGF0Zm9ybSkgZHVlIHRvIHRoZSB1c2Ugb2YgICAgQ0FQV0FQIHByb3RvY29sLiBDbGllbnRz IA0KICAgc2hvdWxkIG5vdCBiZSByZXF1aXJlZCB0byBiZSBhd2FyZSBvZiB0aGUgZXhpc3RlbmNl IG9mIENBUFdBUCANCiAgIHByb3RvY29sLg0KDQo1LiAgU2VydmljZSByZXF1aXJlbWVudHMNCg0K ICAgVGhlIGZvbGxvd2luZyBhcmUgdGhlIHNlcnZpY2UgcmVxdWlyZW1lbnRzOg0KDQogICAxKVZv aWNlIG92ZXIgV0xBTi4gU28gQ0FQV0FQIHNob3VsZCBzdXBwb3J0IElFRUUgODAyLjExZSBhbmQg cHJvdmlkZSANCiAgIGZhc3QtaGFuZG9mZiBjYXBhYmlsaXR5IHRvIGF2b2lkIHZvaWNlIGludGVy cnVwdGlvbi4NCiAgIA0KICAgMilJc29sYXRlIFdUUCBmcm9tIG90aGVycyBhbmQgcmVzdHJpY3Qg aW50ZXItV1RQcyBpbiBsYXllciAyIA0KICAgY29tbXVuaWNhdGlvbiBkaXJlY3RseS4NCg0KICAg MylXTEFOIG5ldHdvcmsgcmVzb3VyY2Ugc2hhcmUuIEl0IGlzIHJlcXVpcmVkIHRoYXQgdHdvIG9y IG1vcmUgV0xBTiANCiAgIHNlcnZpY2UgcHJvdmlkZXJzIGNhbiBzaGFyZSBhIGhvdHNwb3QgV0xB TiBuZXR3b3JrLiBUaGlzIG1lYW5zIA0KICAgdGhhdCBhIHBoeXNpY2FsIFdMQU4gbmV0d29yayBj YW4gYmUgdmlydHVhbGl6ZWQgaW50byBzZXZlcmFsIA0KICAgbG9naWNhbCBXTEFOIG5ldHdvcmsu DQoNCjYuICBDZW50cmFsaXplZCBDb250cm9sIHJlcXVpcmVtZW50cw0KDQogICBUaGUgZm9sbG93 aW5nIGFyZSB0aGUgY29udHJvbCByZXF1aXJlbWVudHM6DQoNCiAgIDEpQUMgbWF5IHBlcmZvcm0g YWNjZXNzIGNvbnRyb2wgZnVuY3Rpb25zIGJhc2VkIG9uIHJhZGlvIHJlc291cmNlIA0KICAgYW5k L29yIG5ldHdvcmsgcmVzb3VyY2UuDQoNCiAgIDIpVG8gc3VwcG9ydCBoYW5kb3ZlciBhbmQgbG9h ZCBiYWxhbmNpbmcgYmV0d2VlbiBkaWZmZXJlbnQgV1RQUywgQUMgDQogICBzaG91bGQgaGF2ZSB0 aGUgY2FwYWJpbGl0eSBvZiBjZW50cmFsaXplZCBjb250cm9sIHZpYSBDQVBXQVAgcHJvdG9jb2wu DQoNCjcuICBNYW5hZ2VtZW50IFJlcXVpcmVtZW50cw0KDQogICBUaGUgZm9sbG93aW5nIGFyZSB0 aGUgbWFuYWdlbWVudCByZXF1aXJlbWVudHM6DQogICBJdCBpcyBwb3NzaWJsZSB0aGF0IFdUUHMg Y2FuIGJlIG1hbmFnZWQgZGlyZWN0bHkgb3IgdGhyb3VnaCBBQyANCiAgIHdoZXJlIEFDIGFjdHMg YXMgYSBtYW5hZ2VtZW50IGFnZW50Lg0KDQo4LiAgU2VjdXJpdHkgUmVxdWlyZW1lbnRzDQoNCiAg IFRoZSBmb2xsb3dpbmcgYXJlIHRoZSBzZWN1cml0eSByZXF1aXJlbWVudHM6DQoNCiAgIDEpSXQg aXMgcmVxdWlyZWQgdG8gc3VwcG9ydCBXUEEgYW5kL29yIElFRUUgODAyLjExaSBmb3Igd2lyZWxl c3MgYWlyIA0KICAgaW50ZXJmYWNlIHNlY3VyaXR5Lg0KDQogICAyKUl0IGlzIHJlcXVpcmVkIHRv IHByb3ZpZGUgbWVjaGFuaXNtIHN1cHBvcnRpbmcgc2VjdXJlIGluZm9ybWF0aW9uIA0KICAgZXhj aGFuZ2UgYmV0d2VlbiBBQyBhbmQgV1RQIA0KDQoNCg0KDQpXZW5odWkgWmhvdSAgICAgICAgICAg ICAgRXhwaXJlcyAtIE1hcmNoIDIwMDUgICAgICAgICAgICAgICAgICAgW1BhZ2UgNl0NCgwNCklu dGVybmV0LURyYWZ0ICAgICAgIENBUFdBUCBQcm90b2NvbCBPYmplY3RpdmVzICAgICAgICAgICAg IE9jdG9iZXIgMjAwNA0KDQoNCjkuICBRb1MgUmVxdWlyZW1lbnRzDQoNCiAgVGhlIGZvbGxvd2lu ZyBhcmUgdGhlIFFvUyByZXF1aXJlbWVudHM6DQoNCiAgV0xBTiBhaXIgaW50ZXJmYWNlIFFvUyBp bXBsZW1lbnRhdGlvbiBzaG91bGQgYmUgYmFzZWQgb24gdGhlIGN1cnJlbnQgDQogIElFRUU4MDIu MTFlLCBidXQgaXQgaXMgcmVxdWlyZWQgdG8gc3VwcG9ydCBRb1MgY2VudHJhbGl6ZWQgY29udHJv bCANCiAgUG9saWN5IGJldHdlZW4gV1RQUyBhbmQgQUMgdmlhIENBUFdBUCBwcm90b2NvbC4NCg0K DQpSZWZlcmVuY2VzDQoNCiAgIDEuIKGwQ0FQV0FQIFByb2JsZW0gU3RhdGVtZW50obEsIEF1Z3Vz dCAyMDA0LCANCiAgIDxodHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1p ZXRmLWNhcHdhcC1wcm9ibGVtLQ0KICAgc3RhdGVtZW50LTAyLnR4dD4NCg0KICAgMi4gobBBcmNo aXRlY3R1cmUgVGF4b25vbXkgZm9yIENvbnRyb2wgYW5kIFByb3Zpc2lvbmluZyBvZiBXaXJlbGVz cyANCiAgIEFjY2VzcyBQb2ludHMgKENBUFdBUCmhsSwgQXVndXN0IDIwMDQsIA0KICAgaHR0cDov L3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtaWV0Zi1jYXB3YXAtYXJjaC0wNS50 eHQ+DQoNCiAgIDMuIKGwRnVuY3Rpb25hbGl0eSBDbGFzc2lmaWNhdGlvbnMgZm9yIENvbnRyb2wg YW5kIFByb3Zpc2lvbmluZyBvZiANCiAgIFdpcmVsZXNzIEFjY2VzcyBQb2ludHMgKENBUFdBUCmh sSwgSnVseSAyMDA0LCAgDQogICA8aHR0cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMv ZHJhZnQtY2hlbmctY2Fwd2FwLQ0KICAgY2xhc3NpZmljYXRpb25zLTAxLnR4dD4NCg0KDQoNCiAN CiANCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQpXZW5odWkg WmhvdSAgICAgICAgICAgICAgRXhwaXJlcyAtIE1hcmNoIDIwMDUgICAgICAgICAgICAgICAgICAg W1BhZ2UgN10NCgw= ------_=_NextPart_001_01C4B534.A8A0A249-- _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Wed Oct 20 21:02:06 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA29710 for ; Wed, 20 Oct 2004 21:02:06 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id E89EF1FCC5; Wed, 20 Oct 2004 21:02:05 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id BE8531FCC1; Wed, 20 Oct 2004 21:02:02 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 21DA11FCC1 for ; Wed, 20 Oct 2004 21:01:53 -0400 (EDT) Received: from mailsrv.psl.com.sg (mailsrv.psl.com.sg [202.14.153.3]) by mail.frascone.com (Postfix) with ESMTP id EDE351FCB7 for ; Wed, 20 Oct 2004 21:01:50 -0400 (EDT) Received: from Saravanan ([10.81.113.32]) by mailsrv.psl.com.sg (8.13.1/8.13.1) with ESMTP id i9L0x4OR023071; Thu, 21 Oct 2004 08:59:04 +0800 (SGT) Message-Id: <200410210059.i9L0x4OR023071@mailsrv.psl.com.sg> From: "Saravanan Govindan" To: Cc: "'Cheng Hong'" , "'Satoshi IINO'" , Organization: Panasonic Singapore Laboratories MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-index: AcS3CYEYEkyjpSNtRpeIuDo/Hexpcg== X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [Capwap] draft-govindan-capwap-objectives-00.txt in I-D directory Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Thu, 21 Oct 2004 09:01:34 +0800 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit Dear All, The following is the official I-D announcement regarding the "Objectives for Control and Provisioning of Wireless Access Points (CAPWAP)" draft. We look forward to any questions or comments. Cheers, Saravanan ---------------------------------------------------------------------------- ------- A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Objectives for Control and Provisioning of Wireless Access Points (CAPWAP) Author(s) : S. Govindan, et al. Filename : draft-govindan-capwap-objectives-00.txt Pages : 18 Date : 2004-10-19 This document presents objectives for the Control and Provisioning of Wireless Access Points (CAPWAP) framework. Primarily it presents a fundamental objective for interoperability among wireless local area network (WLAN) devices of different designs. The document also describes additional objectives for shared WLAN infrastructure and QoS. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-govindan-capwap-objectives-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request at ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-govindan-capwap-objectives-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv at ietf.org. In the body type: "FILE /internet-drafts/draft-govindan-capwap-objectives-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. _______________________________________________ I-D-Announce mailing list I-D-Announce at ietf.org https://www1.ietf.org/mailman/listinfo/i-d-announce _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Thu Oct 21 05:14:06 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA22958 for ; Thu, 21 Oct 2004 05:14:06 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 76CC61FCB7; Thu, 21 Oct 2004 05:14:06 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 37B3A1FCC2; Thu, 21 Oct 2004 05:14:03 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 9D2CF1FCC2 for ; Thu, 21 Oct 2004 05:13:37 -0400 (EDT) Received: from brahma.intotoind.com (ip-66-80-10-146.dsl.sca.megapath.net [66.80.10.146]) by mail.frascone.com (Postfix) with ESMTP id 4C9FD1FCB7 for ; Thu, 21 Oct 2004 05:13:34 -0400 (EDT) Received: from rkp.intoto.com (1mc70.intotoind.com [172.16.1.70]) by brahma.intotoind.com (8.12.11/8.12.8) with ESMTP id i9L9DRnq013752 for ; Thu, 21 Oct 2004 14:43:27 +0530 Message-Id: <5.1.0.14.0.20041021145529.00a8db30@172.16.1.10> X-Sender: rkp@172.16.1.10 X-Mailer: QUALCOMM Windows Eudora Version 5.1 To: From: Chunduru Rama Krishna Prasad Subject: Re: [Capwap] Important: please provide input on comment resolution for CAPWAP Taxonomy draft In-Reply-To: <2AF68A477DD44C4EBCBE338C24E7A9EE018370CA@orsmsx408> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Scanned-By: MIMEDefang 2.41 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Thu, 21 Oct 2004 14:56:37 +0530 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) hi all, I am not sure, I am right on this. My impression is that, PMK is on per Authenticator MAC address. If the station is re-associated with new WTP (different MAC address), then it would not even send PMKID of old AP. If there is no PMKID found in reassoc event, AC would start with full 802.1x authentication. If the station is reassociating with an AP, to which it already established PMK before, then station sends PMKID and in that case only 4 way key handshake is requried to get the PTK. With respect to this, I am not sure whether the statement 'If PMK is shared across multiple WTP' is valid. If not, the whole statement can be removed from the draft Regards Rama Krishna Prasad Ch. Rama Krishna Prasad Intoto Software(I) Pvt Ltd, Uma Plaza, Nagarjuna circle, Panjagutta. Hyderabad, AP Tel No:s 2335 8927/8928/8434 _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Thu Oct 21 09:58:15 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA00251 for ; Thu, 21 Oct 2004 09:58:08 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 33BDD1FC0F; Thu, 21 Oct 2004 09:58:07 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 4CE821FCC2; Thu, 21 Oct 2004 09:58:03 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id A70B51FCC2 for ; Thu, 21 Oct 2004 09:57:55 -0400 (EDT) Received: from tierw.net.avaya.com (tierw.net.avaya.com [198.152.13.100]) by mail.frascone.com (Postfix) with ESMTP id B3F081FC0F for ; Thu, 21 Oct 2004 09:57:53 -0400 (EDT) Received: from tierw.net.avaya.com (localhost [127.0.0.1]) by tierw.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id i9LDnuBV014102 for ; Thu, 21 Oct 2004 08:49:57 -0500 (EST) Received: from cof110avexu1.global.avaya.com (h135-9-6-16.avaya.com [135.9.6.16]) by tierw.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id i9LDlwBV011701 for ; Thu, 21 Oct 2004 08:48:48 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C4B775.A9F4E443" Subject: RE: [Capwap] A draft on Objectives. Message-ID: Thread-Topic: [Capwap] A draft on Objectives. Thread-Index: AcS14dBcS86W7fWpRsGYieswb4xFQgBk0IqQ From: "Mani, Mahalingam (Mahalingam)" To: X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Thu, 21 Oct 2004 07:55:46 -0600 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) This is a multi-part message in MIME format. ------_=_NextPart_001_01C4B775.A9F4E443 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Now there are two individual drafts submitted: again - for review and comments. They are not in IETF repository (too late for that), nor this WG item (not yet chartered to consider). =20 Both are accessible here: http://www.capwap.org/objs/ =20 the second one here is from Zhou et al. =20 (thanks to Dave Frascone for putting them up on CAPWAP website). =20 -mani _____ =20 From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On Behalf Of Mani, Mahalingam (Mahalingam) Sent: Tuesday, October 19, 2004 6:45 AM To: capwap@frascone.com Subject: [Capwap] A draft on Objectives. Importance: High =20 Saravanan Govindan has submitted a draft in response to a call for Objectives (in connection with the recharter discussions in ietf60 @San Diego and on the list). =20 I have had it placed in the capwap website: http://www.capwap.org/draft-govindan-capwap-objectives-00.txt =20 Note that with this being out of scope for this phase of WG (and this phase having drawn/drawing=20 to a close) this is a courtesy posting to facilitate discussions. =20 [It arrived too late for submission as an individual -00 I-D to IETF repository]. =20 Feel free to review & comment. =20 -mani =20 ------_=_NextPart_001_01C4B775.A9F4E443 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Now there are  two individual = drafts submitted: again – for review and = comments.

They are not in IETF repository = (too late for that), nor this WG item (not yet chartered to = consider).

 

Both are accessible = here:

http://www.capwap.org/objs/=

 

the second one here is from Zhou et = al.

 

(thanks to Dave Frascone for = putting them up on CAPWAP website).

 

-mani

From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On Behalf Of Mani, Mahalingam (Mahalingam)
Sent: Tuesday, October = 19, 2004 6:45 AM
To: = capwap@frascone.com
Subject: [Capwap] A draft = on Objectives.
Importance: = High

 

Saravanan Govindan has submitted a draft in response = to a call for Objectives (in connection with

the recharter discussions in ietf60 @San Diego and on the = list).

 

I have had it placed in the capwap = website:

ht= tp://www.capwap.org/draft-govindan-capwap-objectives-00.txt

 

Note that with this being out of scope for this phase = of WG (and this phase having drawn/drawing

to a close) this is a courtesy posting to facilitate discussions.

 

[It arrived too late for submission as an individual = -00 I-D to IETF repository].

 

Feel free to review & = comment.

 

-mani

 

------_=_NextPart_001_01C4B775.A9F4E443-- _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Thu Oct 21 10:17:06 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03729 for ; Thu, 21 Oct 2004 10:17:05 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 8CB4D1FC0F; Thu, 21 Oct 2004 10:17:06 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id E28421FCCA; Thu, 21 Oct 2004 10:17:02 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id DAE0A1FCCA for ; Thu, 21 Oct 2004 10:16:28 -0400 (EDT) Received: from tomts20-srv.bellnexxia.net (tomts20-srv.bellnexxia.net [209.226.175.74]) by mail.frascone.com (Postfix) with ESMTP id 18A741FC0F for ; Thu, 21 Oct 2004 10:16:26 -0400 (EDT) Received: from wxp26 ([67.69.27.58]) by tomts20-srv.bellnexxia.net (InterMail vM.5.01.06.10 201-253-122-130-110-20040306) with ESMTP id <20041021141625.JMXT25820.tomts20-srv.bellnexxia.net@wxp26>; Thu, 21 Oct 2004 10:16:25 -0400 From: "Michael Montemurro" To: "'Chunduru Rama Krishna Prasad'" , Subject: RE: [Capwap] Important: please provide input on comment resolution for CAPWAP Taxonomy draft Message-ID: <004c01c4b778$8c977070$f601a8c0@toronto.chantrynetworks.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 In-Reply-To: <5.1.0.14.0.20041021145529.00a8db30@172.16.1.10> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Importance: Normal X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Thu, 21 Oct 2004 10:16:25 -0400 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit Rama, You are correct. The PMK is derived from an 802.1x authentication between the STA and the Authenticator. It is defined as being unique per Authenticator/STA pair, which implies that is a unique value for each WTP MAC/STA MAC pair. Cheers, Mike Michael Montemurro Director, Advanced Technology and Standards Chantry Networks Inc. Mississauga, ON, CANADA. T: 905-567-6900 x237 F: 905-567-9900 E: mike@chantrynetworks.com -----Original Message----- From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On Behalf Of Chunduru Rama Krishna Prasad Sent: Thursday, October 21, 2004 5:27 AM To: capwap@frascone.com Subject: Re: [Capwap] Important: please provide input on comment resolution for CAPWAP Taxonomy draft hi all, I am not sure, I am right on this. My impression is that, PMK is on per Authenticator MAC address. If the station is re-associated with new WTP (different MAC address), then it would not even send PMKID of old AP. If there is no PMKID found in reassoc event, AC would start with full 802.1x authentication. If the station is reassociating with an AP, to which it already established PMK before, then station sends PMKID and in that case only 4 way key handshake is requried to get the PTK. With respect to this, I am not sure whether the statement 'If PMK is shared across multiple WTP' is valid. If not, the whole statement can be removed from the draft Regards Rama Krishna Prasad Ch. Rama Krishna Prasad Intoto Software(I) Pvt Ltd, Uma Plaza, Nagarjuna circle, Panjagutta. Hyderabad, AP Tel No:s 2335 8927/8928/8434 _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Thu Oct 21 10:47:06 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08579 for ; Thu, 21 Oct 2004 10:47:05 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 3B1651FC0F; Thu, 21 Oct 2004 10:47:06 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id C38AF1FCCA; Thu, 21 Oct 2004 10:47:02 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 8D4F01FCCE for ; Thu, 21 Oct 2004 10:46:57 -0400 (EDT) Received: from AIREMAIL.airespace.com (da001d3897.stl-mo.osd.concentric.net [66.236.111.57]) by mail.frascone.com (Postfix) with ESMTP id D729C1FC0F for ; Thu, 21 Oct 2004 10:46:55 -0400 (EDT) Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Subject: RE: [Capwap] Important: please provide input on comment resolution for CAPWAP Taxonomy draft Message-ID: <55749BC69138654EBBC4C50BA4F556105A2F41@AIREMAIL.airespace.com> Thread-Topic: [Capwap] Important: please provide input on comment resolution for CAPWAP Taxonomy draft Thread-Index: AcS3eJ3RA+IptKBnQoauu4i5jBVMUgAA/UZQ From: "Pat R. Calhoun" To: "Michael Montemurro" , "Chunduru Rama Krishna Prasad" , X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Thu, 21 Oct 2004 07:46:53 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: quoted-printable The comment may be valid in light of 802.11r. I'd argue that the text remains since we need to be cognizant of not only current IEEE standards, but also the ones in progress. PatC=20 -----Original Message----- From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On Behalf Of Chunduru Rama Krishna Prasad Sent: Thursday, October 21, 2004 5:27 AM To: capwap@frascone.com Subject: Re: [Capwap] Important: please provide input on comment resolution for CAPWAP Taxonomy draft hi all, I am not sure, I am right on this. My impression is that, PMK is on per Authenticator MAC address. If the station is re-associated with new WTP (different MAC address), then it would not even send PMKID of old AP. If there is no PMKID found in reassoc event, AC would start with full 802.1x authentication. If the station is reassociating with an AP, to which it already established PMK before, then station sends PMKID and in that case only 4 way key handshake is requried to get the PTK. With respect to this, I am not sure whether the statement 'If PMK is shared across multiple WTP' is valid. If not, the whole statement can be removed from the draft Regards Rama Krishna Prasad Ch. Rama Krishna Prasad Intoto Software(I) Pvt Ltd, Uma Plaza, Nagarjuna circle, Panjagutta. Hyderabad, AP Tel No:s 2335 8927/8928/8434 _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Thu Oct 21 11:12:06 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11665 for ; Thu, 21 Oct 2004 11:12:06 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 0A2421FCCA; Thu, 21 Oct 2004 11:12:07 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 43C681FCCE; Thu, 21 Oct 2004 11:12:03 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 5DEA01FCCA for ; Thu, 21 Oct 2004 11:11:49 -0400 (EDT) Received: from tomts5-srv.bellnexxia.net (tomts5.bellnexxia.net [209.226.175.25]) by mail.frascone.com (Postfix) with ESMTP id 9B68D1FC0F for ; Thu, 21 Oct 2004 11:11:47 -0400 (EDT) Received: from wxp26 ([67.69.27.58]) by tomts5-srv.bellnexxia.net (InterMail vM.5.01.06.10 201-253-122-130-110-20040306) with ESMTP id <20041021151145.JRZM29162.tomts5-srv.bellnexxia.net@wxp26>; Thu, 21 Oct 2004 11:11:45 -0400 From: "Michael Montemurro" To: "'Pat R. Calhoun'" , "'Chunduru Rama Krishna Prasad'" , Subject: RE: [Capwap] Important: please provide input on comment resolution for CAPWAP Taxonomy draft Message-ID: <004f01c4b780$479090d0$f601a8c0@toronto.chantrynetworks.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 In-Reply-To: <55749BC69138654EBBC4C50BA4F556105A2F41@AIREMAIL.airespace.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Importance: Normal X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Thu, 21 Oct 2004 11:11:45 -0400 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit I'd agree that the text should likely remain. However, there should be work done (likely in both IEEE and IETF) to modify the key hierarchy to address this case. Mike -----Original Message----- From: Pat R. Calhoun [mailto:pcalhoun@airespace.com] Sent: Thursday, October 21, 2004 10:47 AM To: Michael Montemurro; Chunduru Rama Krishna Prasad; capwap@frascone.com Subject: RE: [Capwap] Important: please provide input on comment resolution for CAPWAP Taxonomy draft The comment may be valid in light of 802.11r. I'd argue that the text remains since we need to be cognizant of not only current IEEE standards, but also the ones in progress. PatC -----Original Message----- From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On Behalf Of Chunduru Rama Krishna Prasad Sent: Thursday, October 21, 2004 5:27 AM To: capwap@frascone.com Subject: Re: [Capwap] Important: please provide input on comment resolution for CAPWAP Taxonomy draft hi all, I am not sure, I am right on this. My impression is that, PMK is on per Authenticator MAC address. If the station is re-associated with new WTP (different MAC address), then it would not even send PMKID of old AP. If there is no PMKID found in reassoc event, AC would start with full 802.1x authentication. If the station is reassociating with an AP, to which it already established PMK before, then station sends PMKID and in that case only 4 way key handshake is requried to get the PTK. With respect to this, I am not sure whether the statement 'If PMK is shared across multiple WTP' is valid. If not, the whole statement can be removed from the draft Regards Rama Krishna Prasad Ch. Rama Krishna Prasad Intoto Software(I) Pvt Ltd, Uma Plaza, Nagarjuna circle, Panjagutta. Hyderabad, AP Tel No:s 2335 8927/8928/8434 _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Thu Oct 21 12:49:06 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22072 for ; Thu, 21 Oct 2004 12:49:05 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 630041FCCE; Thu, 21 Oct 2004 12:49:06 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id B47711FCD0; Thu, 21 Oct 2004 12:49:02 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 07CE21FCD0 for ; Thu, 21 Oct 2004 12:48:11 -0400 (EDT) Received: from homebrew.trpz.com (66-7-225-40.cust.telepacific.net [66.7.225.40]) by mail.frascone.com (Postfix) with ESMTP id 12F371FCCE for ; Thu, 21 Oct 2004 12:48:09 -0400 (EDT) Received: from trpz.com (localhost.trpz.com [127.0.0.1]) by homebrew.trpz.com (8.13.1/8.13.1) with ESMTP id i9LGlIVJ044738; Thu, 21 Oct 2004 09:47:18 -0700 (PDT) (envelope-from dharkins@trpz.com) Message-Id: <200410211647.i9LGlIVJ044738@homebrew.trpz.com> To: Chunduru Rama Krishna Prasad Cc: capwap@frascone.com Subject: Re: [Capwap] Important: please provide input on comment resolution for CAPWAP Taxonomy draft In-Reply-To: Your message of "Thu, 21 Oct 2004 14:56:37 +0530." <5.1.0.14.0.20041021145529.00a8db30@172.16.1.10> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <44736.1098377238.1@trpz.com> From: Dan Harkins X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Thu, 21 Oct 2004 09:47:18 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Strictly speaking the PMK is shared between the supplicant and the authentication server, not the authenticator. There are no MAC addresses bound to the PMK or used in the derivation of the PMK. As the person who got PMK caching and PMKIDs into the 802.11i draft let me explain the steps we went through: - first motion was to indicate the ability of a STA to do "PMK caching" in an associate request. If the authenticator had a cached PMK for the STA it would respond with the 1st message of the 4way handshake, otherwise it would respond with an 802.1x encapsulated EAP Identity request. That enabled the functionality you describe below-- "the station is reassociating with an AP to with it already established the PMK before..." It prevented a STA in a difficult RF environment from ping-ponging back and forth between APs and hammering an authentication server. - it soon became apparent that an authenticator may have multiple PMKs for a particular STA in its cache. How? Via something like a pro-active key pushing mechanism using neighbor graphs (Bill Arbaugh presented this idea). So the next motion was to name PMKs with a PMKID to indicate which PMK a STA is asserting in its associate request. This eliminated the ambiguity. So the very reason that we have PMKIDs, and not just blind assertions of a cached PMK, is because the PMK may be used to derive a PTK for multiple APs. The statement "If PMK is shared across multiple WTPs" is, indeed, valid. Addressing Russ's comment, the PMK is already leaked because it is given to the authenticator by the authentication server. When discussing "the number of other people who know my secret" there are 3 possible values: 0, 1 and infinity. If 0 other people know your secret there are certain cryptographic properties associated with that state. If 1 other person knows your secret there are other cryptographic properties associated with that state (message source authentication for instance), but if more than 1 person knows your secret then it doesn't matter if it's 2 or 22, the cryptographic properties are the same (it is possible for someone to impersonate you, forge your messages, read your messages, etc). Of course you can say that in the 802.11i case the authenticator is "trusted" and therefore it's OK for the authentication server to leak the secret to the authenticator (and have 3 people know the secret). OK, fine. The other AP is also "trusted" to have the PMK so now 4 people know the secret (or 5 "trusted" people or 10 "trusted" people). Nothing changed. In the case of a switch hosting multiple APs the switch is the authenticator and the APs are merely tentacles of the same octopus. The PMK isn't shared among the APs, it resides on the switch. There is even one company I know of (I won't name it but it shouldn't be difficult to guess) in which the switch plays the role of the authentication server so the PMK is known only by the switch and the STA. This "PMK sharing" situation is even MORE secure than the traditional deployment where a STA establishes a PMK with a RADIUS server and that PMK is leaked to an AP. Dan. On Thu, 21 Oct 2004 14:56:37 +0530 you wrote > hi all, > > I am not sure, I am right on this. My impression is that, PMK is on per > Authenticator MAC address. > If the station is re-associated with new WTP (different MAC address), then > it would not even send > PMKID of old AP. If there is no PMKID found in reassoc event, AC would > start with full 802.1x > authentication. If the station is reassociating with an AP, to which it > already established PMK before, > then station sends PMKID and in that case only 4 way key handshake is > requried to get the PTK. > With respect to this, I am not sure whether the statement > 'If PMK is shared across multiple WTP' is valid. If not, the whole > statement can be removed > from the draft > > Regards > Rama Krishna Prasad > > > > Ch. Rama Krishna Prasad > Intoto Software(I) Pvt Ltd, > Uma Plaza, Nagarjuna circle, > Panjagutta. Hyderabad, AP > Tel No:s 2335 8927/8928/8434 > > _______________________________________________ > Capwap mailing list > Capwap@frascone.com > http://mail.frascone.com/mailman/listinfo/capwap _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Thu Oct 21 16:40:09 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22000 for ; Thu, 21 Oct 2004 16:40:08 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 891391FCB4; Thu, 21 Oct 2004 16:40:06 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 066C41FCCE; Thu, 21 Oct 2004 16:40:02 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id D91EB1FCCE for ; Thu, 21 Oct 2004 16:39:37 -0400 (EDT) Received: from hermes.jf.intel.com (fmr05.intel.com [134.134.136.6]) by mail.frascone.com (Postfix) with ESMTP id 2E43A1FCB4 for ; Thu, 21 Oct 2004 16:39:35 -0400 (EDT) Received: from talaria.jf.intel.com (talaria.jf.intel.com [10.7.209.7]) by hermes.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-outer.mc,v 1.15 2004/01/30 18:16:28 root Exp $) with ESMTP id i9LKg9ed020627; Thu, 21 Oct 2004 20:42:10 GMT Received: from orsmsxvs040.jf.intel.com (orsmsxvs040.jf.intel.com [192.168.65.206]) by talaria.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.11 2004/07/29 22:51:53 root Exp $) with SMTP id i9LKUQQK016350; Thu, 21 Oct 2004 20:31:59 GMT Received: from orsmsx332.amr.corp.intel.com ([192.168.65.60]) by orsmsxvs040.jf.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004102113381210657 ; Thu, 21 Oct 2004 13:38:12 -0700 Received: from orsmsx408.amr.corp.intel.com ([192.168.65.52]) by orsmsx332.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 21 Oct 2004 13:38:12 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Capwap] WG Review: Recharter of Control and Provisioning of Wireless Access Points (capwap) Message-ID: <2AF68A477DD44C4EBCBE338C24E7A9EE0279ED83@orsmsx408> Thread-Topic: [Capwap] WG Review: Recharter of Control and Provisioning of Wireless Access Points (capwap) Thread-Index: AcS21GERIqOv+FbcSgqLbhh+7XCFHwA2R1NA From: "Yang, Lily L" To: , Cc: , "Mahalingam Mani" , "Dorothy Gellert" X-OriginalArrivalTime: 21 Oct 2004 20:38:12.0896 (UTC) FILETIME=[E268CA00:01C4B7AD] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Thu, 21 Oct 2004 13:38:11 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: quoted-printable I am glad to see that the new charter is willing to at least consider extensibility to other radio access technology as a plus, while not being required to work on other radio technology within this new charter. I think many people have asked for it. I am happy to see it being reflected in the new charter wording. -----Original Message----- From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On Behalf Of The IESG Sent: Wednesday, October 20, 2004 11:41 AM To: IETF-Announce@ietf.org Cc: capwap@frascone.com; Mahalingam Mani; Dorothy Gellert Subject: [Capwap] WG Review: Recharter of Control and Provisioning of Wireless Access Points (capwap) A modified charter has been submitted for the Control and Provisioning of=20 Wireless Access Points (capwap) working group in the Operations and Management=20 Area of the IETF. The IESG has not made any determination as yet. The following description was submitted, and is provided for informational purposes only. =20 Please send your comments to the IESG mailing list (iesg@ietf.org)=20 by October 27th. Control and Provisioning of Wireless Access Points (capwap) ----------------------------------------------------------- Current Status: Active Working Group Description: The original CAPWAP WG charter included drafting a problem statement and a taxonomy of architectures. The new charter of the CAPWAP WG proposes building upon the original charter and developing a CAPWAP protocol to provide interoperability among WLAN backend architectures. The intent of the CAPWAP protocol is to facilitate control, management and provisioning of WLAN Termination Points (WTPs) specifying the services, functions and resources relating to 802.11 WLAN Termination Points in order to allow for interoperable implementations of WTPs and ACs. The revised CAPWAP WG will reference two classes of the Centralized WLAN Architecture family, namely the Local MAC and the Split MAC, as described in the CAPWAP Architecture Taxonomy draft. The protocol will define the CAPWAP control plane including the primitives to control data access. An effective Centralized CAPWAP Architecture impacts how WLAN data traffic is managed over the backend network. This implies the abilitiy to control how data is forwarded by negotiating existng data encapsulation mechanisms and specifying data payload formats in order to ensure interoperability between CAPWAP vendors. No other specifications of the CAPWAP data plane are within the scope of this charter. The CAPWAP WG will strive for extensibility in the protocol design to favor future applicability to other access technologies, especially IEEE 802.16. While accommodation of any access technology other than IEEE 802.11 is not required for successful completion, there are clear deployment advantages if a wide range of access technologies are accommodated. In summary, the primary goals of the group will be: 1. Defining a set of Objectives based on the architecture taxonomy work that lists the requirements for an interoperable CAPWAP protocol. In addition, the WG will incorporate requirements derived from the inputs provided by Enterprise and (hotspot) Providers based on the WLAN deployment challenges addressed by CAPWAP architecture. This document will: a. include objectives to address problems described in the CAPWAP Problem statement document b. Describe each objective, its benefit to the protocol and how it satisfies the problem statement. c. Prioritize and classify the objectives into 3 categories: i. Mandatory and Accepted ii. Desirable iii. Rejected d. Undergo review in IEEE 802 as needed This should result in the first WG Last Call for Objectives draft. To avoid requirements bloat and stalemate, the WG has a hard deadline on the Objectives phase. The WG MUST reach WG consensus on the objectives draft by Feb 2005. This is for several reasons: * We must send this for review to IEEE at that time. * We must have a reasonably stable set of objectives so that candidate submissions are aware of the objectives to be met. The 2nd WG Last Call (in April) for the objectives draft is to ensure that the WG has consensus on any changes that may result from IEEE and expert review. So it is not the intention that the WG keeps adding new Objectives after Feb 2005. If the WG cannot reach consensus on the Objectives draft by the May 2005 milestone to the IESG, the WG will close. 2. Evaluating a set of candidate proposals that include existing IETF protocols and any proposals leading to the selection of a protocol on which to base the CAPWAP standard. 3. Developing a CAPWAP protocol standard that meets the Mandatory and Accepted objectives from the Evaluation draft and contains the minimal set of feature needed to control and provision WLAN Access Points. Specifically The CAPWAP protocol document will address the following considerations: a. Architecture b. Operations c. Security d. Network Management e. Scalability f. Performance 4. A MIB Document to support the CAPWAP protocol. In addition, the CAPWAP WG will maintain its Liaison with the IEEE to ensure consistency of its work with the IEEE 802.11 Standard. Deliverables: * Objectives/Criteria Document for CAPWAP protocol * Protocol evaluation and base protocol selection document * CAPWAP Protocol standard * MIB support standard=20 _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Thu Oct 21 16:56:05 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24704 for ; Thu, 21 Oct 2004 16:56:04 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id C87F91FCD8; Thu, 21 Oct 2004 16:56:05 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 917AA1FCCE; Thu, 21 Oct 2004 16:56:02 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id C97AC1FCCE for ; Thu, 21 Oct 2004 16:55:49 -0400 (EDT) Received: from ihemail2.lucent.com (ihemail2.lucent.com [192.11.222.163]) by mail.frascone.com (Postfix) with ESMTP id 9A2301FCB4 for ; Thu, 21 Oct 2004 16:55:47 -0400 (EDT) Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by ihemail2.lucent.com (8.12.11/8.12.11) with ESMTP id i9LKtiFe017585 for ; Thu, 21 Oct 2004 15:55:44 -0500 (CDT) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2657.72) id <4M32G8RM>; Thu, 21 Oct 2004 22:55:43 +0200 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B15503C79DCB@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: "'Yang, Lily L'" , iesg@ietf.org Cc: capwap@frascone.com Subject: RE: [Capwap] WG Review: Recharter of Control and Provisioning of Wireless Access Points (capwap) MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Thu, 21 Oct 2004 22:55:40 +0200 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Lily writes: > > I am glad to see that the new charter is willing to at least consider > extensibility to other radio access technology as a plus, while not > being required to work on other radio technology within this new > charter. I think many people have asked for it. I am happy to see it > being reflected in the new charter wording. > Be aware, that we should make sure to not BLOCK/DELAY the proposed work in the new charter if some aspects of "other radio technology" are not inline with what we need for 802.11. I think the text is clear on that too, so I just want to re-emphasize that. Bert _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Thu Oct 21 17:36:06 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03685 for ; Thu, 21 Oct 2004 17:36:05 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 2CD6C1FD3B; Thu, 21 Oct 2004 17:36:06 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id D5DF41FCD5; Thu, 21 Oct 2004 17:36:02 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 6E29B1FCD5 for ; Thu, 21 Oct 2004 17:35:52 -0400 (EDT) Received: from hermes.jf.intel.com (fmr05.intel.com [134.134.136.6]) by mail.frascone.com (Postfix) with ESMTP id 8BC291FCCE for ; Thu, 21 Oct 2004 17:35:50 -0400 (EDT) Received: from talaria.jf.intel.com (talaria.jf.intel.com [10.7.209.7]) by hermes.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-outer.mc,v 1.15 2004/01/30 18:16:28 root Exp $) with ESMTP id i9LLdeed015909; Thu, 21 Oct 2004 21:39:40 GMT Received: from orsmsxvs040.jf.intel.com (orsmsxvs040.jf.intel.com [192.168.65.206]) by talaria.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.11 2004/07/29 22:51:53 root Exp $) with SMTP id i9LLSTQE024394; Thu, 21 Oct 2004 21:29:30 GMT Received: from orsmsx332.amr.corp.intel.com ([192.168.65.60]) by orsmsxvs040.jf.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004102114354421949 ; Thu, 21 Oct 2004 14:35:44 -0700 Received: from orsmsx408.amr.corp.intel.com ([192.168.65.52]) by orsmsx332.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 21 Oct 2004 14:35:44 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Capwap] WG Review: Recharter of Control and Provisioning of Wireless Access Points (capwap) Message-ID: <2AF68A477DD44C4EBCBE338C24E7A9EE0279EEB1@orsmsx408> Thread-Topic: [Capwap] WG Review: Recharter of Control and Provisioning of Wireless Access Points (capwap) Thread-Index: AcS3sFifWU60YHn0RZykcniHYpY8PQABY2oA From: "Yang, Lily L" To: "Wijnen, Bert (Bert)" , Cc: X-OriginalArrivalTime: 21 Oct 2004 21:35:44.0962 (UTC) FILETIME=[EC004220:01C4B7B5] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Thu, 21 Oct 2004 14:35:43 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: quoted-printable Yes, that makes sense. -----Original Message----- From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com]=20 Sent: Thursday, October 21, 2004 1:56 PM To: Yang, Lily L; iesg@ietf.org Cc: capwap@frascone.com Subject: RE: [Capwap] WG Review: Recharter of Control and Provisioning of Wireless Access Points (capwap) Lily writes: >=20 > I am glad to see that the new charter is willing to at least consider > extensibility to other radio access technology as a plus, while not > being required to work on other radio technology within this new > charter. I think many people have asked for it. I am happy to see it > being reflected in the new charter wording. >=20 Be aware, that we should make sure to not BLOCK/DELAY the proposed work in the new charter if some aspects of "other radio technology" are not inline with what we need for 802.11. I think the text is clear on that too, so I just want to re-emphasize that. Bert _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Thu Oct 21 20:48:15 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA15898 for ; Thu, 21 Oct 2004 20:47:44 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 3DE021FCB4; Thu, 21 Oct 2004 20:47:16 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 7E1761FCD6; Thu, 21 Oct 2004 20:47:12 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 1EF7C1FCD6 for ; Thu, 21 Oct 2004 20:46:48 -0400 (EDT) Received: from mailsrv.psl.com.sg (mailsrv.psl.com.sg [202.14.153.3]) by mail.frascone.com (Postfix) with ESMTP id 38C4A1FCB4 for ; Thu, 21 Oct 2004 20:46:12 -0400 (EDT) Received: from Palpatine ([10.81.113.73]) by mailsrv.psl.com.sg (8.13.1/8.13.1) with ESMTP id i9M0fRBv027007; Fri, 22 Oct 2004 08:41:35 +0800 (SGT) From: "Cheng Hong" To: "'Mani, Mahalingam (Mahalingam)'" , Cc: "'Saravanan Govindan'" Subject: RE: [Capwap] A draft on Objectives. Organization: Panasonic Singapore Laboratories Message-ID: <030501c4b7d0$45968730$4971510a@Palpatine> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0306_01C4B813.53B9C730" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 In-Reply-To: Importance: Normal X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Fri, 22 Oct 2004 08:44:16 +0800 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) This is a multi-part message in MIME format. ------=_NextPart_000_0306_01C4B813.53B9C730 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Mani and all, =20 Thanks for making the draft available on the capwap site. The draft-govindan-capwap-objectives-00.txt is now also available in the = IETF repository at:=20 =20 http://www.ietf.org/internet-drafts/draft-govindan-capwap-objectives-00.t= xt (it managed to meet the 18th Oct deadline as an individual draft). =20 Thanks and Regards Cheng=20 =20 -----Original Message----- From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On = Behalf Of Mani, Mahalingam (Mahalingam) Sent: Thursday, October 21, 2004 9:56 PM To: capwap@frascone.com Subject: RE: [Capwap] A draft on Objectives. Now there are two individual drafts submitted: again - for review and comments. They are not in IETF repository (too late for that), nor this WG item = (not yet chartered to consider). =20 Both are accessible here: http://www.capwap.org/objs/ =20 the second one here is from Zhou et al. =20 (thanks to Dave Frascone for putting them up on CAPWAP website). =20 -mani _____ =20 From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On = Behalf Of Mani, Mahalingam (Mahalingam) Sent: Tuesday, October 19, 2004 6:45 AM To: capwap@frascone.com Subject: [Capwap] A draft on Objectives. Importance: High =20 Saravanan Govindan has submitted a draft in response to a call for Objectives (in connection with the recharter discussions in ietf60 @San Diego and on the list). =20 I have had it placed in the capwap website: http://www.capwap.org/draft-govindan-capwap-objectives-00.txt =20 Note that with this being out of scope for this phase of WG (and this = phase having drawn/drawing=20 to a close) this is a courtesy posting to facilitate discussions. =20 [It arrived too late for submission as an individual -00 I-D to IETF repository]. =20 Feel free to review & comment. =20 -mani =20 ------=_NextPart_000_0306_01C4B813.53B9C730 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message
Hi=20 Mani and all,
 
Thanks for making the draft available on the capwap = site. =20 The draft-govindan-capwap-objectives-00.txt is now = also available=20 in the IETF repository at:

http://www.ietf.org/internet-drafts/draft-govindan-capwap-object= ives-00.txt      (it managed to meet = the 18th=20 Oct deadline as an individual draft).

 

Thanks and = Regards

Cheng

 

<= /DIV>
-----Original Message-----
From:=20 capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On = Behalf Of=20 Mani, Mahalingam (Mahalingam)
Sent: Thursday, October = 21, 2004=20 9:56 PM
To: capwap@frascone.com
Subject: RE: = [Capwap] A=20 draft on Objectives.

Now there = are=20  two individual drafts submitted: again – for review and=20 comments.

They are = not in IETF=20 repository (too late for that), nor this WG item (not yet chartered to = consider).

 

Both are = accessible=20 here:

http://www.capwap.org/objs/=

 

the second = one here=20 is from Zhou et al.

 

(thanks to = Dave=20 Frascone for putting them up on CAPWAP = website).

 

-mani

From:=20 capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On Behalf Of Mani, Mahalingam (Mahalingam)
Sent: Tuesday, October 19, 2004 = 6:45=20 AM
To:=20 capwap@frascone.com
Subject:=20 [Capwap] A draft on Objectives.
Importance:=20 High

 

Saravanan Govindan has = submitted a=20 draft in response to a call for Objectives (in connection=20 with

the recharter = discussions in=20 ietf60 @San Diego and on the=20 list).

 

I have had it placed in = the capwap=20 website:

ht= tp://www.capwap.org/draft-govindan-capwap-objectives-00.txt

 

Note that with this = being out of=20 scope for this phase of WG (and this phase having drawn/drawing=20

to a close) this is a = courtesy=20 posting to facilitate discussions.

 

[It arrived too late for = submission as an individual -00 I-D to IETF=20 repository].

 

Feel free to review = &=20 comment.

 

-mani

 

------=_NextPart_000_0306_01C4B813.53B9C730-- _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Sun Oct 24 23:34:10 2004 Received: from mail.frascone.com (postfix@[204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA25673 for ; Sun, 24 Oct 2004 23:34:09 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id BCE481FC0E; Sun, 24 Oct 2004 23:34:07 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 558401FC68; Sun, 24 Oct 2004 23:34:04 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 55DB01FC68 for ; Sun, 24 Oct 2004 23:33:08 -0400 (EDT) Received: from brahma.intotoind.com (ip-66-80-10-146.dsl.sca.megapath.net [66.80.10.146]) by mail.frascone.com (Postfix) with ESMTP id AFF5C1FC0E for ; Sun, 24 Oct 2004 23:33:05 -0400 (EDT) Received: from rkp.intoto.com (1mc70.intotoind.com [172.16.1.70]) by brahma.intotoind.com (8.12.11/8.12.8) with ESMTP id i9P3WvNi019662; Mon, 25 Oct 2004 09:02:57 +0530 Message-Id: <5.1.0.14.0.20041025091526.00a8dac0@172.16.1.10> X-Sender: rkp@172.16.1.10 X-Mailer: QUALCOMM Windows Eudora Version 5.1 To: Dan Harkins From: Chunduru Rama Krishna Prasad Subject: Re: [Capwap] Important: please provide input on comment resolution for CAPWAP Taxonomy draft Cc: capwap@frascone.com In-Reply-To: <200410211647.i9LGlIVJ044738@homebrew.trpz.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Scanned-By: MIMEDefang 2.41 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Mon, 25 Oct 2004 09:16:18 +0530 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Hi, Does it mean that, 802.11i supplicants reuse the same PMK, even though they talk to new BSSID (WTP)? If it is true in majority of supplicant implemenations, then it reduces one configuration element in our WTP/AC implementation :-). If that is the case, it also helps in voice quality (as it does not require full EAP authentication), when the station moves from one WTP to another new WTP belonging to same ESS, controlled by AC. Thanks Rama Krishna Prasad At 09:47 AM 10/21/2004 -0700, Dan Harkins wrote: > Strictly speaking the PMK is shared between the supplicant and the >authentication server, not the authenticator. There are no MAC addresses >bound to the PMK or used in the derivation of the PMK. > > As the person who got PMK caching and PMKIDs into the 802.11i draft >let me explain the steps we went through: > > - first motion was to indicate the ability of a STA to do "PMK caching" > in an associate request. If the authenticator had a cached PMK for > the STA it would respond with the 1st message of the 4way handshake, > otherwise it would respond with an 802.1x encapsulated EAP Identity > request. That enabled the functionality you describe below-- "the > station is reassociating with an AP to with it already established > the PMK before..." It prevented a STA in a difficult RF environment > from ping-ponging back and forth between APs and hammering an > authentication server. > > - it soon became apparent that an authenticator may have multiple PMKs > for a particular STA in its cache. How? Via something like a pro-active > key pushing mechanism using neighbor graphs (Bill Arbaugh presented > this idea). So the next motion was to name PMKs with a PMKID to > indicate which PMK a STA is asserting in its associate request. > This eliminated the ambiguity. > >So the very reason that we have PMKIDs, and not just blind assertions of >a cached PMK, is because the PMK may be used to derive a PTK for >multiple APs. The statement "If PMK is shared across multiple WTPs" is, >indeed, valid. > > Addressing Russ's comment, the PMK is already leaked because it is >given to the authenticator by the authentication server. When discussing >"the number of other people who know my secret" there are 3 possible >values: 0, 1 and infinity. If 0 other people know your secret there are >certain cryptographic properties associated with that state. If 1 other >person knows your secret there are other cryptographic properties >associated with that state (message source authentication for instance), >but if more than 1 person knows your secret then it doesn't matter if >it's 2 or 22, the cryptographic properties are the same (it is possible >for someone to impersonate you, forge your messages, read your >messages, etc). > > Of course you can say that in the 802.11i case the authenticator is >"trusted" and therefore it's OK for the authentication server to leak >the secret to the authenticator (and have 3 people know the secret). >OK, fine. The other AP is also "trusted" to have the PMK so now 4 people >know the secret (or 5 "trusted" people or 10 "trusted" people). Nothing >changed. > > In the case of a switch hosting multiple APs the switch is the >authenticator and the APs are merely tentacles of the same octopus. The >PMK isn't shared among the APs, it resides on the switch. There is even >one company I know of (I won't name it but it shouldn't be difficult to >guess) in which the switch plays the role of the authentication server >so the PMK is known only by the switch and the STA. This "PMK sharing" >situation is even MORE secure than the traditional deployment where a STA >establishes a PMK with a RADIUS server and that PMK is leaked to an AP. > > Dan. > >On Thu, 21 Oct 2004 14:56:37 +0530 you wrote > > hi all, > > > > I am not sure, I am right on this. My impression is that, PMK is on per > > Authenticator MAC address. > > If the station is re-associated with new WTP (different MAC address), then > > it would not even send > > PMKID of old AP. If there is no PMKID found in reassoc event, AC would > > start with full 802.1x > > authentication. If the station is reassociating with an AP, to which it > > already established PMK before, > > then station sends PMKID and in that case only 4 way key handshake is > > requried to get the PTK. > > With respect to this, I am not sure whether the statement > > 'If PMK is shared across multiple WTP' is valid. If not, the whole > > statement can be removed > > from the draft > > > > Regards > > Rama Krishna Prasad > > > > > > > > Ch. Rama Krishna Prasad > > Intoto Software(I) Pvt Ltd, > > Uma Plaza, Nagarjuna circle, > > Panjagutta. Hyderabad, AP > > Tel No:s 2335 8927/8928/8434 > > > > _______________________________________________ > > Capwap mailing list > > Capwap@frascone.com > > http://mail.frascone.com/mailman/listinfo/capwap Ch. Rama Krishna Prasad Intoto Software(I) Pvt Ltd, Uma Plaza, Nagarjuna circle, Panjagutta. Hyderabad, AP Tel No:s 2335 8927/8928/8434 _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Mon Oct 25 00:43:21 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA00392 for ; Mon, 25 Oct 2004 00:43:10 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id A11EB1FC0E; Mon, 25 Oct 2004 00:43:07 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id DA01C1FC68; Mon, 25 Oct 2004 00:43:03 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 000A81FC68 for ; Mon, 25 Oct 2004 00:42:32 -0400 (EDT) Received: from tierw.net.avaya.com (tierw.net.avaya.com [198.152.13.100]) by mail.frascone.com (Postfix) with ESMTP id 0AFDC1FC0E for ; Mon, 25 Oct 2004 00:42:30 -0400 (EDT) Received: from tierw.net.avaya.com (localhost [127.0.0.1]) by tierw.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id i9P4YVBV007274 for ; Sun, 24 Oct 2004 23:34:32 -0500 (EST) Received: from cof110avexu1.global.avaya.com (h135-9-6-16.avaya.com [135.9.6.16]) by tierw.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id i9P4YUBV007267 for ; Sun, 24 Oct 2004 23:34:30 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C4BA4D.07F741BF" Message-ID: Thread-Topic: Related work: IEEE 802.11v & IEEE 802.1 Thread-Index: AcS6TQOtGi1YUiraQeCEvDoC24e46g== X-Priority: 1 Priority: Urgent Importance: high From: "Mani, Mahalingam (Mahalingam)" To: X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [Capwap] Related work: IEEE 802.11v & IEEE 802.1 Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Sun, 24 Oct 2004 22:42:28 -0600 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) This is a multi-part message in MIME format. ------_=_NextPart_001_01C4BA4D.07F741BF Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable IEEE 802.11v =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D IEEE 802.11 WG is considering approval of WNM (WLAN Network Management) SG study group Proposal to form a Task Group to standardize WLAN Management (Control & Configuration)=20 as a Task Group (802.11v). =20 11v has definite relevance to CAPWAP. =20 WNM provides the complement of 802.11k (Radio Resource Measurements - allowing, say, an AC to monitor the set of APs and clients in its domain). 802.11v is about Radio Resource Management - control and provisioning of APs in its domain from individual standpoint. This means CAPWAP Can theoretically make use of 11v primitives (used to control aspects of Radio Resource) to realize the CAPWAP protocol. Of course, 11v is more than merely control of radio resource. =20 The proposed 'charter' (PAR & 5 criteria are available as documents in http://www.802wirelessworld.com =20 =20 11-04-0537-07-0wnm & 11-04-0684-01-0wnm =20 802.1 =3D=3D=3D=3D A work proposal for "Protocol-independent MAC enhancements for RF management of 802 wireless networks" in the recent October interim session of IEEE 802.1 has been presented. =20 http://www.ieee802.org/1/files/public/docs2004/Backes-RF-Mgmt.pdf =20 It is not clear how this may be mapped to CAPWAP work; however, among the many Control and configuration aspects that CAPWAP can facilitate - RF management is one. =20 Apparently this aspect is also being discussed in some form in the AP Functional Description AdHoc committee (IEEE 802.11 APF AHC) - a committee triggered in IEEE 802.11 WG - in part to address the AP functional requirements for CAPWAP. =20 -mani ------_=_NextPart_001_01C4BA4D.07F741BF Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

IEEE = 802.11v

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D

IEEE 802.11 WG is = considering approval of WNM (WLAN Network Management) SG study = group

Proposal to form a Task = Group to standardize WLAN Management (Control & Configuration) =

as a Task Group = (802.11v).

 

11v has definite relevance = to CAPWAP.

 

WNM provides the complement = of 802.11k (Radio Resource Measurements – allowing, say, an AC to = monitor the set of APs and clients in its domain). 802.11v is about Radio = Resource Management – control and provisioning of APs in its domain from individual standpoint. This means CAPWAP

Can theoretically make use = of 11v primitives (used to control aspects of Radio Resource) to realize the = CAPWAP protocol. Of course, 11v is more than merely control of radio = resource.

 

The proposed = ‘charter’ (PAR & 5 criteria are available as documents in http://www.802wirelessworld.com=

 

11-04-0537-07-0wnm & = 11-04-0684-01-0wnm

 

802.1

=3D=3D=3D=3D

A work proposal for “Protocol-independent MAC enhancements for RF management of 802 wireless networks” in the = recent October interim session of IEEE 802.1 has been = presented.

 

http://www.ieee802.org/1/files/public/docs2004/Backes-RF-Mgmt.pdf

 

It is not clear how this may be mapped to CAPWAP = work; however, among the many

Control and configuration aspects that CAPWAP can = facilitate – RF management is one.

 

Apparently this aspect is also being discussed in = some form in the AP Functional Description AdHoc committee (IEEE 802.11 APF AHC) = – a committee triggered in IEEE 802.11 WG - in = part

to address the AP functional requirements for = CAPWAP.

 

-mani

------_=_NextPart_001_01C4BA4D.07F741BF-- _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Mon Oct 25 02:42:08 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA24013 for ; Mon, 25 Oct 2004 02:42:07 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 34B771FC0E; Mon, 25 Oct 2004 02:42:07 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id D556D1FC72; Mon, 25 Oct 2004 02:42:03 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 18F281FC72 for ; Mon, 25 Oct 2004 02:41:22 -0400 (EDT) Received: from homebrew.trpz.com (66-7-225-40.cust.telepacific.net [66.7.225.40]) by mail.frascone.com (Postfix) with ESMTP id 18CD61FC0E for ; Mon, 25 Oct 2004 02:41:20 -0400 (EDT) Received: from trpz.com (localhost.trpz.com [127.0.0.1]) by homebrew.trpz.com (8.13.1/8.13.1) with ESMTP id i9P6eTJJ076920; Sun, 24 Oct 2004 23:40:29 -0700 (PDT) (envelope-from dharkins@trpz.com) Message-Id: <200410250640.i9P6eTJJ076920@homebrew.trpz.com> To: Chunduru Rama Krishna Prasad Cc: capwap@frascone.com Subject: Re: [Capwap] Important: please provide input on comment resolution for CAPWAP Taxonomy draft In-Reply-To: Your message of "Mon, 25 Oct 2004 09:16:18 +0530." <5.1.0.14.0.20041025091526.00a8dac0@172.16.1.10> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <76918.1098686429.1@trpz.com> From: Dan Harkins X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Sun, 24 Oct 2004 23:40:29 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) What it means is that when a supplicant associates to an AP that it has never been associated to before it is permissible for a it to indicate a possession of a PMK (through a PMKID in an associate request) that was derived from associating to a different AP. What a majority of supplicant implementations do is a completely different story because it is also permissible for a supplicant to be 802.11i compliant and have a PMK cache of size zero-- that is, never cache a PMK and require a full 802.1X/EAP authentication every time it associates. I cannot speak to a majority of supplicant implementations. All I can say is that they can take advantaged of a cached PMK between multiple APs. If a supplicant indicates possession of a PMK and the authenticator has the PMK it wins, if the authenticator doesn't then it's just as if the supplicant didn't identify the PMK. It would seem to make sense that given such a situation a supplicant would aggressively assert possession of PMKs when handing off. You're right. It will help in voice applications when the client hands off from AP to AP. That's the whole idea. Dan. On Mon, 25 Oct 2004 09:16:18 +0530 you wrote > Hi, > Does it mean that, 802.11i supplicants reuse the same PMK, even though they > talk to new BSSID (WTP)? > If it is true in majority of supplicant implemenations, then it reduces one > configuration element in our WTP/AC implementation :-). > If that is the case, it also helps in voice quality (as it does not require > full EAP authentication), when the station moves from one > WTP to another new WTP belonging to same ESS, controlled by AC. > Thanks > Rama Krishna Prasad > > At 09:47 AM 10/21/2004 -0700, Dan Harkins wrote: > > Strictly speaking the PMK is shared between the supplicant and the > >authentication server, not the authenticator. There are no MAC addresses > >bound to the PMK or used in the derivation of the PMK. > > > > As the person who got PMK caching and PMKIDs into the 802.11i draft > >let me explain the steps we went through: > > > > - first motion was to indicate the ability of a STA to do "PMK caching" > > in an associate request. If the authenticator had a cached PMK for > > the STA it would respond with the 1st message of the 4way handshake, > > otherwise it would respond with an 802.1x encapsulated EAP Identity > > request. That enabled the functionality you describe below-- "the > > station is reassociating with an AP to with it already established > > the PMK before..." It prevented a STA in a difficult RF environment > > from ping-ponging back and forth between APs and hammering an > > authentication server. > > > > - it soon became apparent that an authenticator may have multiple PMKs > > for a particular STA in its cache. How? Via something like a pro-active > > key pushing mechanism using neighbor graphs (Bill Arbaugh presented > > this idea). So the next motion was to name PMKs with a PMKID to > > indicate which PMK a STA is asserting in its associate request. > > This eliminated the ambiguity. > > > >So the very reason that we have PMKIDs, and not just blind assertions of > >a cached PMK, is because the PMK may be used to derive a PTK for > >multiple APs. The statement "If PMK is shared across multiple WTPs" is, > >indeed, valid. > > > > Addressing Russ's comment, the PMK is already leaked because it is > >given to the authenticator by the authentication server. When discussing > >"the number of other people who know my secret" there are 3 possible > >values: 0, 1 and infinity. If 0 other people know your secret there are > >certain cryptographic properties associated with that state. If 1 other > >person knows your secret there are other cryptographic properties > >associated with that state (message source authentication for instance), > >but if more than 1 person knows your secret then it doesn't matter if > >it's 2 or 22, the cryptographic properties are the same (it is possible > >for someone to impersonate you, forge your messages, read your > >messages, etc). > > > > Of course you can say that in the 802.11i case the authenticator is > >"trusted" and therefore it's OK for the authentication server to leak > >the secret to the authenticator (and have 3 people know the secret). > >OK, fine. The other AP is also "trusted" to have the PMK so now 4 people > >know the secret (or 5 "trusted" people or 10 "trusted" people). Nothing > >changed. > > > > In the case of a switch hosting multiple APs the switch is the > >authenticator and the APs are merely tentacles of the same octopus. The > >PMK isn't shared among the APs, it resides on the switch. There is even > >one company I know of (I won't name it but it shouldn't be difficult to > >guess) in which the switch plays the role of the authentication server > >so the PMK is known only by the switch and the STA. This "PMK sharing" > >situation is even MORE secure than the traditional deployment where a STA > >establishes a PMK with a RADIUS server and that PMK is leaked to an AP. > > > > Dan. > > > >On Thu, 21 Oct 2004 14:56:37 +0530 you wrote > > > hi all, > > > > > > I am not sure, I am right on this. My impression is that, PMK is on per > > > Authenticator MAC address. > > > If the station is re-associated with new WTP (different MAC address), the >n > > > it would not even send > > > PMKID of old AP. If there is no PMKID found in reassoc event, AC would > > > start with full 802.1x > > > authentication. If the station is reassociating with an AP, to which it > > > already established PMK before, > > > then station sends PMKID and in that case only 4 way key handshake is > > > requried to get the PTK. > > > With respect to this, I am not sure whether the statement > > > 'If PMK is shared across multiple WTP' is valid. If not, the whole > > > statement can be removed > > > from the draft > > > > > > Regards > > > Rama Krishna Prasad > > > > > > > > > > > > Ch. Rama Krishna Prasad > > > Intoto Software(I) Pvt Ltd, > > > Uma Plaza, Nagarjuna circle, > > > Panjagutta. Hyderabad, AP > > > Tel No:s 2335 8927/8928/8434 > > > > > > _______________________________________________ > > > Capwap mailing list > > > Capwap@frascone.com > > > http://mail.frascone.com/mailman/listinfo/capwap > > Ch. Rama Krishna Prasad > Intoto Software(I) Pvt Ltd, > Uma Plaza, Nagarjuna circle, > Panjagutta. Hyderabad, AP > Tel No:s 2335 8927/8928/8434 > _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Mon Oct 25 10:16:10 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28236 for ; Mon, 25 Oct 2004 10:16:07 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 91C571FD64; Mon, 25 Oct 2004 10:16:07 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 13D8F1FC78; Mon, 25 Oct 2004 10:16:04 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 691EF1FC78 for ; Mon, 25 Oct 2004 10:15:57 -0400 (EDT) Received: from tierw.net.avaya.com (tierw.net.avaya.com [198.152.13.100]) by mail.frascone.com (Postfix) with ESMTP id 8BF5D1FC73 for ; Mon, 25 Oct 2004 10:15:55 -0400 (EDT) Received: from tierw.net.avaya.com (localhost [127.0.0.1]) by tierw.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id i9PE7thB000225 for ; Mon, 25 Oct 2004 09:07:56 -0500 (EST) Received: from IS0004AVEXU1.global.avaya.com (h135-64-105-51.avaya.com [135.64.105.51]) by tierw.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id i9PE7khB029939 for ; Mon, 25 Oct 2004 09:07:48 -0500 (EST) content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C4BA9D.1BEC08AE" X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 Subject: RE: [Capwap] Related work: IEEE 802.11v & IEEE 802.1 Message-ID: Thread-Topic: Related work: IEEE 802.11v & IEEE 802.1 Thread-Index: AcS6TQOtGi1YUiraQeCEvDoC24e46gAT8QGA From: "Romascanu, Dan (Dan)" To: "Mani, Mahalingam (Mahalingam)" , X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Mon, 25 Oct 2004 16:15:41 +0200 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) This is a multi-part message in MIME format. ------_=_NextPart_001_01C4BA9D.1BEC08AE Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Mani, =20 I attended the interim meeting of IEEE 802.1. My understanding was that = the 802.1 RF management proposal was made on behalf of the 802.11 WG, = with the intent to avoid parallelism between 802.11v and other = activities, and suggesting to have this activity taken over by 802.1. = The probable outcome is a common meeting of 802.11v and 802.1 in San = Antonio to discuss these issues.=20 =20 Regards, Dan =20 -----Original Message----- From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com]On = Behalf Of Mani, Mahalingam (Mahalingam) Sent: 25 October, 2004 6:42 AM To: capwap@frascone.com Subject: [Capwap] Related work: IEEE 802.11v & IEEE 802.1 Importance: High IEEE 802.11v =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D IEEE 802.11 WG is considering approval of WNM (WLAN Network Management) = SG study group Proposal to form a Task Group to standardize WLAN Management (Control & = Configuration)=20 as a Task Group (802.11v). =20 11v has definite relevance to CAPWAP. =20 WNM provides the complement of 802.11k (Radio Resource Measurements - = allowing, say, an AC to monitor the set of APs and clients in its = domain). 802.11v is about Radio Resource Management - control and = provisioning of APs in its domain from individual standpoint. This means = CAPWAP Can theoretically make use of 11v primitives (used to control aspects of = Radio Resource) to realize the CAPWAP protocol. Of course, 11v is more = than merely control of radio resource. =20 The proposed 'charter' (PAR & 5 criteria are available as documents in = http://www.802wirelessworld.com =20 =20 11-04-0537-07-0wnm & 11-04-0684-01-0wnm =20 802.1 =3D=3D=3D=3D A work proposal for "Protocol-independent MAC enhancements for RF = management of 802 wireless networks" in the recent October interim = session of IEEE 802.1 has been presented. =20 http://www.ieee802.org/1/files/public/docs2004/Backes-RF-Mgmt.pdf =20 It is not clear how this may be mapped to CAPWAP work; however, among = the many Control and configuration aspects that CAPWAP can facilitate - RF = management is one. =20 Apparently this aspect is also being discussed in some form in the AP = Functional Description AdHoc committee (IEEE 802.11 APF AHC) - a = committee triggered in IEEE 802.11 WG - in part to address the AP functional requirements for CAPWAP. =20 -mani ------_=_NextPart_001_01C4BA9D.1BEC08AE Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Mani,
 
I = attended the interim=20 meeting of IEEE 802.1. My understanding was that the 802.1 RF = management=20 proposal was made on behalf of the 802.11 WG, with the intent to avoid=20 parallelism between 802.11v and other activities, and suggesting to = have=20 this activity taken over by 802.1. The probable outcome is a common = meeting of=20 802.11v and 802.1 in San Antonio to discuss these issues.=20
 

Regards,

Dan

 
-----Original Message-----
From: = capwap-admin@frascone.com=20 [mailto:capwap-admin@frascone.com]On Behalf Of Mani, Mahalingam = (Mahalingam)
Sent: 25 October, 2004 6:42 AM
To:=20 capwap@frascone.com
Subject: [Capwap] Related work: IEEE = 802.11v=20 & IEEE 802.1
Importance: High

IEEE=20 802.11v

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

IEEE 802.11 WG is = considering=20 approval of WNM (WLAN Network Management) SG study=20 group

Proposal to form a Task = Group to=20 standardize WLAN Management (Control & Configuration)=20

as a Task Group=20 (802.11v).

 

11v has definite = relevance to=20 CAPWAP.

 

WNM provides the = complement of=20 802.11k (Radio Resource Measurements – allowing, say, an AC to = monitor the set=20 of APs and clients in its domain). 802.11v is about Radio Resource = Management=20 – control and provisioning of APs in its domain from individual = standpoint.=20 This means CAPWAP

Can theoretically make = use of 11v=20 primitives (used to control aspects of Radio Resource) to realize the = CAPWAP=20 protocol. Of course, 11v is more than merely control of radio = resource.

 

The proposed = ‘charter’ (PAR &=20 5 criteria are available as documents in http://www.802wirelessworld.com=

 

11-04-0537-07-0wnm = &=20 11-04-0684-01-0wnm

 

802.1

=3D=3D=3D=3D

A work proposal for=20 “Protocol-independent MAC enhancements for RF management of 802 = wireless=20 networks” in the recent October interim session of IEEE 802.1 = has been=20 presented.

 

http://www.ieee802.org/1/files/public/docs2004/Backes-RF-Mgmt.pdf

 

It is not clear how this = may be=20 mapped to CAPWAP work; however, among the = many

Control and = configuration aspects=20 that CAPWAP can facilitate – RF management is=20 one.

 

Apparently this aspect = is also=20 being discussed in some form in the AP Functional Description AdHoc = committee=20 (IEEE 802.11 APF AHC) – a committee triggered in IEEE 802.11 WG = - in=20 part

to address the AP = functional=20 requirements for CAPWAP.

 

-mani

------_=_NextPart_001_01C4BA9D.1BEC08AE-- _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Mon Oct 25 12:34:07 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12144 for ; Mon, 25 Oct 2004 12:34:06 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id D90971FC64; Mon, 25 Oct 2004 12:34:07 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 5CE3F1FC71; Mon, 25 Oct 2004 12:34:04 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id BD0A91FC71 for ; Mon, 25 Oct 2004 12:33:19 -0400 (EDT) Received: from orsfmr001.jf.intel.com (fmr12.intel.com [134.134.136.15]) by mail.frascone.com (Postfix) with ESMTP id BF3AE1FC64 for ; Mon, 25 Oct 2004 12:33:16 -0400 (EDT) Received: from petasus.jf.intel.com (petasus.jf.intel.com [10.7.209.6]) by orsfmr001.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-outer.mc,v 1.15 2004/01/30 18:16:28 root Exp $) with ESMTP id i9PGXvQm019718; Mon, 25 Oct 2004 16:33:57 GMT Received: from orsmsxvs041.jf.intel.com (orsmsxvs041.jf.intel.com [192.168.65.54]) by petasus.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.11 2004/07/29 22:51:53 root Exp $) with SMTP id i9PGZQsT025855; Mon, 25 Oct 2004 16:36:55 GMT Received: from orsmsx332.amr.corp.intel.com ([192.168.65.60]) by orsmsxvs041.jf.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004102509330813859 ; Mon, 25 Oct 2004 09:33:08 -0700 Received: from orsmsx408.amr.corp.intel.com ([192.168.65.52]) by orsmsx332.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.0); Mon, 25 Oct 2004 09:33:07 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: FW: [Capwap] Important: please provide input on comment resolution for CAPWAP Taxonomy draft Message-ID: <2AF68A477DD44C4EBCBE338C24E7A9EE027DBBFD@orsmsx408> Thread-Topic: [Capwap] Important: please provide input on comment resolution for CAPWAP Taxonomy draft Thread-Index: AcS3jlLj/cK4zXrKS72DbXccLHdHEwA2mv5gAECRkEAAUSQscA== From: "Yang, Lily L" To: Cc: "Walker, Jesse" , X-OriginalArrivalTime: 25 Oct 2004 16:33:07.0867 (UTC) FILETIME=[4F2E6EB0:01C4BAB0] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Mon, 25 Oct 2004 09:33:05 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: quoted-printable I solicited input from Jesse Walker and Russ Housley on the issue of PMK sharing, and here is the response from Jesse. He agrees to let me forward this to the CAPWAP list. I also cc Jesse and Russ here. Since Russ posted the original comment in IESG review, and Jesse is the technical editor of 11i, I think it would be good that we keep them in the loop with regard this discussion. So please cc them in your email posting on this issue as they are not in the CAPWAP list. -----Original Message----- From: Walker, Jesse=20 Sent: Saturday, October 23, 2004 7:05 PM To: Yang, Lily L; 'housley@vigilsec.com' Subject: RE: [Capwap] Important: please provide input on comment resolution for CAPWAP Taxonomy draft=20 Lily, Dan's reasoning is invalid, unless he or someone else can produce a deterministic algorithm that allows the client to distinguish the following two cases: Case 1: AP1 and AP2 are classical access points. An attacker compromises AP1 and AP2 and moves the client's PMK from AP1 and AP2. Case 2: AP1 and AP2 are two light-weight access points that are part of the same switch S. The switch S uses the same PMK with both AP1 and AP2. If no one can demonstrate a deterministic algorithm the client can use to distinguish the two cases, then a properly implemented client will always assume its PMK has been compromised when it sees either case. I suspect no one can, because the client lacks the necessary state. It appears to me there are three possible solutions: a. The first is the necessary state is somehow delivered to the client in an attestable fashion. The only party that client trusts is the AAA server, so this implies a new binding protocol between the AAA server and the EAP Peer. b. The second is to define a new protocol that delivers the AP's authenticated identifier to the EAP Peer in an attestable fashion, and to change the 802.11i key confirmation handshake to use this identifier instead of the BSSID of the APs. c. The text that permits this usage should be removed. I believe possibilities (a) or (b) are the right way to address this issue. -- Jesse -----Original Message----- From: Yang, Lily L=20 Sent: Friday, October 22, 2004 12:03 PM To: Walker, Jesse; housley@vigilsec.com Subject: FW: [Capwap] Important: please provide input on comment resolution for CAPWAP Taxonomy draft=20 Importance: High Jesse and Russ -- CAPWAP WG has had some email discussion regarding the comment from you on PMK sharing. I don't think either of you are on the list, so I am forwarding to you this and I would like to hear what you think about these responses.=20 Lily -----Original Message----- From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On Behalf Of Dan Harkins Sent: Thursday, October 21, 2004 9:47 AM To: Chunduru Rama Krishna Prasad Cc: capwap@frascone.com Subject: Re: [Capwap] Important: please provide input on comment resolution for CAPWAP Taxonomy draft=20 Strictly speaking the PMK is shared between the supplicant and the authentication server, not the authenticator. There are no MAC addresses bound to the PMK or used in the derivation of the PMK. As the person who got PMK caching and PMKIDs into the 802.11i draft let me explain the steps we went through: - first motion was to indicate the ability of a STA to do "PMK caching" in an associate request. If the authenticator had a cached PMK for the STA it would respond with the 1st message of the 4way handshake, otherwise it would respond with an 802.1x encapsulated EAP Identity request. That enabled the functionality you describe below-- "the station is reassociating with an AP to with it already established the PMK before..." It prevented a STA in a difficult RF environment from ping-ponging back and forth between APs and hammering an=20 authentication server. - it soon became apparent that an authenticator may have multiple PMKs for a particular STA in its cache. How? Via something like a pro-active key pushing mechanism using neighbor graphs (Bill Arbaugh presented this idea). So the next motion was to name PMKs with a PMKID to indicate which PMK a STA is asserting in its associate request. This eliminated the ambiguity. So the very reason that we have PMKIDs, and not just blind assertions of a cached PMK, is because the PMK may be used to derive a PTK for=20 multiple APs. The statement "If PMK is shared across multiple WTPs" is, indeed, valid. Addressing Russ's comment, the PMK is already leaked because it is given to the authenticator by the authentication server. When discussing "the number of other people who know my secret" there are 3 possible values: 0, 1 and infinity. If 0 other people know your secret there are certain cryptographic properties associated with that state. If 1 other person knows your secret there are other cryptographic properties associated with that state (message source authentication for instance), but if more than 1 person knows your secret then it doesn't matter if it's 2 or 22, the cryptographic properties are the same (it is possible for someone to impersonate you, forge your messages, read your messages, etc). Of course you can say that in the 802.11i case the authenticator is "trusted" and therefore it's OK for the authentication server to leak the secret to the authenticator (and have 3 people know the secret). OK, fine. The other AP is also "trusted" to have the PMK so now 4 people know the secret (or 5 "trusted" people or 10 "trusted" people). Nothing changed. In the case of a switch hosting multiple APs the switch is the authenticator and the APs are merely tentacles of the same octopus. The PMK isn't shared among the APs, it resides on the switch. There is even one company I know of (I won't name it but it shouldn't be difficult to guess) in which the switch plays the role of the authentication server so the PMK is known only by the switch and the STA. This "PMK sharing" situation is even MORE secure than the traditional deployment where a STA establishes a PMK with a RADIUS server and that PMK is leaked to an AP. Dan. On Thu, 21 Oct 2004 14:56:37 +0530 you wrote > hi all, >=20 > I am not sure, I am right on this. My impression is that, PMK is on per=20 > Authenticator MAC address. > If the station is re-associated with new WTP (different MAC address), then=20 > it would not even send > PMKID of old AP. If there is no PMKID found in reassoc event, AC would > start with full 802.1x > authentication. If the station is reassociating with an AP, to which it=20 > already established PMK before, > then station sends PMKID and in that case only 4 way key handshake is=20 > requried to get the PTK. > With respect to this, I am not sure whether the statement > 'If PMK is shared across multiple WTP' is valid. If not, the whole=20 > statement can be removed > from the draft >=20 > Regards > Rama Krishna Prasad >=20 >=20 >=20 > Ch. Rama Krishna Prasad > Intoto Software(I) Pvt Ltd, > Uma Plaza, Nagarjuna circle, > Panjagutta. Hyderabad, AP > Tel No:s 2335 8927/8928/8434 >=20 > _______________________________________________ > Capwap mailing list > Capwap@frascone.com > http://mail.frascone.com/mailman/listinfo/capwap _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Mon Oct 25 12:39:08 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12465 for ; Mon, 25 Oct 2004 12:39:06 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 4998F1FC71; Mon, 25 Oct 2004 12:39:07 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id A51081FD5A; Mon, 25 Oct 2004 12:39:03 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id E2BB71FD5A for ; Mon, 25 Oct 2004 12:38:13 -0400 (EDT) Received: from orsfmr001.jf.intel.com (fmr12.intel.com [134.134.136.15]) by mail.frascone.com (Postfix) with ESMTP id 2B2321FC71 for ; Mon, 25 Oct 2004 12:38:11 -0400 (EDT) Received: from petasus.jf.intel.com (petasus.jf.intel.com [10.7.209.6]) by orsfmr001.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-outer.mc,v 1.15 2004/01/30 18:16:28 root Exp $) with ESMTP id i9PGcgQm022580; Mon, 25 Oct 2004 16:38:44 GMT Received: from orsmsxvs040.jf.intel.com (orsmsxvs040.jf.intel.com [192.168.65.206]) by petasus.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.11 2004/07/29 22:51:53 root Exp $) with SMTP id i9PGfSsE031513; Mon, 25 Oct 2004 16:41:30 GMT Received: from orsmsx332.amr.corp.intel.com ([192.168.65.60]) by orsmsxvs040.jf.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004102509373306528 ; Mon, 25 Oct 2004 09:37:35 -0700 Received: from orsmsx408.amr.corp.intel.com ([192.168.65.52]) by orsmsx332.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.0); Mon, 25 Oct 2004 09:37:32 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Capwap] Important: please provide input on comment resolution for CAPWAP Taxonomy draft Message-ID: <2AF68A477DD44C4EBCBE338C24E7A9EE027DBC2E@orsmsx408> Thread-Topic: [Capwap] Important: please provide input on comment resolution for CAPWAP Taxonomy draft Thread-Index: AcS3gFn0KhwJD2+tRMysD7ypgp5/FwA8TSTwAD7XbCAAUPvL4A== From: "Yang, Lily L" To: Cc: "Walker, Jesse" , X-OriginalArrivalTime: 25 Oct 2004 16:37:32.0217 (UTC) FILETIME=[ECBF0A90:01C4BAB0] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Mon, 25 Oct 2004 09:37:30 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: quoted-printable Another response from Jesse on this ... -----Original Message----- From: Walker, Jesse=20 Sent: Saturday, October 23, 2004 7:06 PM To: Yang, Lily L; 'housley@vigilsec.com' Subject: RE: [Capwap] Important: please provide input on comment resolution for CAPWAP Taxonomy draft Whether vendors want to believe it or not, the BSSID of the AP identifies the PMK the STA should use, while the PMKID was an after-thought to 802.11i, and was not properly integrated to perform the function required of it. In particular, the binding of BSSIDs and STA MAC addresses to the PMKID was never undertaken. Therefore, if the BSSID changes, the STA has to assume that the PMK has been compromised, unless the AAA server gives it some reason to believe the new BSSID is also bound to the same PMK. -----Original Message----- From: Yang, Lily L=20 Sent: Friday, October 22, 2004 12:59 PM To: Walker, Jesse; housley@vigilsec.com Subject: FW: [Capwap] Important: please provide input on comment resolution for CAPWAP Taxonomy draft Here is some other responds to the comment. -----Original Message----- From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On Behalf Of Michael Montemurro Sent: Thursday, October 21, 2004 8:12 AM To: 'Pat R. Calhoun'; 'Chunduru Rama Krishna Prasad'; capwap@frascone.com Subject: RE: [Capwap] Important: please provide input on comment resolution for CAPWAP Taxonomy draft I'd agree that the text should likely remain. However, there should be work done (likely in both IEEE and IETF) to modify the key hierarchy to address this case. Mike -----Original Message----- From: Pat R. Calhoun [mailto:pcalhoun@airespace.com]=20 Sent: Thursday, October 21, 2004 10:47 AM To: Michael Montemurro; Chunduru Rama Krishna Prasad; capwap@frascone.com Subject: RE: [Capwap] Important: please provide input on comment resolution for CAPWAP Taxonomy draft The comment may be valid in light of 802.11r. I'd argue that the text remains since we need to be cognizant of not only current IEEE standards, but also the ones in progress. PatC=20 -----Original Message----- From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On Behalf Of Chunduru Rama Krishna Prasad Sent: Thursday, October 21, 2004 5:27 AM To: capwap@frascone.com Subject: Re: [Capwap] Important: please provide input on comment resolution for CAPWAP Taxonomy draft hi all, I am not sure, I am right on this. My impression is that, PMK is on per Authenticator MAC address. If the station is re-associated with new WTP (different MAC address), then it would not even send PMKID of old AP. If there is no PMKID found in reassoc event, AC would start with full 802.1x authentication. If the station is reassociating with an AP, to which it already established PMK before, then station sends PMKID and in that case only 4 way key handshake is requried to get the PTK. With respect to this, I am not sure whether the statement 'If PMK is shared across multiple WTP' is valid. If not, the whole statement can be removed from the draft Regards Rama Krishna Prasad Ch. Rama Krishna Prasad Intoto Software(I) Pvt Ltd, Uma Plaza, Nagarjuna circle, Panjagutta. Hyderabad, AP Tel No:s 2335 8927/8928/8434 _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Mon Oct 25 13:21:10 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15510 for ; Mon, 25 Oct 2004 13:21:09 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 8CAAC1FD68; Mon, 25 Oct 2004 13:21:07 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 4A1851FD6B; Mon, 25 Oct 2004 13:21:04 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id F09FC1FD5A for ; Mon, 25 Oct 2004 13:20:05 -0400 (EDT) Received: from AIREMAIL.airespace.com (da001d3897.stl-mo.osd.concentric.net [66.236.111.57]) by mail.frascone.com (Postfix) with ESMTP id E9CF31FC64 for ; Mon, 25 Oct 2004 13:20:01 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Capwap] Important: please provide input on comment resolution for CAPWAP Taxonomy draft Message-ID: <55749BC69138654EBBC4C50BA4F556105A2F86@AIREMAIL.airespace.com> Thread-Topic: [Capwap] Important: please provide input on comment resolution for CAPWAP Taxonomy draft Thread-Index: AcS3gFn0KhwJD2+tRMysD7ypgp5/FwA8TSTwAD7XbCAAUPvL4AABaXUw From: "Pat R. Calhoun" To: "Yang, Lily L" , Cc: "Walker, Jesse" , X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Mon, 25 Oct 2004 10:19:47 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: quoted-printable While I understand Jesse's point, the IEEE is looking at alternatives in its 802.11r task group. So while there is no standards based solution today, I think it would be a mistake to break future interoperability. Furthermore, I think the point that Dan was trying to make was that in the CAPWAP architecture, the AC contain the authenticator, not the WTP. Since the AC has access to the PMK, it is inherently a "shared" resource - regardless of whether it is re-used across BSSIDs or not. PatC=20 -----Original Message----- From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On Behalf Of Yang, Lily L Sent: Monday, October 25, 2004 9:38 AM To: capwap@frascone.com Cc: Walker, Jesse; housley@vigilsec.com Subject: RE: [Capwap] Important: please provide input on comment resolution for CAPWAP Taxonomy draft Another response from Jesse on this ... -----Original Message----- From: Walker, Jesse Sent: Saturday, October 23, 2004 7:06 PM To: Yang, Lily L; 'housley@vigilsec.com' Subject: RE: [Capwap] Important: please provide input on comment resolution for CAPWAP Taxonomy draft Whether vendors want to believe it or not, the BSSID of the AP identifies the PMK the STA should use, while the PMKID was an after-thought to 802.11i, and was not properly integrated to perform the function required of it. In particular, the binding of BSSIDs and STA MAC addresses to the PMKID was never undertaken. Therefore, if the BSSID changes, the STA has to assume that the PMK has been compromised, unless the AAA server gives it some reason to believe the new BSSID is also bound to the same PMK. -----Original Message----- From: Yang, Lily L Sent: Friday, October 22, 2004 12:59 PM To: Walker, Jesse; housley@vigilsec.com Subject: FW: [Capwap] Important: please provide input on comment resolution for CAPWAP Taxonomy draft Here is some other responds to the comment. -----Original Message----- From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On Behalf Of Michael Montemurro Sent: Thursday, October 21, 2004 8:12 AM To: 'Pat R. Calhoun'; 'Chunduru Rama Krishna Prasad'; capwap@frascone.com Subject: RE: [Capwap] Important: please provide input on comment resolution for CAPWAP Taxonomy draft I'd agree that the text should likely remain. However, there should be work done (likely in both IEEE and IETF) to modify the key hierarchy to address this case. Mike -----Original Message----- From: Pat R. Calhoun [mailto:pcalhoun@airespace.com] Sent: Thursday, October 21, 2004 10:47 AM To: Michael Montemurro; Chunduru Rama Krishna Prasad; capwap@frascone.com Subject: RE: [Capwap] Important: please provide input on comment resolution for CAPWAP Taxonomy draft The comment may be valid in light of 802.11r. I'd argue that the text remains since we need to be cognizant of not only current IEEE standards, but also the ones in progress. PatC=20 -----Original Message----- From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On Behalf Of Chunduru Rama Krishna Prasad Sent: Thursday, October 21, 2004 5:27 AM To: capwap@frascone.com Subject: Re: [Capwap] Important: please provide input on comment resolution for CAPWAP Taxonomy draft hi all, I am not sure, I am right on this. My impression is that, PMK is on per Authenticator MAC address. If the station is re-associated with new WTP (different MAC address), then it would not even send PMKID of old AP. If there is no PMKID found in reassoc event, AC would start with full 802.1x authentication. If the station is reassociating with an AP, to which it already established PMK before, then station sends PMKID and in that case only 4 way key handshake is requried to get the PTK. With respect to this, I am not sure whether the statement 'If PMK is shared across multiple WTP' is valid. If not, the whole statement can be removed from the draft Regards Rama Krishna Prasad Ch. Rama Krishna Prasad Intoto Software(I) Pvt Ltd, Uma Plaza, Nagarjuna circle, Panjagutta. Hyderabad, AP Tel No:s 2335 8927/8928/8434 _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Mon Oct 25 13:41:08 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17337 for ; Mon, 25 Oct 2004 13:41:07 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id A36CA1FC64; Mon, 25 Oct 2004 13:41:07 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id EB3081FCBF; Mon, 25 Oct 2004 13:41:03 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 98D6F1FCBF for ; Mon, 25 Oct 2004 13:40:11 -0400 (EDT) Received: from AIREMAIL.airespace.com (da001d3897.stl-mo.osd.concentric.net [66.236.111.57]) by mail.frascone.com (Postfix) with ESMTP id C16661FC64 for ; Mon, 25 Oct 2004 13:40:09 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Capwap] Important: please provide input on comment resolution for CAPWAP Taxonomy draft Message-ID: <55749BC69138654EBBC4C50BA4F556105A2F8C@AIREMAIL.airespace.com> Thread-Topic: [Capwap] Important: please provide input on comment resolution for CAPWAP Taxonomy draft Thread-Index: AcS6uYIJRs2sN/zBSKO7g3WW8sD+qAAADMdQ From: "Pat R. Calhoun" To: "Russ Housley" Cc: "Walker, Jesse" , "Yang, Lily L" , X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Mon, 25 Oct 2004 10:40:09 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: quoted-printable Correct, and 802.11r is looking at that problem. The CAPWAP architecture "enables" 802.11r to function. PatC=20 -----Original Message----- From: Russ Housley [mailto:housley@vigilsec.com]=20 Sent: Monday, October 25, 2004 10:32 AM To: Pat R. Calhoun Cc: Walker, Jesse; Yang, Lily L; capwap@frascone.com Subject: RE: [Capwap] Important: please provide input on comment resolution for CAPWAP Taxonomy draft Pat: You are correct. In the CAPWAP environment, the PMK is shared with many WTPs. However, the STA has no way to figure out which WTPs out to have access to the PMK. This needs to be solved before the PMK can be effectively shared. Russ At 01:19 PM 10/25/2004, Pat R. Calhoun wrote: >While I understand Jesse's point, the IEEE is looking at alternatives=20 >in its 802.11r task group. So while there is no standards based=20 >solution today, I think it would be a mistake to break future interoperability. > >Furthermore, I think the point that Dan was trying to make was that in=20 >the CAPWAP architecture, the AC contain the authenticator, not the WTP. >Since the AC has access to the PMK, it is inherently a "shared"=20 >resource >- regardless of whether it is re-used across BSSIDs or not. > >PatC > >-----Original Message----- >From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On=20 >Behalf Of Yang, Lily L >Sent: Monday, October 25, 2004 9:38 AM >To: capwap@frascone.com >Cc: Walker, Jesse; housley@vigilsec.com >Subject: RE: [Capwap] Important: please provide input on comment=20 >resolution for CAPWAP Taxonomy draft > >Another response from Jesse on this ... > >-----Original Message----- >From: Walker, Jesse >Sent: Saturday, October 23, 2004 7:06 PM >To: Yang, Lily L; 'housley@vigilsec.com' >Subject: RE: [Capwap] Important: please provide input on comment=20 >resolution for CAPWAP Taxonomy draft > >Whether vendors want to believe it or not, the BSSID of the AP=20 >identifies the PMK the STA should use, while the PMKID was an=20 >after-thought to 802.11i, and was not properly integrated to perform=20 >the function required of it. In particular, the binding of BSSIDs and=20 >STA MAC addresses to the PMKID was never undertaken. Therefore, if the=20 >BSSID changes, the STA has to assume that the PMK has been compromised, >unless the AAA server gives it some reason to believe the new BSSID is=20 >also bound to the same PMK. > >-----Original Message----- >From: Yang, Lily L >Sent: Friday, October 22, 2004 12:59 PM >To: Walker, Jesse; housley@vigilsec.com >Subject: FW: [Capwap] Important: please provide input on comment=20 >resolution for CAPWAP Taxonomy draft > >Here is some other responds to the comment. > >-----Original Message----- >From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On=20 >Behalf Of Michael Montemurro >Sent: Thursday, October 21, 2004 8:12 AM >To: 'Pat R. Calhoun'; 'Chunduru Rama Krishna Prasad';=20 >capwap@frascone.com >Subject: RE: [Capwap] Important: please provide input on comment=20 >resolution for CAPWAP Taxonomy draft > >I'd agree that the text should likely remain. However, there should be=20 >work done (likely in both IEEE and IETF) to modify the key hierarchy to >address this case. > > Mike > >-----Original Message----- >From: Pat R. Calhoun [mailto:pcalhoun@airespace.com] >Sent: Thursday, October 21, 2004 10:47 AM >To: Michael Montemurro; Chunduru Rama Krishna Prasad;=20 >capwap@frascone.com >Subject: RE: [Capwap] Important: please provide input on comment=20 >resolution for CAPWAP Taxonomy draft > > >The comment may be valid in light of 802.11r. I'd argue that the text=20 >remains since we need to be cognizant of not only current IEEE=20 >standards, but also the ones in progress. > >PatC >-----Original Message----- >From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On=20 >Behalf Of Chunduru Rama Krishna Prasad >Sent: Thursday, October 21, 2004 5:27 AM >To: capwap@frascone.com >Subject: Re: [Capwap] Important: please provide input on comment=20 >resolution for CAPWAP Taxonomy draft > > >hi all, > >I am not sure, I am right on this. My impression is that, PMK is on per >Authenticator MAC address. If the station is re-associated with new WTP >(different MAC address), then it would not even send PMKID of old AP.=20 >If there is no PMKID found in reassoc event, AC would start with full=20 >802.1x authentication. If the station is reassociating with an AP, to=20 >which it already established PMK before, then station sends PMKID and=20 >in that case only 4 way key handshake is requried to get the PTK. With=20 >respect to this, I am not sure whether the statement 'If PMK is shared=20 >across multiple WTP' is valid. If not, the whole statement can be=20 >removed from the draft > >Regards >Rama Krishna Prasad > > > >Ch. Rama Krishna Prasad >Intoto Software(I) Pvt Ltd, >Uma Plaza, Nagarjuna circle, >Panjagutta. Hyderabad, AP >Tel No:s 2335 8927/8928/8434 > >_______________________________________________ >Capwap mailing list >Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap > >_______________________________________________ >Capwap mailing list >Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap > >_______________________________________________ >Capwap mailing list >Capwap@frascone.com >http://mail.frascone.com/mailman/listinfo/capwap >_______________________________________________ >Capwap mailing list >Capwap@frascone.com >http://mail.frascone.com/mailman/listinfo/capwap _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Mon Oct 25 13:42:08 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17372 for ; Mon, 25 Oct 2004 13:42:07 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id E7EB51FCBF; Mon, 25 Oct 2004 13:42:07 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 928A71FD5A; Mon, 25 Oct 2004 13:42:04 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id BF2451FD68 for ; Mon, 25 Oct 2004 13:41:15 -0400 (EDT) Received: from AIREMAIL.airespace.com (da001d3897.stl-mo.osd.concentric.net [66.236.111.57]) by mail.frascone.com (Postfix) with ESMTP id 882111FD5A for ; Mon, 25 Oct 2004 13:41:13 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Capwap] Important: please provide input on comment resolution for CAPWAP Taxonomy draft Message-ID: <55749BC69138654EBBC4C50BA4F556105A2F8D@AIREMAIL.airespace.com> Thread-Topic: [Capwap] Important: please provide input on comment resolution for CAPWAP Taxonomy draft Thread-Index: AcS3gFn0KhwJD2+tRMysD7ypgp5/FwA8TSTwAD7XbCAAUPvL4AABaXUwAAAbZCAAALw98A== From: "Pat R. Calhoun" To: "Walker, Jesse" , "Yang, Lily L" , Cc: X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Mon, 25 Oct 2004 10:41:13 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: quoted-printable I agree. Obviously some of my contributions are being made in 802.11r, but I'll be glad to help out in whatever way I can. PatC=20 -----Original Message----- From: Walker, Jesse [mailto:jesse.walker@intel.com]=20 Sent: Monday, October 25, 2004 10:34 AM To: Pat R. Calhoun; Yang, Lily L; capwap@frascone.com Cc: housley@vigilsec.com Subject: RE: [Capwap] Important: please provide input on comment resolution for CAPWAP Taxonomy draft Pat, The issue is not whether the AC is the Authenticator, and we are not talking about breaking future interoperability. The issue is the contract the Authenticator makes with the mobile device concerning the PMK. Under 802.11i there is no way to specify that the Authenticator is anything but the BSSID of the access point. If the key gets reused with multiple BSSIDs, then the client must assume the key has been compromised, because the Authenticator has broken its faith with the client over the only relationship that is expressible within 802.11i. My view is that no one wants to force people to necessarily use a different PMK with different APs in switched architecture, because the PMK and PTK remains within a single crypto boundary and so we know it has not been compromised. What is needed instead is some way to express the actual relationship, so that the client can distinguish the situation from the case where its key has been compromised. We need a way for the Authenticator to express its relationship with the client, so that the client can determine that it is indeed living up to this relationship. Neither 802.11i nor EAP has attempted to address the binding problem, and this is a deficiency that rules out the very natural usage model CAPWAP wants to propose. We must either remove the deficiency, or else we must live with the deployment restrictions it implies. I am assembling a strawman list requirements to discuss in 802.11 for the key binding problem. This sounds like one of them. If you have any contributions, please let me know. -- Jesse -----Original Message----- From: Pat R. Calhoun [mailto:pcalhoun@airespace.com] Sent: Monday, October 25, 2004 10:20 AM To: Yang, Lily L; capwap@frascone.com Cc: Walker, Jesse; housley@vigilsec.com Subject: RE: [Capwap] Important: please provide input on comment resolution for CAPWAP Taxonomy draft While I understand Jesse's point, the IEEE is looking at alternatives in its 802.11r task group. So while there is no standards based solution today, I think it would be a mistake to break future interoperability. Furthermore, I think the point that Dan was trying to make was that in the CAPWAP architecture, the AC contain the authenticator, not the WTP. Since the AC has access to the PMK, it is inherently a "shared" resource - regardless of whether it is re-used across BSSIDs or not. PatC=20 -----Original Message----- From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On Behalf Of Yang, Lily L Sent: Monday, October 25, 2004 9:38 AM To: capwap@frascone.com Cc: Walker, Jesse; housley@vigilsec.com Subject: RE: [Capwap] Important: please provide input on comment resolution for CAPWAP Taxonomy draft Another response from Jesse on this ... -----Original Message----- From: Walker, Jesse Sent: Saturday, October 23, 2004 7:06 PM To: Yang, Lily L; 'housley@vigilsec.com' Subject: RE: [Capwap] Important: please provide input on comment resolution for CAPWAP Taxonomy draft Whether vendors want to believe it or not, the BSSID of the AP identifies the PMK the STA should use, while the PMKID was an after-thought to 802.11i, and was not properly integrated to perform the function required of it. In particular, the binding of BSSIDs and STA MAC addresses to the PMKID was never undertaken. Therefore, if the BSSID changes, the STA has to assume that the PMK has been compromised, unless the AAA server gives it some reason to believe the new BSSID is also bound to the same PMK. -----Original Message----- From: Yang, Lily L Sent: Friday, October 22, 2004 12:59 PM To: Walker, Jesse; housley@vigilsec.com Subject: FW: [Capwap] Important: please provide input on comment resolution for CAPWAP Taxonomy draft Here is some other responds to the comment. -----Original Message----- From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On Behalf Of Michael Montemurro Sent: Thursday, October 21, 2004 8:12 AM To: 'Pat R. Calhoun'; 'Chunduru Rama Krishna Prasad'; capwap@frascone.com Subject: RE: [Capwap] Important: please provide input on comment resolution for CAPWAP Taxonomy draft I'd agree that the text should likely remain. However, there should be work done (likely in both IEEE and IETF) to modify the key hierarchy to address this case. Mike -----Original Message----- From: Pat R. Calhoun [mailto:pcalhoun@airespace.com] Sent: Thursday, October 21, 2004 10:47 AM To: Michael Montemurro; Chunduru Rama Krishna Prasad; capwap@frascone.com Subject: RE: [Capwap] Important: please provide input on comment resolution for CAPWAP Taxonomy draft The comment may be valid in light of 802.11r. I'd argue that the text remains since we need to be cognizant of not only current IEEE standards, but also the ones in progress. PatC -----Original Message----- From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On Behalf Of Chunduru Rama Krishna Prasad Sent: Thursday, October 21, 2004 5:27 AM To: capwap@frascone.com Subject: Re: [Capwap] Important: please provide input on comment resolution for CAPWAP Taxonomy draft hi all, I am not sure, I am right on this. My impression is that, PMK is on per Authenticator MAC address. If the station is re-associated with new WTP (different MAC address), then it would not even send PMKID of old AP. If there is no PMKID found in reassoc event, AC would start with full 802.1x authentication. If the station is reassociating with an AP, to which it already established PMK before, then station sends PMKID and in that case only 4 way key handshake is requried to get the PTK. With respect to this, I am not sure whether the statement 'If PMK is shared across multiple WTP' is valid. If not, the whole statement can be removed from the draft Regards Rama Krishna Prasad Ch. Rama Krishna Prasad Intoto Software(I) Pvt Ltd, Uma Plaza, Nagarjuna circle, Panjagutta. Hyderabad, AP Tel No:s 2335 8927/8928/8434 _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Mon Oct 25 13:58:09 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18813 for ; Mon, 25 Oct 2004 13:58:08 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 2B4971FC64; Mon, 25 Oct 2004 13:58:08 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 830DB1FC7B; Mon, 25 Oct 2004 13:58:04 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 259A11FC7B for ; Mon, 25 Oct 2004 13:57:57 -0400 (EDT) Received: from rproxy.gmail.com (rproxy.gmail.com [64.233.170.193]) by mail.frascone.com (Postfix) with ESMTP id CFD8A1FC64 for ; Mon, 25 Oct 2004 13:57:54 -0400 (EDT) Received: by rproxy.gmail.com with SMTP id 77so429963rnl for ; Mon, 25 Oct 2004 10:57:53 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=CsvEkUH3VLLkzhKcrQh4GQIPwW2j9pz2KFTUdsSIE0eS3+ZGiLCsdG6dRndbB2tpXWiozgUKz8YMPF0BsEVpV22NkGAK7mwcPWEFAoRx2reWTBHhU/8lndgmeG6dYwaLaoYavGRvPNR2njnFjNHIiv9C1FCYvoxUvEvokQqxL40= Received: by 10.38.82.50 with SMTP id f50mr1203507rnb; Mon, 25 Oct 2004 10:57:53 -0700 (PDT) Received: by 10.38.15.39 with HTTP; Mon, 25 Oct 2004 10:57:51 -0700 (PDT) Message-ID: From: Clint Chaplin Reply-To: Clint Chaplin To: "Pat R. Calhoun" Subject: Re: [Capwap] Important: please provide input on comment resolution for CAPWAP Taxonomy draft Cc: Russ Housley , "Walker, Jesse" , "Yang, Lily L" , capwap@frascone.com In-Reply-To: <55749BC69138654EBBC4C50BA4F556105A2F8C@AIREMAIL.airespace.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <55749BC69138654EBBC4C50BA4F556105A2F8C@AIREMAIL.airespace.com> X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Mon, 25 Oct 2004 10:57:51 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit "The CAPWAP architecture "enables" 802.11r to function." Say what? Number one, I didn't think there was a CAPWAP "architecture"; well, at least this group hasn't been able to define one. CAPWAP is more a protocol.... And, number two, the above seems to imply that without CAPWAP, IEEE 802.11r wouldn't be able to solve the problem at all. I find that limiting. On Mon, 25 Oct 2004 10:40:09 -0700, Pat R. Calhoun wrote: > Correct, and 802.11r is looking at that problem. The CAPWAP architecture > "enables" 802.11r to function. > > PatC > > -----Original Message----- > From: Russ Housley [mailto:housley@vigilsec.com] > Sent: Monday, October 25, 2004 10:32 AM > To: Pat R. Calhoun > Cc: Walker, Jesse; Yang, Lily L; capwap@frascone.com > Subject: RE: [Capwap] Important: please provide input on comment > resolution for CAPWAP Taxonomy draft > > Pat: > > You are correct. In the CAPWAP environment, the PMK is shared with many > WTPs. However, the STA has no way to figure out which WTPs out to have > access to the PMK. This needs to be solved before the PMK can be > effectively shared. > > Russ > > > > At 01:19 PM 10/25/2004, Pat R. Calhoun wrote: > >While I understand Jesse's point, the IEEE is looking at alternatives > >in its 802.11r task group. So while there is no standards based > >solution today, I think it would be a mistake to break future > interoperability. > > > >Furthermore, I think the point that Dan was trying to make was that in > >the CAPWAP architecture, the AC contain the authenticator, not the WTP. > >Since the AC has access to the PMK, it is inherently a "shared" > >resource > >- regardless of whether it is re-used across BSSIDs or not. > > > >PatC > > > >-----Original Message----- > >From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On > >Behalf Of Yang, Lily L > >Sent: Monday, October 25, 2004 9:38 AM > >To: capwap@frascone.com > >Cc: Walker, Jesse; housley@vigilsec.com > >Subject: RE: [Capwap] Important: please provide input on comment > >resolution for CAPWAP Taxonomy draft > > > >Another response from Jesse on this ... > > > >-----Original Message----- > >From: Walker, Jesse > >Sent: Saturday, October 23, 2004 7:06 PM > >To: Yang, Lily L; 'housley@vigilsec.com' > >Subject: RE: [Capwap] Important: please provide input on comment > >resolution for CAPWAP Taxonomy draft > > > >Whether vendors want to believe it or not, the BSSID of the AP > >identifies the PMK the STA should use, while the PMKID was an > >after-thought to 802.11i, and was not properly integrated to perform > >the function required of it. In particular, the binding of BSSIDs and > >STA MAC addresses to the PMKID was never undertaken. Therefore, if the > >BSSID changes, the STA has to assume that the PMK has been compromised, > > >unless the AAA server gives it some reason to believe the new BSSID is > >also bound to the same PMK. > > > >-----Original Message----- > >From: Yang, Lily L > >Sent: Friday, October 22, 2004 12:59 PM > >To: Walker, Jesse; housley@vigilsec.com > >Subject: FW: [Capwap] Important: please provide input on comment > >resolution for CAPWAP Taxonomy draft > > > >Here is some other responds to the comment. > > > >-----Original Message----- > >From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On > >Behalf Of Michael Montemurro > >Sent: Thursday, October 21, 2004 8:12 AM > >To: 'Pat R. Calhoun'; 'Chunduru Rama Krishna Prasad'; > >capwap@frascone.com > >Subject: RE: [Capwap] Important: please provide input on comment > >resolution for CAPWAP Taxonomy draft > > > >I'd agree that the text should likely remain. However, there should be > >work done (likely in both IEEE and IETF) to modify the key hierarchy to > > >address this case. > > > > Mike > > > >-----Original Message----- > >From: Pat R. Calhoun [mailto:pcalhoun@airespace.com] > >Sent: Thursday, October 21, 2004 10:47 AM > >To: Michael Montemurro; Chunduru Rama Krishna Prasad; > >capwap@frascone.com > >Subject: RE: [Capwap] Important: please provide input on comment > >resolution for CAPWAP Taxonomy draft > > > > > >The comment may be valid in light of 802.11r. I'd argue that the text > >remains since we need to be cognizant of not only current IEEE > >standards, but also the ones in progress. > > > >PatC > >-----Original Message----- > >From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On > >Behalf Of Chunduru Rama Krishna Prasad > >Sent: Thursday, October 21, 2004 5:27 AM > >To: capwap@frascone.com > >Subject: Re: [Capwap] Important: please provide input on comment > >resolution for CAPWAP Taxonomy draft > > > > > >hi all, > > > >I am not sure, I am right on this. My impression is that, PMK is on per > > >Authenticator MAC address. If the station is re-associated with new WTP > > >(different MAC address), then it would not even send PMKID of old AP. > >If there is no PMKID found in reassoc event, AC would start with full > >802.1x authentication. If the station is reassociating with an AP, to > >which it already established PMK before, then station sends PMKID and > >in that case only 4 way key handshake is requried to get the PTK. With > >respect to this, I am not sure whether the statement 'If PMK is shared > >across multiple WTP' is valid. If not, the whole statement can be > >removed from the draft > > > >Regards > >Rama Krishna Prasad > > > > > > > >Ch. Rama Krishna Prasad > >Intoto Software(I) Pvt Ltd, > >Uma Plaza, Nagarjuna circle, > >Panjagutta. Hyderabad, AP > >Tel No:s 2335 8927/8928/8434 > > > >_______________________________________________ > >Capwap mailing list > >Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap > > > >_______________________________________________ > >Capwap mailing list > >Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap > > > >_______________________________________________ > >Capwap mailing list > >Capwap@frascone.com > >http://mail.frascone.com/mailman/listinfo/capwap > >_______________________________________________ > >Capwap mailing list > >Capwap@frascone.com > >http://mail.frascone.com/mailman/listinfo/capwap > > _______________________________________________ > Capwap mailing list > Capwap@frascone.com > http://mail.frascone.com/mailman/listinfo/capwap > -- Clint (JOATMON) Chaplin Wireless Security Technologist Wireless Standards Lead _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Mon Oct 25 14:18:08 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20951 for ; Mon, 25 Oct 2004 14:18:07 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 46CED1FC64; Mon, 25 Oct 2004 14:18:07 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id EF5FF1FCBF; Mon, 25 Oct 2004 14:18:03 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id EF2581FCBF for ; Mon, 25 Oct 2004 14:17:23 -0400 (EDT) Received: from AIREMAIL.airespace.com (da001d3897.stl-mo.osd.concentric.net [66.236.111.57]) by mail.frascone.com (Postfix) with ESMTP id 0286D1FC64 for ; Mon, 25 Oct 2004 14:17:21 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Capwap] Important: please provide input on comment resolution for CAPWAP Taxonomy draft Message-ID: <55749BC69138654EBBC4C50BA4F556105A2F8F@AIREMAIL.airespace.com> Thread-Topic: [Capwap] Important: please provide input on comment resolution for CAPWAP Taxonomy draft Thread-Index: AcS6vDRfPk/jghoBS2uBobEb4G952AAAl1Kg From: "Pat R. Calhoun" To: "Clint Chaplin" Cc: "Russ Housley" , "Walker, Jesse" , "Yang, Lily L" , X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Mon, 25 Oct 2004 11:17:21 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: quoted-printable When I refer to CAPWAP architecture, I refer to the various architectures that are defined in the taxonomy document. The document clearly states that certain architectures centralize the authenticator function.=20 So now you have a centralized place where the PMK is store. 802.11r can help define a method of using the original PMK (in some way that I am not defining here) to create new PMKs in a fast and efficient manner. I know Jesse has other thoughts here too. I am referring to CAPWAP here because the discussion is in the context of the CAPWAP list. I am referring to 802.11r as external work. 802.11r may work with other architectures as well. PatC=20 -----Original Message----- From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On Behalf Of Clint Chaplin Sent: Monday, October 25, 2004 10:58 AM To: Pat R. Calhoun Cc: Russ Housley; Walker, Jesse; Yang, Lily L; capwap@frascone.com Subject: Re: [Capwap] Important: please provide input on comment resolution for CAPWAP Taxonomy draft "The CAPWAP architecture "enables" 802.11r to function." Say what? Number one, I didn't think there was a CAPWAP "architecture"; well, at least this group hasn't been able to define one. CAPWAP is more a protocol.... And, number two, the above seems to imply that without CAPWAP, IEEE 802.11r wouldn't be able to solve the problem at all. I find that limiting. On Mon, 25 Oct 2004 10:40:09 -0700, Pat R. Calhoun wrote: > Correct, and 802.11r is looking at that problem. The CAPWAP=20 > architecture "enables" 802.11r to function. >=20 > PatC >=20 > -----Original Message----- > From: Russ Housley [mailto:housley@vigilsec.com] > Sent: Monday, October 25, 2004 10:32 AM > To: Pat R. Calhoun > Cc: Walker, Jesse; Yang, Lily L; capwap@frascone.com > Subject: RE: [Capwap] Important: please provide input on comment=20 > resolution for CAPWAP Taxonomy draft >=20 > Pat: >=20 > You are correct. In the CAPWAP environment, the PMK is shared with=20 > many WTPs. However, the STA has no way to figure out which WTPs out=20 > to have access to the PMK. This needs to be solved before the PMK can > be effectively shared. >=20 > Russ >=20 >=20 >=20 > At 01:19 PM 10/25/2004, Pat R. Calhoun wrote: > >While I understand Jesse's point, the IEEE is looking at alternatives > >in its 802.11r task group. So while there is no standards based=20 > >solution today, I think it would be a mistake to break future > interoperability. > > > >Furthermore, I think the point that Dan was trying to make was that=20 > >in the CAPWAP architecture, the AC contain the authenticator, not the WTP. > >Since the AC has access to the PMK, it is inherently a "shared" > >resource > >- regardless of whether it is re-used across BSSIDs or not. > > > >PatC > > > >-----Original Message----- > >From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On > >Behalf Of Yang, Lily L > >Sent: Monday, October 25, 2004 9:38 AM > >To: capwap@frascone.com > >Cc: Walker, Jesse; housley@vigilsec.com > >Subject: RE: [Capwap] Important: please provide input on comment=20 > >resolution for CAPWAP Taxonomy draft > > > >Another response from Jesse on this ... > > > >-----Original Message----- > >From: Walker, Jesse > >Sent: Saturday, October 23, 2004 7:06 PM > >To: Yang, Lily L; 'housley@vigilsec.com' > >Subject: RE: [Capwap] Important: please provide input on comment=20 > >resolution for CAPWAP Taxonomy draft > > > >Whether vendors want to believe it or not, the BSSID of the AP=20 > >identifies the PMK the STA should use, while the PMKID was an=20 > >after-thought to 802.11i, and was not properly integrated to perform=20 > >the function required of it. In particular, the binding of BSSIDs and > >STA MAC addresses to the PMKID was never undertaken. Therefore, if=20 > >the BSSID changes, the STA has to assume that the PMK has been=20 > >compromised, >=20 > >unless the AAA server gives it some reason to believe the new BSSID=20 > >is also bound to the same PMK. > > > >-----Original Message----- > >From: Yang, Lily L > >Sent: Friday, October 22, 2004 12:59 PM > >To: Walker, Jesse; housley@vigilsec.com > >Subject: FW: [Capwap] Important: please provide input on comment=20 > >resolution for CAPWAP Taxonomy draft > > > >Here is some other responds to the comment. > > > >-----Original Message----- > >From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On > >Behalf Of Michael Montemurro > >Sent: Thursday, October 21, 2004 8:12 AM > >To: 'Pat R. Calhoun'; 'Chunduru Rama Krishna Prasad';=20 > >capwap@frascone.com > >Subject: RE: [Capwap] Important: please provide input on comment=20 > >resolution for CAPWAP Taxonomy draft > > > >I'd agree that the text should likely remain. However, there should=20 > >be work done (likely in both IEEE and IETF) to modify the key=20 > >hierarchy to >=20 > >address this case. > > > > Mike > > > >-----Original Message----- > >From: Pat R. Calhoun [mailto:pcalhoun@airespace.com] > >Sent: Thursday, October 21, 2004 10:47 AM > >To: Michael Montemurro; Chunduru Rama Krishna Prasad;=20 > >capwap@frascone.com > >Subject: RE: [Capwap] Important: please provide input on comment=20 > >resolution for CAPWAP Taxonomy draft > > > > > >The comment may be valid in light of 802.11r. I'd argue that the text > >remains since we need to be cognizant of not only current IEEE=20 > >standards, but also the ones in progress. > > > >PatC > >-----Original Message----- > >From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On > >Behalf Of Chunduru Rama Krishna Prasad > >Sent: Thursday, October 21, 2004 5:27 AM > >To: capwap@frascone.com > >Subject: Re: [Capwap] Important: please provide input on comment=20 > >resolution for CAPWAP Taxonomy draft > > > > > >hi all, > > > >I am not sure, I am right on this. My impression is that, PMK is on=20 > >per >=20 > >Authenticator MAC address. If the station is re-associated with new=20 > >WTP >=20 > >(different MAC address), then it would not even send PMKID of old AP. > >If there is no PMKID found in reassoc event, AC would start with full > >802.1x authentication. If the station is reassociating with an AP, to > >which it already established PMK before, then station sends PMKID and > >in that case only 4 way key handshake is requried to get the PTK.=20 > >With respect to this, I am not sure whether the statement 'If PMK is=20 > >shared across multiple WTP' is valid. If not, the whole statement can > >be removed from the draft > > > >Regards > >Rama Krishna Prasad > > > > > > > >Ch. Rama Krishna Prasad > >Intoto Software(I) Pvt Ltd, > >Uma Plaza, Nagarjuna circle, > >Panjagutta. Hyderabad, AP > >Tel No:s 2335 8927/8928/8434 > > > >_______________________________________________ > >Capwap mailing list > >Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap > > > >_______________________________________________ > >Capwap mailing list > >Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap > > > >_______________________________________________ > >Capwap mailing list > >Capwap@frascone.com > >http://mail.frascone.com/mailman/listinfo/capwap > >_______________________________________________ > >Capwap mailing list > >Capwap@frascone.com > >http://mail.frascone.com/mailman/listinfo/capwap >=20 > _______________________________________________ > Capwap mailing list > Capwap@frascone.com > http://mail.frascone.com/mailman/listinfo/capwap >=20 -- Clint (JOATMON) Chaplin Wireless Security Technologist Wireless Standards Lead _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Mon Oct 25 14:20:08 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21050 for ; Mon, 25 Oct 2004 14:20:07 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id D47B61FC64; Mon, 25 Oct 2004 14:20:07 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 280421FD5A; Mon, 25 Oct 2004 14:20:04 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id D40901FD5A for ; Mon, 25 Oct 2004 14:19:25 -0400 (EDT) Received: from AIREMAIL.airespace.com (da001d3897.stl-mo.osd.concentric.net [66.236.111.57]) by mail.frascone.com (Postfix) with ESMTP id 8D3A61FC64 for ; Mon, 25 Oct 2004 14:19:23 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Capwap] Important: please provide input on comment resolution for CAPWAP Taxonomy draft Message-ID: <55749BC69138654EBBC4C50BA4F556105A2F90@AIREMAIL.airespace.com> Thread-Topic: [Capwap] Important: please provide input on comment resolution for CAPWAP Taxonomy draft Thread-Index: AcS6uYIJRs2sN/zBSKO7g3WW8sD+qAAADMdQAAAkocAAASmOYA== From: "Pat R. Calhoun" To: "Walker, Jesse" , "Russ Housley" Cc: "Yang, Lily L" , X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Mon, 25 Oct 2004 11:19:23 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: quoted-printable That's a topic that I will not bother polluting this specific list with. However, regardless of the end solution, I do believe that what we are both agreeing to is that the CAPWAP architecture makes this solution possible once the actual problem has been addressed. PatC=20 -----Original Message----- From: Walker, Jesse [mailto:jesse.walker@intel.com]=20 Sent: Monday, October 25, 2004 10:48 AM To: Pat R. Calhoun; Russ Housley Cc: Yang, Lily L; capwap@frascone.com Subject: RE: [Capwap] Important: please provide input on comment resolution for CAPWAP Taxonomy draft Pat, Your assertion that 802.11r is addressing the problem is not obviously correct. Any solution that works will involve interaction between the client, the AP or AC, and the AAA server. This is because the AAA server is the only party available that the client trusts to make assertions about its relationship with the Authenticator. This unfortunately means that the solution is outside the scope of 802.11 and can only be dealt with in IETF. I think 802.11r can specify its requirements for solutions to this problem, or it can draft the kind of solution it would like to see and then request that the IETF accept its proposed solution as a work item. I do not believe 802.11r can define the solution itself. -- Jesse -----Original Message----- From: Pat R. Calhoun [mailto:pcalhoun@airespace.com] Sent: Monday, October 25, 2004 10:40 AM To: Russ Housley Cc: Walker, Jesse; Yang, Lily L; capwap@frascone.com Subject: RE: [Capwap] Important: please provide input on comment resolution for CAPWAP Taxonomy draft Correct, and 802.11r is looking at that problem. The CAPWAP architecture "enables" 802.11r to function. PatC=20 -----Original Message----- From: Russ Housley [mailto:housley@vigilsec.com] Sent: Monday, October 25, 2004 10:32 AM To: Pat R. Calhoun Cc: Walker, Jesse; Yang, Lily L; capwap@frascone.com Subject: RE: [Capwap] Important: please provide input on comment resolution for CAPWAP Taxonomy draft Pat: You are correct. In the CAPWAP environment, the PMK is shared with many WTPs. However, the STA has no way to figure out which WTPs out to have access to the PMK. This needs to be solved before the PMK can be effectively shared. Russ At 01:19 PM 10/25/2004, Pat R. Calhoun wrote: >While I understand Jesse's point, the IEEE is looking at alternatives=20 >in its 802.11r task group. So while there is no standards based=20 >solution today, I think it would be a mistake to break future interoperability. > >Furthermore, I think the point that Dan was trying to make was that in=20 >the CAPWAP architecture, the AC contain the authenticator, not the WTP. >Since the AC has access to the PMK, it is inherently a "shared"=20 >resource >- regardless of whether it is re-used across BSSIDs or not. > >PatC > >-----Original Message----- >From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On=20 >Behalf Of Yang, Lily L >Sent: Monday, October 25, 2004 9:38 AM >To: capwap@frascone.com >Cc: Walker, Jesse; housley@vigilsec.com >Subject: RE: [Capwap] Important: please provide input on comment=20 >resolution for CAPWAP Taxonomy draft > >Another response from Jesse on this ... > >-----Original Message----- >From: Walker, Jesse >Sent: Saturday, October 23, 2004 7:06 PM >To: Yang, Lily L; 'housley@vigilsec.com' >Subject: RE: [Capwap] Important: please provide input on comment=20 >resolution for CAPWAP Taxonomy draft > >Whether vendors want to believe it or not, the BSSID of the AP=20 >identifies the PMK the STA should use, while the PMKID was an=20 >after-thought to 802.11i, and was not properly integrated to perform=20 >the function required of it. In particular, the binding of BSSIDs and=20 >STA MAC addresses to the PMKID was never undertaken. Therefore, if the=20 >BSSID changes, the STA has to assume that the PMK has been compromised, >unless the AAA server gives it some reason to believe the new BSSID is=20 >also bound to the same PMK. > >-----Original Message----- >From: Yang, Lily L >Sent: Friday, October 22, 2004 12:59 PM >To: Walker, Jesse; housley@vigilsec.com >Subject: FW: [Capwap] Important: please provide input on comment=20 >resolution for CAPWAP Taxonomy draft > >Here is some other responds to the comment. > >-----Original Message----- >From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On=20 >Behalf Of Michael Montemurro >Sent: Thursday, October 21, 2004 8:12 AM >To: 'Pat R. Calhoun'; 'Chunduru Rama Krishna Prasad';=20 >capwap@frascone.com >Subject: RE: [Capwap] Important: please provide input on comment=20 >resolution for CAPWAP Taxonomy draft > >I'd agree that the text should likely remain. However, there should be=20 >work done (likely in both IEEE and IETF) to modify the key hierarchy to >address this case. > > Mike > >-----Original Message----- >From: Pat R. Calhoun [mailto:pcalhoun@airespace.com] >Sent: Thursday, October 21, 2004 10:47 AM >To: Michael Montemurro; Chunduru Rama Krishna Prasad;=20 >capwap@frascone.com >Subject: RE: [Capwap] Important: please provide input on comment=20 >resolution for CAPWAP Taxonomy draft > > >The comment may be valid in light of 802.11r. I'd argue that the text=20 >remains since we need to be cognizant of not only current IEEE=20 >standards, but also the ones in progress. > >PatC >-----Original Message----- >From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On=20 >Behalf Of Chunduru Rama Krishna Prasad >Sent: Thursday, October 21, 2004 5:27 AM >To: capwap@frascone.com >Subject: Re: [Capwap] Important: please provide input on comment=20 >resolution for CAPWAP Taxonomy draft > > >hi all, > >I am not sure, I am right on this. My impression is that, PMK is on per >Authenticator MAC address. If the station is re-associated with new WTP >(different MAC address), then it would not even send PMKID of old AP.=20 >If there is no PMKID found in reassoc event, AC would start with full=20 >802.1x authentication. If the station is reassociating with an AP, to=20 >which it already established PMK before, then station sends PMKID and=20 >in that case only 4 way key handshake is requried to get the PTK. With=20 >respect to this, I am not sure whether the statement 'If PMK is shared=20 >across multiple WTP' is valid. If not, the whole statement can be=20 >removed from the draft > >Regards >Rama Krishna Prasad > > > >Ch. Rama Krishna Prasad >Intoto Software(I) Pvt Ltd, >Uma Plaza, Nagarjuna circle, >Panjagutta. Hyderabad, AP >Tel No:s 2335 8927/8928/8434 > >_______________________________________________ >Capwap mailing list >Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap > >_______________________________________________ >Capwap mailing list >Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap > >_______________________________________________ >Capwap mailing list >Capwap@frascone.com >http://mail.frascone.com/mailman/listinfo/capwap >_______________________________________________ >Capwap mailing list >Capwap@frascone.com >http://mail.frascone.com/mailman/listinfo/capwap _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Mon Oct 25 15:59:09 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28798 for ; Mon, 25 Oct 2004 15:59:08 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 457D21FC64; Mon, 25 Oct 2004 15:59:08 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id B59851FCBF; Mon, 25 Oct 2004 15:59:04 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 58EB31FCBF for ; Mon, 25 Oct 2004 15:58:28 -0400 (EDT) Received: from homebrew.trpz.com (66-7-225-40.cust.telepacific.net [66.7.225.40]) by mail.frascone.com (Postfix) with ESMTP id 3869D1FC64 for ; Mon, 25 Oct 2004 15:58:25 -0400 (EDT) Received: from trpz.com (localhost.trpz.com [127.0.0.1]) by homebrew.trpz.com (8.13.1/8.13.1) with ESMTP id i9PJvY28079279; Mon, 25 Oct 2004 12:57:35 -0700 (PDT) (envelope-from dharkins@trpz.com) Message-Id: <200410251957.i9PJvY28079279@homebrew.trpz.com> To: "Yang, Lily L" Cc: capwap@frascone.com, "Walker, Jesse" , housley@vigilsec.com Subject: Re: FW: [Capwap] Important: please provide input on comment resolution for CAPWAP Taxonomy draft In-Reply-To: Your message of "Mon, 25 Oct 2004 09:33:05 PDT." <2AF68A477DD44C4EBCBE338C24E7A9EE027DBBFD@orsmsx408> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <79277.1098734254.1@trpz.com> From: Dan Harkins X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Mon, 25 Oct 2004 12:57:34 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) I beg to differ. If this was a Needham-Schroeder-esqe protocol Jesse might have a point. But it's not. There is no way for a "properly implemented" client to know that the AP it is speaking to is trusted by the authentication server since nothing in the exchange that derives the PMK includes anything about the AP. It's merely a man-in-the-middle. The AP proves knowledge of the PMK so the client is just supposed to assume it's trusted! What is being asked here is just ignore that unpleasant security issue and believe we have a secure 3-party authenticaiton system here so that we can then condemn a scheme that suffers from that same unpleasant security issue. How does a "properly implemented" client know that AP2 is not a attacker which compromised AP1? By the same technique that it used to know that AP1 was not an attacker which compromised the authen- tication server (or the link between the authentication server and a legitimate authenticator). Since a "properly implemented" client can do the latter it can take the same steps to do the former. If mere proof of possession of the PMK is enough to legitimize AP1 to the client then mere proof of possession of the PMK is enough to legitimize AP2 to the client. You cannot reasonably claim otherwise. This is not to say that Jesse's suggestions of (a) or (b) below are not needed, I would welcome either of those. I would also like to note that Jesse's mention of (c) is an explicit acknowledgment that "PMK sharing" is permitted by the existing specification. Dan. On Mon, 25 Oct 2004 09:33:05 PDT you wrote > I solicited input from Jesse Walker and Russ Housley on the issue of PMK > sharing, and here is the response from Jesse. He agrees to let me > forward this to the CAPWAP list. I also cc Jesse and Russ here. Since > Russ posted the original comment in IESG review, and Jesse is the > technical editor of 11i, I think it would be good that we keep them in > the loop with regard this discussion. So please cc them in your email > posting on this issue as they are not in the CAPWAP list. > > -----Original Message----- > From: Walker, Jesse > Sent: Saturday, October 23, 2004 7:05 PM > To: Yang, Lily L; 'housley@vigilsec.com' > Subject: RE: [Capwap] Important: please provide input on comment > resolution for CAPWAP Taxonomy draft > > Lily, > > Dan's reasoning is invalid, unless he or someone else can produce a > deterministic algorithm that allows the client to distinguish the > following two cases: > > Case 1: AP1 and AP2 are classical access points. An attacker compromises > AP1 and AP2 and moves the client's PMK from AP1 and AP2. > > Case 2: AP1 and AP2 are two light-weight access points that are part of > the same switch S. The switch S uses the same PMK with both AP1 and AP2. > > If no one can demonstrate a deterministic algorithm the client can use > to distinguish the two cases, then a properly implemented client will > always assume its PMK has been compromised when it sees either case. I > suspect no one can, because the client lacks the necessary state. > > It appears to me there are three possible solutions: > > a. The first is the necessary state is somehow delivered to the client > in an attestable fashion. The only party that client trusts is the AAA > server, so this implies a new binding protocol between the AAA server > and the EAP Peer. > > b. The second is to define a new protocol that delivers the AP's > authenticated identifier to the EAP Peer in an attestable fashion, and > to change the 802.11i key confirmation handshake to use this identifier > instead of the BSSID of the APs. > > c. The text that permits this usage should be removed. > > I believe possibilities (a) or (b) are the right way to address this > issue. > > -- Jesse > > -----Original Message----- > From: Yang, Lily L > Sent: Friday, October 22, 2004 12:03 PM > To: Walker, Jesse; housley@vigilsec.com > Subject: FW: [Capwap] Important: please provide input on comment > resolution for CAPWAP Taxonomy draft > Importance: High > > Jesse and Russ -- > > CAPWAP WG has had some email discussion regarding the comment from you > on PMK sharing. I don't think either of you are on the list, so I am > forwarding to you this and I would like to hear what you think about > these responses. > > Lily > > -----Original Message----- > From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On > Behalf Of Dan Harkins > Sent: Thursday, October 21, 2004 9:47 AM > To: Chunduru Rama Krishna Prasad > Cc: capwap@frascone.com > Subject: Re: [Capwap] Important: please provide input on comment > resolution for CAPWAP Taxonomy draft > > Strictly speaking the PMK is shared between the supplicant and the > authentication server, not the authenticator. There are no MAC addresses > bound to the PMK or used in the derivation of the PMK. > > As the person who got PMK caching and PMKIDs into the 802.11i draft > let me explain the steps we went through: > > - first motion was to indicate the ability of a STA to do "PMK > caching" > in an associate request. If the authenticator had a cached PMK for > the STA it would respond with the 1st message of the 4way handshake, > otherwise it would respond with an 802.1x encapsulated EAP Identity > request. That enabled the functionality you describe below-- "the > station is reassociating with an AP to with it already established > the PMK before..." It prevented a STA in a difficult RF environment > from ping-ponging back and forth between APs and hammering an > authentication server. > > - it soon became apparent that an authenticator may have multiple PMKs > for a particular STA in its cache. How? Via something like a > pro-active > key pushing mechanism using neighbor graphs (Bill Arbaugh presented > this idea). So the next motion was to name PMKs with a PMKID to > indicate which PMK a STA is asserting in its associate request. > This eliminated the ambiguity. > > So the very reason that we have PMKIDs, and not just blind assertions of > a cached PMK, is because the PMK may be used to derive a PTK for > multiple APs. The statement "If PMK is shared across multiple WTPs" is, > indeed, valid. > > Addressing Russ's comment, the PMK is already leaked because it is > given to the authenticator by the authentication server. When discussing > "the number of other people who know my secret" there are 3 possible > values: 0, 1 and infinity. If 0 other people know your secret there are > certain cryptographic properties associated with that state. If 1 other > person knows your secret there are other cryptographic properties > associated with that state (message source authentication for instance), > but if more than 1 person knows your secret then it doesn't matter if > it's 2 or 22, the cryptographic properties are the same (it is possible > for someone to impersonate you, forge your messages, read your > messages, etc). > > Of course you can say that in the 802.11i case the authenticator is > "trusted" and therefore it's OK for the authentication server to leak > the secret to the authenticator (and have 3 people know the secret). > OK, fine. The other AP is also "trusted" to have the PMK so now 4 people > know the secret (or 5 "trusted" people or 10 "trusted" people). Nothing > changed. > > In the case of a switch hosting multiple APs the switch is the > authenticator and the APs are merely tentacles of the same octopus. The > PMK isn't shared among the APs, it resides on the switch. There is even > one company I know of (I won't name it but it shouldn't be difficult to > guess) in which the switch plays the role of the authentication server > so the PMK is known only by the switch and the STA. This "PMK sharing" > situation is even MORE secure than the traditional deployment where a > STA > establishes a PMK with a RADIUS server and that PMK is leaked to an AP. > > Dan. > > On Thu, 21 Oct 2004 14:56:37 +0530 you wrote > > hi all, > > > > I am not sure, I am right on this. My impression is that, PMK is on > per > > Authenticator MAC address. > > If the station is re-associated with new WTP (different MAC address), > then > > it would not even send > > PMKID of old AP. If there is no PMKID found in reassoc event, AC would > > > start with full 802.1x > > authentication. If the station is reassociating with an AP, to which > it > > already established PMK before, > > then station sends PMKID and in that case only 4 way key handshake is > > requried to get the PTK. > > With respect to this, I am not sure whether the statement > > 'If PMK is shared across multiple WTP' is valid. If not, the whole > > statement can be removed > > from the draft > > > > Regards > > Rama Krishna Prasad > > > > > > > > Ch. Rama Krishna Prasad > > Intoto Software(I) Pvt Ltd, > > Uma Plaza, Nagarjuna circle, > > Panjagutta. Hyderabad, AP > > Tel No:s 2335 8927/8928/8434 > > > > _______________________________________________ > > Capwap mailing list > > Capwap@frascone.com > > http://mail.frascone.com/mailman/listinfo/capwap > _______________________________________________ > Capwap mailing list > Capwap@frascone.com > http://mail.frascone.com/mailman/listinfo/capwap > _______________________________________________ > Capwap mailing list > Capwap@frascone.com > http://mail.frascone.com/mailman/listinfo/capwap > _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Mon Oct 25 16:07:08 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00044 for ; Mon, 25 Oct 2004 16:07:07 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 412D51FCBF; Mon, 25 Oct 2004 16:07:08 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 978621FD5A; Mon, 25 Oct 2004 16:07:04 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id E83061FD5A for ; Mon, 25 Oct 2004 16:06:41 -0400 (EDT) Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by mail.frascone.com (Postfix) with ESMTP id E9C9F1FCBF for ; Mon, 25 Oct 2004 16:06:37 -0400 (EDT) Message-ID: <01c801c4bace$411019a0$656115ac@dcml.docomolabsusa.com> From: "James Kempf" To: "Pat R. Calhoun" , "Walker, Jesse" , "Russ Housley" Cc: "Yang, Lily L" , References: <55749BC69138654EBBC4C50BA4F556105A2F90@AIREMAIL.airespace.com> Subject: Re: [Capwap] Important: please provide input on comment resolution for CAPWAP Taxonomy draft MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Mon, 25 Oct 2004 13:07:22 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit Pat, From an architectural standpoint, the AAA server is the only functional entity in the network that everybody trusts, so it has to be an important part of the solution somehow. Since AAA is an IETF function, the IETF has to be involved, and actually is probably the better body to do the technical work, since the technical expertiese is in IETF. Exactly how that plays out with 802.11r/CAPWAP, I am not sure, primarily because I don't have a very good idea about what 802.11r does (and, after spending a frustrating 10 minutes browsing around the confusing 802.11 Web site and failing to find the PAR, I've not been able to find out by myself either). If .11r is primarily concerned with host to network protocol, then I think CAPWAP might be a good place to do the work in IETF, or the AAA WG (though I believe they are on the verge of closing). If .11r is involved in network to network, then I am not so sure, it would depend on what .11r is intending. Perhaps the right time to discuss this is when .11r gets its requirements together, but I do think it will need to be discussed in IETF at some point. jak ----- Original Message ----- From: "Pat R. Calhoun" To: "Walker, Jesse" ; "Russ Housley" Cc: "Yang, Lily L" ; Sent: Monday, October 25, 2004 11:19 AM Subject: RE: [Capwap] Important: please provide input on comment resolution for CAPWAP Taxonomy draft That's a topic that I will not bother polluting this specific list with. However, regardless of the end solution, I do believe that what we are both agreeing to is that the CAPWAP architecture makes this solution possible once the actual problem has been addressed. PatC -----Original Message----- From: Walker, Jesse [mailto:jesse.walker@intel.com] Sent: Monday, October 25, 2004 10:48 AM To: Pat R. Calhoun; Russ Housley Cc: Yang, Lily L; capwap@frascone.com Subject: RE: [Capwap] Important: please provide input on comment resolution for CAPWAP Taxonomy draft Pat, Your assertion that 802.11r is addressing the problem is not obviously correct. Any solution that works will involve interaction between the client, the AP or AC, and the AAA server. This is because the AAA server is the only party available that the client trusts to make assertions about its relationship with the Authenticator. This unfortunately means that the solution is outside the scope of 802.11 and can only be dealt with in IETF. I think 802.11r can specify its requirements for solutions to this problem, or it can draft the kind of solution it would like to see and then request that the IETF accept its proposed solution as a work item. I do not believe 802.11r can define the solution itself. -- Jesse -----Original Message----- From: Pat R. Calhoun [mailto:pcalhoun@airespace.com] Sent: Monday, October 25, 2004 10:40 AM To: Russ Housley Cc: Walker, Jesse; Yang, Lily L; capwap@frascone.com Subject: RE: [Capwap] Important: please provide input on comment resolution for CAPWAP Taxonomy draft Correct, and 802.11r is looking at that problem. The CAPWAP architecture "enables" 802.11r to function. PatC -----Original Message----- From: Russ Housley [mailto:housley@vigilsec.com] Sent: Monday, October 25, 2004 10:32 AM To: Pat R. Calhoun Cc: Walker, Jesse; Yang, Lily L; capwap@frascone.com Subject: RE: [Capwap] Important: please provide input on comment resolution for CAPWAP Taxonomy draft Pat: You are correct. In the CAPWAP environment, the PMK is shared with many WTPs. However, the STA has no way to figure out which WTPs out to have access to the PMK. This needs to be solved before the PMK can be effectively shared. Russ At 01:19 PM 10/25/2004, Pat R. Calhoun wrote: >While I understand Jesse's point, the IEEE is looking at alternatives >in its 802.11r task group. So while there is no standards based >solution today, I think it would be a mistake to break future interoperability. > >Furthermore, I think the point that Dan was trying to make was that in >the CAPWAP architecture, the AC contain the authenticator, not the WTP. >Since the AC has access to the PMK, it is inherently a "shared" >resource >- regardless of whether it is re-used across BSSIDs or not. > >PatC > >-----Original Message----- >From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On >Behalf Of Yang, Lily L >Sent: Monday, October 25, 2004 9:38 AM >To: capwap@frascone.com >Cc: Walker, Jesse; housley@vigilsec.com >Subject: RE: [Capwap] Important: please provide input on comment >resolution for CAPWAP Taxonomy draft > >Another response from Jesse on this ... > >-----Original Message----- >From: Walker, Jesse >Sent: Saturday, October 23, 2004 7:06 PM >To: Yang, Lily L; 'housley@vigilsec.com' >Subject: RE: [Capwap] Important: please provide input on comment >resolution for CAPWAP Taxonomy draft > >Whether vendors want to believe it or not, the BSSID of the AP >identifies the PMK the STA should use, while the PMKID was an >after-thought to 802.11i, and was not properly integrated to perform >the function required of it. In particular, the binding of BSSIDs and >STA MAC addresses to the PMKID was never undertaken. Therefore, if the >BSSID changes, the STA has to assume that the PMK has been compromised, >unless the AAA server gives it some reason to believe the new BSSID is >also bound to the same PMK. > >-----Original Message----- >From: Yang, Lily L >Sent: Friday, October 22, 2004 12:59 PM >To: Walker, Jesse; housley@vigilsec.com >Subject: FW: [Capwap] Important: please provide input on comment >resolution for CAPWAP Taxonomy draft > >Here is some other responds to the comment. > >-----Original Message----- >From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On >Behalf Of Michael Montemurro >Sent: Thursday, October 21, 2004 8:12 AM >To: 'Pat R. Calhoun'; 'Chunduru Rama Krishna Prasad'; >capwap@frascone.com >Subject: RE: [Capwap] Important: please provide input on comment >resolution for CAPWAP Taxonomy draft > >I'd agree that the text should likely remain. However, there should be >work done (likely in both IEEE and IETF) to modify the key hierarchy to >address this case. > > Mike > >-----Original Message----- >From: Pat R. Calhoun [mailto:pcalhoun@airespace.com] >Sent: Thursday, October 21, 2004 10:47 AM >To: Michael Montemurro; Chunduru Rama Krishna Prasad; >capwap@frascone.com >Subject: RE: [Capwap] Important: please provide input on comment >resolution for CAPWAP Taxonomy draft > > >The comment may be valid in light of 802.11r. I'd argue that the text >remains since we need to be cognizant of not only current IEEE >standards, but also the ones in progress. > >PatC >-----Original Message----- >From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On >Behalf Of Chunduru Rama Krishna Prasad >Sent: Thursday, October 21, 2004 5:27 AM >To: capwap@frascone.com >Subject: Re: [Capwap] Important: please provide input on comment >resolution for CAPWAP Taxonomy draft > > >hi all, > >I am not sure, I am right on this. My impression is that, PMK is on per >Authenticator MAC address. If the station is re-associated with new WTP >(different MAC address), then it would not even send PMKID of old AP. >If there is no PMKID found in reassoc event, AC would start with full >802.1x authentication. If the station is reassociating with an AP, to >which it already established PMK before, then station sends PMKID and >in that case only 4 way key handshake is requried to get the PTK. With >respect to this, I am not sure whether the statement 'If PMK is shared >across multiple WTP' is valid. If not, the whole statement can be >removed from the draft > >Regards >Rama Krishna Prasad > > > >Ch. Rama Krishna Prasad >Intoto Software(I) Pvt Ltd, >Uma Plaza, Nagarjuna circle, >Panjagutta. Hyderabad, AP >Tel No:s 2335 8927/8928/8434 > >_______________________________________________ >Capwap mailing list >Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap > >_______________________________________________ >Capwap mailing list >Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap > >_______________________________________________ >Capwap mailing list >Capwap@frascone.com >http://mail.frascone.com/mailman/listinfo/capwap >_______________________________________________ >Capwap mailing list >Capwap@frascone.com >http://mail.frascone.com/mailman/listinfo/capwap _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Mon Oct 25 16:24:08 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04044 for ; Mon, 25 Oct 2004 16:24:07 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 7F3061FD5A; Mon, 25 Oct 2004 16:24:08 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 8D00E1FD68; Mon, 25 Oct 2004 16:24:04 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 6DFC71FD68 for ; Mon, 25 Oct 2004 16:23:37 -0400 (EDT) Received: from AIREMAIL.airespace.com (da001d3897.stl-mo.osd.concentric.net [66.236.111.57]) by mail.frascone.com (Postfix) with ESMTP id 45D9A1FD5A for ; Mon, 25 Oct 2004 16:23:32 -0400 (EDT) Content-class: urn:content-classes:message Subject: RE: [Capwap] Important: please provide input on comment resolution for CAPWAP Taxonomy draft MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message-ID: <55749BC69138654EBBC4C50BA4F556105A2F93@AIREMAIL.airespace.com> X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Thread-Topic: [Capwap] Important: please provide input on comment resolution for CAPWAP Taxonomy draft Thread-Index: AcS6ziCzz6Od1qOASveLd+Y6UqQSXAAAbodQ From: "Pat R. Calhoun" To: "James Kempf" , "Walker, Jesse" , "Russ Housley" Cc: "Yang, Lily L" , X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Mon, 25 Oct 2004 13:23:29 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: quoted-printable 802.11r is out of scope and is a client-network protocol for speeding up hand-offs. There is no document at this time to review. This discussion is unfortunately really getting out of hand. My point, below, is that PMKs are maintained in the AC today, and ACs can support more than one WTP. If there is a mechanism that allows a station's PMKs created on one WTP to be "used" in some fashion to derive other keying material for other WTPs, then so be it. CAPWAP is not the place to discuss the merits of such an approach. This would be better served in other mailing lists (either AAA, RADIUS-EXT or perhaps in 802.11r). That said, let some other group define the specific mechanism but CAPWAP shouldn't explicitely prevent this behavior in its charter. I am not stating that 802.11r is in some way replicating CAPWAP or AAA work - it is completely orthogonal. PatC=20 -----Original Message----- From: James Kempf [mailto:kempf@docomolabs-usa.com]=20 Sent: Monday, October 25, 2004 1:07 PM To: Pat R. Calhoun; Walker, Jesse; Russ Housley Cc: Yang, Lily L; capwap@frascone.com Subject: Re: [Capwap] Important: please provide input on comment resolution for CAPWAP Taxonomy draft Pat, From an architectural standpoint, the AAA server is the only functional entity in the network that everybody trusts, so it has to be an important part of the solution somehow. Since AAA is an IETF function, the IETF has to be involved, and actually is probably the better body to do the technical work, since the technical expertiese is in IETF. Exactly how that plays out with 802.11r/CAPWAP, I am not sure, primarily because I don't have a very good idea about what 802.11r does (and, after spending a frustrating 10 minutes browsing around the confusing 802.11 Web site and failing to find the PAR, I've not been able to find out by myself either). If .11r is primarily concerned with host to network protocol, then I think CAPWAP might be a good place to do the work in IETF, or the AAA WG (though I believe they are on the verge of closing). If .11r is involved in network to network, then I am not so sure, it would depend on what .11r is intending. Perhaps the right time to discuss this is when .11r gets its requirements together, but I do think it will need to be discussed in IETF at some point. jak ----- Original Message ----- From: "Pat R. Calhoun" To: "Walker, Jesse" ; "Russ Housley" Cc: "Yang, Lily L" ; Sent: Monday, October 25, 2004 11:19 AM Subject: RE: [Capwap] Important: please provide input on comment resolution for CAPWAP Taxonomy draft That's a topic that I will not bother polluting this specific list with. However, regardless of the end solution, I do believe that what we are both agreeing to is that the CAPWAP architecture makes this solution possible once the actual problem has been addressed. PatC -----Original Message----- From: Walker, Jesse [mailto:jesse.walker@intel.com] Sent: Monday, October 25, 2004 10:48 AM To: Pat R. Calhoun; Russ Housley Cc: Yang, Lily L; capwap@frascone.com Subject: RE: [Capwap] Important: please provide input on comment resolution for CAPWAP Taxonomy draft Pat, Your assertion that 802.11r is addressing the problem is not obviously correct. Any solution that works will involve interaction between the client, the AP or AC, and the AAA server. This is because the AAA server is the only party available that the client trusts to make assertions about its relationship with the Authenticator. This unfortunately means that the solution is outside the scope of 802.11 and can only be dealt with in IETF. I think 802.11r can specify its requirements for solutions to this problem, or it can draft the kind of solution it would like to see and then request that the IETF accept its proposed solution as a work item. I do not believe 802.11r can define the solution itself. -- Jesse -----Original Message----- From: Pat R. Calhoun [mailto:pcalhoun@airespace.com] Sent: Monday, October 25, 2004 10:40 AM To: Russ Housley Cc: Walker, Jesse; Yang, Lily L; capwap@frascone.com Subject: RE: [Capwap] Important: please provide input on comment resolution for CAPWAP Taxonomy draft Correct, and 802.11r is looking at that problem. The CAPWAP architecture "enables" 802.11r to function. PatC -----Original Message----- From: Russ Housley [mailto:housley@vigilsec.com] Sent: Monday, October 25, 2004 10:32 AM To: Pat R. Calhoun Cc: Walker, Jesse; Yang, Lily L; capwap@frascone.com Subject: RE: [Capwap] Important: please provide input on comment resolution for CAPWAP Taxonomy draft Pat: You are correct. In the CAPWAP environment, the PMK is shared with many WTPs. However, the STA has no way to figure out which WTPs out to have access to the PMK. This needs to be solved before the PMK can be effectively shared. Russ At 01:19 PM 10/25/2004, Pat R. Calhoun wrote: >While I understand Jesse's point, the IEEE is looking at alternatives >in its 802.11r task group. So while there is no standards based >solution today, I think it would be a mistake to break future interoperability. > >Furthermore, I think the point that Dan was trying to make was that in >the CAPWAP architecture, the AC contain the authenticator, not the WTP. >Since the AC has access to the PMK, it is inherently a "shared" >resource >- regardless of whether it is re-used across BSSIDs or not. > >PatC > >-----Original Message----- >From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On >Behalf Of Yang, Lily L >Sent: Monday, October 25, 2004 9:38 AM >To: capwap@frascone.com >Cc: Walker, Jesse; housley@vigilsec.com >Subject: RE: [Capwap] Important: please provide input on comment >resolution for CAPWAP Taxonomy draft > >Another response from Jesse on this ... > >-----Original Message----- >From: Walker, Jesse >Sent: Saturday, October 23, 2004 7:06 PM >To: Yang, Lily L; 'housley@vigilsec.com' >Subject: RE: [Capwap] Important: please provide input on comment >resolution for CAPWAP Taxonomy draft > >Whether vendors want to believe it or not, the BSSID of the AP >identifies the PMK the STA should use, while the PMKID was an >after-thought to 802.11i, and was not properly integrated to perform >the function required of it. In particular, the binding of BSSIDs and >STA MAC addresses to the PMKID was never undertaken. Therefore, if the >BSSID changes, the STA has to assume that the PMK has been compromised, >unless the AAA server gives it some reason to believe the new BSSID is >also bound to the same PMK. > >-----Original Message----- >From: Yang, Lily L >Sent: Friday, October 22, 2004 12:59 PM >To: Walker, Jesse; housley@vigilsec.com >Subject: FW: [Capwap] Important: please provide input on comment >resolution for CAPWAP Taxonomy draft > >Here is some other responds to the comment. > >-----Original Message----- >From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On >Behalf Of Michael Montemurro >Sent: Thursday, October 21, 2004 8:12 AM >To: 'Pat R. Calhoun'; 'Chunduru Rama Krishna Prasad'; >capwap@frascone.com >Subject: RE: [Capwap] Important: please provide input on comment >resolution for CAPWAP Taxonomy draft > >I'd agree that the text should likely remain. However, there should be >work done (likely in both IEEE and IETF) to modify the key hierarchy to >address this case. > > Mike > >-----Original Message----- >From: Pat R. Calhoun [mailto:pcalhoun@airespace.com] >Sent: Thursday, October 21, 2004 10:47 AM >To: Michael Montemurro; Chunduru Rama Krishna Prasad; >capwap@frascone.com >Subject: RE: [Capwap] Important: please provide input on comment >resolution for CAPWAP Taxonomy draft > > >The comment may be valid in light of 802.11r. I'd argue that the text >remains since we need to be cognizant of not only current IEEE >standards, but also the ones in progress. > >PatC >-----Original Message----- >From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On >Behalf Of Chunduru Rama Krishna Prasad >Sent: Thursday, October 21, 2004 5:27 AM >To: capwap@frascone.com >Subject: Re: [Capwap] Important: please provide input on comment >resolution for CAPWAP Taxonomy draft > > >hi all, > >I am not sure, I am right on this. My impression is that, PMK is on per >Authenticator MAC address. If the station is re-associated with new WTP >(different MAC address), then it would not even send PMKID of old AP. >If there is no PMKID found in reassoc event, AC would start with full >802.1x authentication. If the station is reassociating with an AP, to >which it already established PMK before, then station sends PMKID and >in that case only 4 way key handshake is requried to get the PTK. With >respect to this, I am not sure whether the statement 'If PMK is shared >across multiple WTP' is valid. If not, the whole statement can be >removed from the draft > >Regards >Rama Krishna Prasad > > > >Ch. Rama Krishna Prasad >Intoto Software(I) Pvt Ltd, >Uma Plaza, Nagarjuna circle, >Panjagutta. Hyderabad, AP >Tel No:s 2335 8927/8928/8434 > >_______________________________________________ >Capwap mailing list >Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap > >_______________________________________________ >Capwap mailing list >Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap > >_______________________________________________ >Capwap mailing list >Capwap@frascone.com >http://mail.frascone.com/mailman/listinfo/capwap >_______________________________________________ >Capwap mailing list >Capwap@frascone.com >http://mail.frascone.com/mailman/listinfo/capwap _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Mon Oct 25 16:29:07 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04819 for ; Mon, 25 Oct 2004 16:29:06 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id BC0C31FD70; Mon, 25 Oct 2004 16:29:07 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 54F051FD68; Mon, 25 Oct 2004 16:29:04 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 825E91FD6B for ; Mon, 25 Oct 2004 16:28:28 -0400 (EDT) Received: from homebrew.trpz.com (66-7-225-40.cust.telepacific.net [66.7.225.40]) by mail.frascone.com (Postfix) with ESMTP id 7FC481FD68 for ; Mon, 25 Oct 2004 16:28:25 -0400 (EDT) Received: from trpz.com (localhost.trpz.com [127.0.0.1]) by homebrew.trpz.com (8.13.1/8.13.1) with ESMTP id i9PKRZvi079422; Mon, 25 Oct 2004 13:27:35 -0700 (PDT) (envelope-from dharkins@trpz.com) Message-Id: <200410252027.i9PKRZvi079422@homebrew.trpz.com> To: "Yang, Lily L" Cc: capwap@frascone.com, "Walker, Jesse" , housley@vigilsec.com Subject: Re: [Capwap] Important: please provide input on comment resolution for CAPWAP Taxonomy draft In-Reply-To: Your message of "Mon, 25 Oct 2004 09:37:30 PDT." <2AF68A477DD44C4EBCBE338C24E7A9EE027DBC2E@orsmsx408> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <79420.1098736055.1@trpz.com> From: Dan Harkins X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Mon, 25 Oct 2004 13:27:35 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) This is not an issue of what vendors want to believe. If the supplicant informed the authentication server of the BSSID of the AP while it was deriving the PMK (and it should also properly identify itself in a manner that the AP will identify it, i.e. it's MAC address and not some meta-identity like a "username"), and if the authentication server had its trusted relationship with an entity identified by the BSSID and not something completely different (like an IP address of a different interface) we could have a PMK bound to BSSID and the supplicant's MAC address. But that is not what we have. What we have is a PMK derived by the supplicant and authentication server with no binding of MAC addresses or BSSIDs. The two peers identify themselves by meta-identities (like the DN of a certificate, or a username) and the supplicant never indicates its desire to use this secret for communication with a different entity, much less identify that entity. Since the authentication server doesn't know the BSSID of the AP (and the supplicant never told it that the PMK was to be shared with that BSSID) there is no way that the PMK can be bound to it. Dan. On Mon, 25 Oct 2004 09:37:30 PDT you wrote > Another response from Jesse on this ... > > -----Original Message----- > From: Walker, Jesse > Sent: Saturday, October 23, 2004 7:06 PM > To: Yang, Lily L; 'housley@vigilsec.com' > Subject: RE: [Capwap] Important: please provide input on comment > resolution for CAPWAP Taxonomy draft > > Whether vendors want to believe it or not, the BSSID of the AP > identifies the PMK the STA should use, while the PMKID was an > after-thought to 802.11i, and was not properly integrated to perform the > function required of it. In particular, the binding of BSSIDs and STA > MAC addresses to the PMKID was never undertaken. Therefore, if the BSSID > changes, the STA has to assume that the PMK has been compromised, unless > the AAA server gives it some reason to believe the new BSSID is also > bound to the same PMK. > > -----Original Message----- > From: Yang, Lily L > Sent: Friday, October 22, 2004 12:59 PM > To: Walker, Jesse; housley@vigilsec.com > Subject: FW: [Capwap] Important: please provide input on comment > resolution for CAPWAP Taxonomy draft > > Here is some other responds to the comment. > > -----Original Message----- > From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On > Behalf Of Michael Montemurro > Sent: Thursday, October 21, 2004 8:12 AM > To: 'Pat R. Calhoun'; 'Chunduru Rama Krishna Prasad'; > capwap@frascone.com > Subject: RE: [Capwap] Important: please provide input on comment > resolution for CAPWAP Taxonomy draft > > I'd agree that the text should likely remain. However, there should be > work done (likely in both IEEE and IETF) to modify the key hierarchy to > address this case. > > Mike > > -----Original Message----- > From: Pat R. Calhoun [mailto:pcalhoun@airespace.com] > Sent: Thursday, October 21, 2004 10:47 AM > To: Michael Montemurro; Chunduru Rama Krishna Prasad; > capwap@frascone.com > Subject: RE: [Capwap] Important: please provide input on comment > resolution for CAPWAP Taxonomy draft > > > The comment may be valid in light of 802.11r. I'd argue that the text > remains since we need to be cognizant of not only current IEEE > standards, but also the ones in progress. > PatC > -----Original Message----- > From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On > Behalf Of Chunduru Rama Krishna Prasad > Sent: Thursday, October 21, 2004 5:27 AM > To: capwap@frascone.com > Subject: Re: [Capwap] Important: please provide input on comment > resolution for CAPWAP Taxonomy draft > > > hi all, > > I am not sure, I am right on this. My impression is that, PMK is on per > Authenticator MAC address. If the station is re-associated with new WTP > (different MAC address), then it would not even send PMKID of old AP. If > there is no PMKID found in reassoc event, AC would start with full > 802.1x authentication. If the station is reassociating with an AP, to > which it already established PMK before, then station sends PMKID and in > that case only 4 way key handshake is requried to get the PTK. With > respect to this, I am not sure whether the statement 'If PMK is shared > across multiple WTP' is valid. If not, the whole statement can be > removed from the draft > > Regards > Rama Krishna Prasad > > > > Ch. Rama Krishna Prasad > Intoto Software(I) Pvt Ltd, > Uma Plaza, Nagarjuna circle, > Panjagutta. Hyderabad, AP > Tel No:s 2335 8927/8928/8434 > > _______________________________________________ > Capwap mailing list > Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap > > _______________________________________________ > Capwap mailing list > Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap > > _______________________________________________ > Capwap mailing list > Capwap@frascone.com > http://mail.frascone.com/mailman/listinfo/capwap > _______________________________________________ > Capwap mailing list > Capwap@frascone.com > http://mail.frascone.com/mailman/listinfo/capwap > _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Mon Oct 25 16:36:07 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA06070 for ; Mon, 25 Oct 2004 16:36:06 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 8347C1FCBF; Mon, 25 Oct 2004 16:36:07 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id CE3041FD68; Mon, 25 Oct 2004 16:36:03 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 1133C1FD68 for ; Mon, 25 Oct 2004 16:35:41 -0400 (EDT) Received: from homebrew.trpz.com (66-7-225-40.cust.telepacific.net [66.7.225.40]) by mail.frascone.com (Postfix) with ESMTP id 01EEC1FCBF for ; Mon, 25 Oct 2004 16:35:39 -0400 (EDT) Received: from trpz.com (localhost.trpz.com [127.0.0.1]) by homebrew.trpz.com (8.13.1/8.13.1) with ESMTP id i9PKYnPc079452; Mon, 25 Oct 2004 13:34:49 -0700 (PDT) (envelope-from dharkins@trpz.com) Message-Id: <200410252034.i9PKYnPc079452@homebrew.trpz.com> To: Clint Chaplin Cc: "Pat R. Calhoun" , Russ Housley , "Walker, Jesse" , "Yang, Lily L" , capwap@frascone.com Subject: Re: [Capwap] Important: please provide input on comment resolution for CAPWAP Taxonomy draft In-Reply-To: Your message of "Mon, 25 Oct 2004 10:57:51 PDT." MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <79450.1098736489.1@trpz.com> From: Dan Harkins X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Mon, 25 Oct 2004 13:34:49 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) On Mon, 25 Oct 2004 10:57:51 PDT you wrote > "The CAPWAP architecture "enables" 802.11r to function." Say what? > > Number one, I didn't think there was a CAPWAP "architecture"; well, at > least this group hasn't been able to define one. CAPWAP is more a > protocol.... Whoa, whoa, whoa! CAPWAP is a taxonomy. And maybe it can become an "architecture". We shall see. But what CAPWAP is definitely not (in spite of some laughable press releases to the contrary) is a protocol. It might become one some day, but it is not one now. Dan. _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Mon Oct 25 16:47:12 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07673 for ; Mon, 25 Oct 2004 16:47:09 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 3368B1FCBF; Mon, 25 Oct 2004 16:47:08 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id CE8161FD5A; Mon, 25 Oct 2004 16:47:04 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 422421FD5A for ; Mon, 25 Oct 2004 16:46:07 -0400 (EDT) Received: from AIREMAIL.airespace.com (da001d3897.stl-mo.osd.concentric.net [66.236.111.57]) by mail.frascone.com (Postfix) with ESMTP id C305D1FCBF for ; Mon, 25 Oct 2004 16:46:01 -0400 (EDT) Content-class: urn:content-classes:message Subject: RE: [Capwap] Important: please provide input on commentresolution for CAPWAP Taxonomy draft MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Message-ID: <55749BC69138654EBBC4C50BA4F556105A2F99@AIREMAIL.airespace.com> Thread-Topic: [Capwap] Important: please provide input on commentresolution for CAPWAP Taxonomy draft Thread-Index: AcS60raQZ5q+4fAQQD6n9knh6felnQAAAiOA From: "Pat R. Calhoun" To: "Clint Chaplin" , , Cc: , , , X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Mon, 25 Oct 2004 13:45:59 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: quoted-printable I am going to try to kill this thread before it gets out of hand. Noone ever mentioned a specific protocol, so this is only distracting us from the task of trying to get some closure on the current Taxonomy draft. I believe *some* of us are trying to make some progress within this working group, and that will (hopefully) eventually lead to protocol design - regardless of its name, shape or color. PatC=20 -----Original Message----- From: Clint Chaplin [mailto:cchaplin@sj.symbol.com]=20 Sent: Monday, October 25, 2004 1:39 PM To: clint.chaplin@gmail.com; dharkins@trpz.com Cc: Pat R. Calhoun; capwap@frascone.com; jesse.walker@intel.com; lily.l.yang@intel.com; housley@vigilsec.com Subject: Re: [Capwap] Important: please provide input on commentresolution for CAPWAP Taxonomy draft Well, let's even back up one here: capwap is a group within the IETF. Whatever taxonomy or protocol they may come up with has not been titled. One of the published protocols (I-D) is LWAPP, but wasn't necessarily part of the capwap group. Clint (JOATMON) Chaplin Wireless Security Advisor Wireless Standards Lead >>> Dan Harkins 10/25/04 13:34:49 >>> On Mon, 25 Oct 2004 10:57:51 PDT you wrote > "The CAPWAP architecture "enables" 802.11r to function." Say what? >=20 > Number one, I didn't think there was a CAPWAP "architecture"; well, at > least this group hasn't been able to define one. CAPWAP is more a=20 > protocol.... Whoa, whoa, whoa!=20 CAPWAP is a taxonomy. And maybe it can become an "architecture". We shall see. But what CAPWAP is definitely not (in spite of some laughable press releases to the contrary) is a protocol. It might become one some day, but it is not one now. Dan. _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap=20 ________________________________________________________________________ This email has been scanned for computer viruses. _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Mon Oct 25 16:57:17 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08575 for ; Mon, 25 Oct 2004 16:57:08 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 56CDE1FD5A; Mon, 25 Oct 2004 16:57:08 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id CF79B1FD68; Mon, 25 Oct 2004 16:57:04 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 2C2091FD68 for ; Mon, 25 Oct 2004 16:56:28 -0400 (EDT) Received: from homebrew.trpz.com (66-7-225-40.cust.telepacific.net [66.7.225.40]) by mail.frascone.com (Postfix) with ESMTP id 88F181FD5A for ; Mon, 25 Oct 2004 16:56:25 -0400 (EDT) Received: from trpz.com (localhost.trpz.com [127.0.0.1]) by homebrew.trpz.com (8.13.1/8.13.1) with ESMTP id i9PKtZGO079569; Mon, 25 Oct 2004 13:55:35 -0700 (PDT) (envelope-from dharkins@trpz.com) Message-Id: <200410252055.i9PKtZGO079569@homebrew.trpz.com> To: "Walker, Jesse" Cc: "Yang, Lily L" , capwap@frascone.com, housley@vigilsec.com Subject: Re: FW: [Capwap] Important: please provide input on comment resolution for CAPWAP Taxonomy draft In-Reply-To: Your message of "Mon, 25 Oct 2004 13:03:24 PDT." MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <79567.1098737735.1@trpz.com> From: Dan Harkins X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Mon, 25 Oct 2004 13:55:35 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Jesse, Common courtesy dictates that one should not merely state "you are wrong" but to explain exactly where one is wrong. Abstract language is getting in the way of my point so let me just use common vernacular that is descriptive of what is deployed today: If I can try to boil this down I think the residue we will be left with is that you believe that there is a one-to-one relationship between a RADIUS client and a BSSID that a supplicant speaks to and that the identity of the RADIUS client and BSSID are interchangable. It is that belief, I believe, that causes you to infer a binding of PMK to BSSID when, strictly speaking, none exists. The RADIUS server has a trust relationship with a RADIUS client. That RADIUS client is identified, to the RADIUS server, with an IP address. You are assuming that that RADIUS client, identified by its IP address, has one and only one BSSID. This is incorrect. Furthermore you are assuming that this 3 way protocol between the supplicant, the RADIUS server, and the RADIUS client is 1) secure; and 2) extensible to a different identity of the RADIUS client, a BSSID, without loss of security. Feel free to tell me I'm wrong again, but please tell me where and how. Dan. On Mon, 25 Oct 2004 13:03:24 PDT you wrote > Dan, > > You are wrong. The problem is there is no Needham-Shroeder-eseque > protocol in the back end. > > -- Jesse > > -----Original Message----- > From: Dan Harkins [mailto:dharkins@trpz.com] > Sent: Monday, October 25, 2004 12:58 PM > To: Yang, Lily L > Cc: capwap@frascone.com; Walker, Jesse; housley@vigilsec.com > Subject: Re: FW: [Capwap] Important: please provide input on comment > resolution for CAPWAP Taxonomy draft > > I beg to differ. > > If this was a Needham-Schroeder-esqe protocol Jesse might have a > point. But it's not. > > There is no way for a "properly implemented" client to know that the > AP it is speaking to is trusted by the authentication server since > nothing in the exchange that derives the PMK includes anything about > the AP. It's merely a man-in-the-middle. The AP proves knowledge of the > PMK so the client is just supposed to assume it's trusted! What is being > asked here is just ignore that unpleasant > security issue and believe we have a > secure > 3-party authenticaiton system here so that we can then condemn a scheme > that suffers from that same unpleasant security issue. > > How does a "properly implemented" client know that AP2 is not a > attacker which compromised AP1? By the same technique that it used > to know that AP1 was not an attacker which compromised the authen- > tication server (or the link between the authentication server and a > legitimate authenticator). Since a "properly implemented" client can > do the latter it can take the same steps to do the former. > > If mere proof of possession of the PMK is enough to legitimize AP1 > to the client then mere proof of possession of the PMK is enough to > legitimize AP2 to the client. You cannot reasonably claim otherwise. > > This is not to say that Jesse's suggestions of (a) or (b) below > are not needed, I would welcome either of those. I would also like > to note that Jesse's mention of (c) is an explicit acknowledgment > that "PMK sharing" is permitted by the existing specification. > > Dan. > > On Mon, 25 Oct 2004 09:33:05 PDT you wrote > > I solicited input from Jesse Walker and Russ Housley on the issue of > PMK > > sharing, and here is the response from Jesse. He agrees to let me > > forward this to the CAPWAP list. I also cc Jesse and Russ here. Since > > Russ posted the original comment in IESG review, and Jesse is the > > technical editor of 11i, I think it would be good that we keep them in > > the loop with regard this discussion. So please cc them in your email > > posting on this issue as they are not in the CAPWAP list. > > > > -----Original Message----- > > From: Walker, Jesse > > Sent: Saturday, October 23, 2004 7:05 PM > > To: Yang, Lily L; 'housley@vigilsec.com' > > Subject: RE: [Capwap] Important: please provide input on comment > > resolution for CAPWAP Taxonomy draft > > > > Lily, > > > > Dan's reasoning is invalid, unless he or someone else can produce a > > deterministic algorithm that allows the client to distinguish the > > following two cases: > > > > Case 1: AP1 and AP2 are classical access points. An attacker > compromises > > AP1 and AP2 and moves the client's PMK from AP1 and AP2. > > > > Case 2: AP1 and AP2 are two light-weight access points that are part > of > > the same switch S. The switch S uses the same PMK with both AP1 and > AP2. > > > > If no one can demonstrate a deterministic algorithm the client can use > > to distinguish the two cases, then a properly implemented client will > > always assume its PMK has been compromised when it sees either case. I > > suspect no one can, because the client lacks the necessary state. > > > > It appears to me there are three possible solutions: > > > > a. The first is the necessary state is somehow delivered to the client > > in an attestable fashion. The only party that client trusts is the AAA > > server, so this implies a new binding protocol between the AAA server > > and the EAP Peer. > > > > b. The second is to define a new protocol that delivers the AP's > > authenticated identifier to the EAP Peer in an attestable fashion, and > > to change the 802.11i key confirmation handshake to use this > identifier > > instead of the BSSID of the APs. > > > > c. The text that permits this usage should be removed. > > > > I believe possibilities (a) or (b) are the right way to address this > > issue. > > > > -- Jesse > > > > -----Original Message----- > > From: Yang, Lily L > > Sent: Friday, October 22, 2004 12:03 PM > > To: Walker, Jesse; housley@vigilsec.com > > Subject: FW: [Capwap] Important: please provide input on comment > > resolution for CAPWAP Taxonomy draft > > Importance: High > > > > Jesse and Russ -- > > > > CAPWAP WG has had some email discussion regarding the comment from you > > on PMK sharing. I don't think either of you are on the list, so I am > > forwarding to you this and I would like to hear what you think about > > these responses. > > > > Lily > > > > -----Original Message----- > > From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On > > Behalf Of Dan Harkins > > Sent: Thursday, October 21, 2004 9:47 AM > > To: Chunduru Rama Krishna Prasad > > Cc: capwap@frascone.com > > Subject: Re: [Capwap] Important: please provide input on comment > > resolution for CAPWAP Taxonomy draft > > > > Strictly speaking the PMK is shared between the supplicant and the > > authentication server, not the authenticator. There are no MAC > addresses > > bound to the PMK or used in the derivation of the PMK. > > > > As the person who got PMK caching and PMKIDs into the 802.11i draft > > let me explain the steps we went through: > > > > - first motion was to indicate the ability of a STA to do "PMK > > caching" > > in an associate request. If the authenticator had a cached PMK for > > the STA it would respond with the 1st message of the 4way > handshake, > > otherwise it would respond with an 802.1x encapsulated EAP > Identity > > request. That enabled the functionality you describe below-- "the > > station is reassociating with an AP to with it already established > > the PMK before..." It prevented a STA in a difficult RF > environment > > from ping-ponging back and forth between APs and hammering an > > authentication server. > > > > - it soon became apparent that an authenticator may have multiple > PMKs > > for a particular STA in its cache. How? Via something like a > > pro-active > > key pushing mechanism using neighbor graphs (Bill Arbaugh > presented > > this idea). So the next motion was to name PMKs with a PMKID to > > indicate which PMK a STA is asserting in its associate request. > > This eliminated the ambiguity. > > > > So the very reason that we have PMKIDs, and not just blind assertions > of > > a cached PMK, is because the PMK may be used to derive a PTK for > > multiple APs. The statement "If PMK is shared across multiple WTPs" > is, > > indeed, valid. > > > > Addressing Russ's comment, the PMK is already leaked because it is > > given to the authenticator by the authentication server. When > discussing > > "the number of other people who know my secret" there are 3 possible > > values: 0, 1 and infinity. If 0 other people know your secret there > are > > certain cryptographic properties associated with that state. If 1 > other > > person knows your secret there are other cryptographic properties > > associated with that state (message source authentication for > instance), > > but if more than 1 person knows your secret then it doesn't matter if > > it's 2 or 22, the cryptographic properties are the same (it is > possible > > for someone to impersonate you, forge your messages, read your > > messages, etc). > > > > Of course you can say that in the 802.11i case the authenticator is > > "trusted" and therefore it's OK for the authentication server to leak > > the secret to the authenticator (and have 3 people know the secret). > > OK, fine. The other AP is also "trusted" to have the PMK so now 4 > people > > know the secret (or 5 "trusted" people or 10 "trusted" people). > Nothing > > changed. > > > > In the case of a switch hosting multiple APs the switch is the > > authenticator and the APs are merely tentacles of the same octopus. > The > > PMK isn't shared among the APs, it resides on the switch. There is > even > > one company I know of (I won't name it but it shouldn't be difficult > to > > guess) in which the switch plays the role of the authentication server > > so the PMK is known only by the switch and the STA. This "PMK sharing" > > situation is even MORE secure than the traditional deployment where a > > STA > > establishes a PMK with a RADIUS server and that PMK is leaked to an > AP. > > > > Dan. > > > > On Thu, 21 Oct 2004 14:56:37 +0530 you wrote > > > hi all, > > > > > > I am not sure, I am right on this. My impression is that, PMK is on > > per > > > Authenticator MAC address. > > > If the station is re-associated with new WTP (different MAC > address), > > then > > > it would not even send > > > PMKID of old AP. If there is no PMKID found in reassoc event, AC > would > > > > > start with full 802.1x > > > authentication. If the station is reassociating with an AP, to which > > it > > > already established PMK before, > > > then station sends PMKID and in that case only 4 way key handshake > is > > > requried to get the PTK. > > > With respect to this, I am not sure whether the statement > > > 'If PMK is shared across multiple WTP' is valid. If not, the whole > > > statement can be removed > > > from the draft > > > > > > Regards > > > Rama Krishna Prasad > > > > > > > > > > > > Ch. Rama Krishna Prasad > > > Intoto Software(I) Pvt Ltd, > > > Uma Plaza, Nagarjuna circle, > > > Panjagutta. Hyderabad, AP > > > Tel No:s 2335 8927/8928/8434 > > > > > > _______________________________________________ > > > Capwap mailing list > > > Capwap@frascone.com > > > http://mail.frascone.com/mailman/listinfo/capwap > > _______________________________________________ > > Capwap mailing list > > Capwap@frascone.com > > http://mail.frascone.com/mailman/listinfo/capwap > > _______________________________________________ > > Capwap mailing list > > Capwap@frascone.com > > http://mail.frascone.com/mailman/listinfo/capwap > > > _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Mon Oct 25 18:07:08 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA24841 for ; Mon, 25 Oct 2004 18:07:07 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id A1B101FC64; Mon, 25 Oct 2004 18:07:08 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 36C9D1FCBF; Mon, 25 Oct 2004 18:07:04 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 13E931FCBF for ; Mon, 25 Oct 2004 18:06:08 -0400 (EDT) Received: from homebrew.trpz.com (66-7-225-40.cust.telepacific.net [66.7.225.40]) by mail.frascone.com (Postfix) with ESMTP id 00A921FC64 for ; Mon, 25 Oct 2004 18:06:05 -0400 (EDT) Received: from trpz.com (localhost.trpz.com [127.0.0.1]) by homebrew.trpz.com (8.13.1/8.13.1) with ESMTP id i9PM5FOm079893; Mon, 25 Oct 2004 15:05:15 -0700 (PDT) (envelope-from dharkins@trpz.com) Message-Id: <200410252205.i9PM5FOm079893@homebrew.trpz.com> To: "Walker, Jesse" Cc: "Yang, Lily L" , capwap@frascone.com, housley@vigilsec.com Subject: Re: FW: [Capwap] Important: please provide input on comment resolution for CAPWAP Taxonomy draft In-Reply-To: Your message of "Mon, 25 Oct 2004 14:28:16 PDT." MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <79891.1098741915.1@trpz.com> From: Dan Harkins X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Mon, 25 Oct 2004 15:05:15 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Jesse, You are not addressing any of the issues I raised in response to your previous demand for a deterministic algorithm, you're just repeating yourself. I was trying to point out how the security of the system is not lessened by the lack of such an algorithm. I asked you to show me where in that email I was wrong and how I was wrong. I even added some more analysis of what I think is the crux of the matter. You ignored it all. Sigh, Dan. On Mon, 25 Oct 2004 14:28:16 PDT you wrote > Dan, > > I have already explained this, but will do so again out of common > courtesy. Please provide a deterministic algorithm by which a client > determines whether PMK sharing between AP1 and AP2 is acceptable or > represents a compromise, using information available to it under > 802.11i. If you produce such an algorithm, then I withdraw my claim and > apologize. If you cannot, then my assertion stands. > > -- Jesse > > -----Original Message----- > From: Dan Harkins [mailto:dharkins@trpz.com] > Sent: Monday, October 25, 2004 1:56 PM > To: Walker, Jesse > Cc: Yang, Lily L; capwap@frascone.com; housley@vigilsec.com > Subject: Re: FW: [Capwap] Important: please provide input on comment > resolution for CAPWAP Taxonomy draft > > Jesse, > > Common courtesy dictates that one should not merely state "you are > wrong" but to explain exactly where one is wrong. > > Abstract language is getting in the way of my point so let me > just use common vernacular that is descriptive of what is deployed > today: > > If I can try to boil this down I think the residue we will be left > with is that you believe that there is a one-to-one relationship > between a RADIUS client and a BSSID that a supplicant speaks to and > that the identity of the RADIUS client and BSSID are interchangable. > It is that belief, I believe, that causes you to infer a binding of > PMK to BSSID when, strictly speaking, none exists. > > The RADIUS server has a trust relationship with a RADIUS client. > That RADIUS client is identified, to the RADIUS server, with an IP > address. You are assuming that that RADIUS client, identified by > its IP address, has one and only one BSSID. This is incorrect. > Furthermore you are assuming that this 3 way protocol between the > supplicant, the RADIUS server, and the RADIUS client is 1) secure; > and 2) extensible to a different identity of the RADIUS client, a > BSSID, without loss of security. > > Feel free to tell me I'm wrong again, but please tell me where > and how. > > Dan. > > On Mon, 25 Oct 2004 13:03:24 PDT you wrote > > Dan, > > > > You are wrong. The problem is there is no Needham-Shroeder-eseque > > protocol in the back end. > > > > -- Jesse > > > > -----Original Message----- > > From: Dan Harkins [mailto:dharkins@trpz.com] > > Sent: Monday, October 25, 2004 12:58 PM > > To: Yang, Lily L > > Cc: capwap@frascone.com; Walker, Jesse; housley@vigilsec.com > > Subject: Re: FW: [Capwap] Important: please provide input on comment > > resolution for CAPWAP Taxonomy draft > > > > I beg to differ. > > > > If this was a Needham-Schroeder-esqe protocol Jesse might have a > > point. But it's not. > > > > There is no way for a "properly implemented" client to know that the > > AP it is speaking to is trusted by the authentication server since > > nothing in the exchange that derives the PMK includes anything about > > the AP. It's merely a man-in-the-middle. The AP proves knowledge of > the > > PMK so the client is just supposed to assume it's trusted! What is > being > > asked here is just ignore that unpleasant > > security issue and believe we have a > > secure > > 3-party authenticaiton system here so that we can then condemn a > scheme > > that suffers from that same unpleasant security issue. > > > > How does a "properly implemented" client know that AP2 is not a > > attacker which compromised AP1? By the same technique that it used > > to know that AP1 was not an attacker which compromised the authen- > > tication server (or the link between the authentication server and a > > legitimate authenticator). Since a "properly implemented" client can > > do the latter it can take the same steps to do the former. > > > > If mere proof of possession of the PMK is enough to legitimize AP1 > > to the client then mere proof of possession of the PMK is enough to > > legitimize AP2 to the client. You cannot reasonably claim otherwise. > > > > This is not to say that Jesse's suggestions of (a) or (b) below > > are not needed, I would welcome either of those. I would also like > > to note that Jesse's mention of (c) is an explicit acknowledgment > > that "PMK sharing" is permitted by the existing specification. > > > > Dan. > > > > On Mon, 25 Oct 2004 09:33:05 PDT you wrote > > > I solicited input from Jesse Walker and Russ Housley on the issue of > > PMK > > > sharing, and here is the response from Jesse. He agrees to let me > > > forward this to the CAPWAP list. I also cc Jesse and Russ here. > Since > > > Russ posted the original comment in IESG review, and Jesse is the > > > technical editor of 11i, I think it would be good that we keep them > in > > > the loop with regard this discussion. So please cc them in your > email > > > posting on this issue as they are not in the CAPWAP list. > > > > > > -----Original Message----- > > > From: Walker, Jesse > > > Sent: Saturday, October 23, 2004 7:05 PM > > > To: Yang, Lily L; 'housley@vigilsec.com' > > > Subject: RE: [Capwap] Important: please provide input on comment > > > resolution for CAPWAP Taxonomy draft > > > > > > Lily, > > > > > > Dan's reasoning is invalid, unless he or someone else can produce a > > > deterministic algorithm that allows the client to distinguish the > > > following two cases: > > > > > > Case 1: AP1 and AP2 are classical access points. An attacker > > compromises > > > AP1 and AP2 and moves the client's PMK from AP1 and AP2. > > > > > > Case 2: AP1 and AP2 are two light-weight access points that are part > > of > > > the same switch S. The switch S uses the same PMK with both AP1 and > > AP2. > > > > > > If no one can demonstrate a deterministic algorithm the client can > use > > > to distinguish the two cases, then a properly implemented client > will > > > always assume its PMK has been compromised when it sees either case. > I > > > suspect no one can, because the client lacks the necessary state. > > > > > > It appears to me there are three possible solutions: > > > > > > a. The first is the necessary state is somehow delivered to the > client > > > in an attestable fashion. The only party that client trusts is the > AAA > > > server, so this implies a new binding protocol between the AAA > server > > > and the EAP Peer. > > > > > > b. The second is to define a new protocol that delivers the AP's > > > authenticated identifier to the EAP Peer in an attestable fashion, > and > > > to change the 802.11i key confirmation handshake to use this > > identifier > > > instead of the BSSID of the APs. > > > > > > c. The text that permits this usage should be removed. > > > > > > I believe possibilities (a) or (b) are the right way to address this > > > issue. > > > > > > -- Jesse > > > > > > -----Original Message----- > > > From: Yang, Lily L > > > Sent: Friday, October 22, 2004 12:03 PM > > > To: Walker, Jesse; housley@vigilsec.com > > > Subject: FW: [Capwap] Important: please provide input on comment > > > resolution for CAPWAP Taxonomy draft > > > Importance: High > > > > > > Jesse and Russ -- > > > > > > CAPWAP WG has had some email discussion regarding the comment from > you > > > on PMK sharing. I don't think either of you are on the list, so I am > > > forwarding to you this and I would like to hear what you think about > > > these responses. > > > > > > Lily > > > > > > -----Original Message----- > > > From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] > On > > > Behalf Of Dan Harkins > > > Sent: Thursday, October 21, 2004 9:47 AM > > > To: Chunduru Rama Krishna Prasad > > > Cc: capwap@frascone.com > > > Subject: Re: [Capwap] Important: please provide input on comment > > > resolution for CAPWAP Taxonomy draft > > > > > > Strictly speaking the PMK is shared between the supplicant and the > > > authentication server, not the authenticator. There are no MAC > > addresses > > > bound to the PMK or used in the derivation of the PMK. > > > > > > As the person who got PMK caching and PMKIDs into the 802.11i > draft > > > let me explain the steps we went through: > > > > > > - first motion was to indicate the ability of a STA to do "PMK > > > caching" > > > in an associate request. If the authenticator had a cached PMK > for > > > the STA it would respond with the 1st message of the 4way > > handshake, > > > otherwise it would respond with an 802.1x encapsulated EAP > > Identity > > > request. That enabled the functionality you describe below-- > "the > > > station is reassociating with an AP to with it already > established > > > the PMK before..." It prevented a STA in a difficult RF > > environment > > > from ping-ponging back and forth between APs and hammering an > > > authentication server. > > > > > > - it soon became apparent that an authenticator may have multiple > > PMKs > > > for a particular STA in its cache. How? Via something like a > > > pro-active > > > key pushing mechanism using neighbor graphs (Bill Arbaugh > > presented > > > this idea). So the next motion was to name PMKs with a PMKID to > > > indicate which PMK a STA is asserting in its associate request. > > > This eliminated the ambiguity. > > > > > > So the very reason that we have PMKIDs, and not just blind > assertions > > of > > > a cached PMK, is because the PMK may be used to derive a PTK for > > > multiple APs. The statement "If PMK is shared across multiple WTPs" > > is, > > > indeed, valid. > > > > > > Addressing Russ's comment, the PMK is already leaked because it is > > > given to the authenticator by the authentication server. When > > discussing > > "the number of other people who know my secret" there are 3 possible > > > values: 0, 1 and infinity. If 0 other people know your secret there > > are > > > certain cryptographic properties associated with that state. If 1 > > other > > > person knows your secret there are other cryptographic properties > > > associated with that state (message source authentication for > > instance), > > > but if more than 1 person knows your secret then it doesn't matter > if > > > it's 2 or 22, the cryptographic properties are the same (it is > > possible > > > for someone to impersonate you, forge your messages, read your > > > messages, etc). > > > > > > Of course you can say that in the 802.11i case the authenticator > is > > > "trusted" and therefore it's OK for the authentication server to > leak > > > the secret to the authenticator (and have 3 people know the secret). > > > OK, fine. The other AP is also "trusted" to have the PMK so now 4 > > people > > > know the secret (or 5 "trusted" people or 10 "trusted" people). > > Nothing > > > changed. > > > > > > In the case of a switch hosting multiple APs the switch is the > > > authenticator and the APs are merely tentacles of the same octopus. > > The > > > PMK isn't shared among the APs, it resides on the switch. There is > > even > > > one company I know of (I won't name it but it shouldn't be difficult > > to > > > guess) in which the switch plays the role of the authentication > server > > > so the PMK is known only by the switch and the STA. This "PMK > sharing" > > > situation is even MORE secure than the traditional deployment where > a > > > STA > > > establishes a PMK with a RADIUS server and that PMK is leaked to an > > AP. > > > > > > Dan. > > > > > > On Thu, 21 Oct 2004 14:56:37 +0530 you wrote > > > > hi all, > > > > > > > > I am not sure, I am right on this. My impression is that, PMK is > on > > > per > > > > Authenticator MAC address. > > > > If the station is re-associated with new WTP (different MAC > > address), > > > then > > > > it would not even send > > > > PMKID of old AP. If there is no PMKID found in reassoc event, AC > > would > > > > > > > start with full 802.1x > > > > authentication. If the station is reassociating with an AP, to > which > > > it > > > > already established PMK before, > > > > then station sends PMKID and in that case only 4 way key handshake > > is > > > > requried to get the PTK. > > > > With respect to this, I am not sure whether the statement > > > > 'If PMK is shared across multiple WTP' is valid. If not, the whole > > > > > statement can be removed > > > > from the draft > > > > > > > > Regards > > > > Rama Krishna Prasad > > > > > > > > > > > > > > > > Ch. Rama Krishna Prasad > > > > Intoto Software(I) Pvt Ltd, > > > > Uma Plaza, Nagarjuna circle, > > > > Panjagutta. Hyderabad, AP > > > > Tel No:s 2335 8927/8928/8434 > > > > > > > > _______________________________________________ > > > > Capwap mailing list > > > > Capwap@frascone.com > > > > http://mail.frascone.com/mailman/listinfo/capwap > > > _______________________________________________ > > > Capwap mailing list > > > Capwap@frascone.com > > > http://mail.frascone.com/mailman/listinfo/capwap > > > _______________________________________________ > > > Capwap mailing list > > > Capwap@frascone.com > > > http://mail.frascone.com/mailman/listinfo/capwap > > > > > > _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Mon Oct 25 19:55:10 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA20280 for ; Mon, 25 Oct 2004 19:55:09 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id BFCC21FC64; Mon, 25 Oct 2004 19:55:08 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id ED9E71FCBA; Mon, 25 Oct 2004 19:55:04 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 376D31FCBA for ; Mon, 25 Oct 2004 19:54:26 -0400 (EDT) Received: from homebrew.trpz.com (66-7-225-40.cust.telepacific.net [66.7.225.40]) by mail.frascone.com (Postfix) with ESMTP id 244E61FC64 for ; Mon, 25 Oct 2004 19:54:23 -0400 (EDT) Received: from trpz.com (localhost.trpz.com [127.0.0.1]) by homebrew.trpz.com (8.13.1/8.13.1) with ESMTP id i9PNrW2J080327; Mon, 25 Oct 2004 16:53:33 -0700 (PDT) (envelope-from dharkins@trpz.com) Message-Id: <200410252353.i9PNrW2J080327@homebrew.trpz.com> To: "Walker, Jesse" Cc: "Yang, Lily L" , capwap@frascone.com, housley@vigilsec.com Subject: Re: FW: [Capwap] Important: please provide input on comment resolution for CAPWAP Taxonomy draft In-Reply-To: Your message of "Mon, 25 Oct 2004 15:44:13 PDT." MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <80325.1098748412.1@trpz.com> From: Dan Harkins X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Mon, 25 Oct 2004 16:53:32 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Jesse, That same argument can be made against the existing 3 party exchange between the supplicant, authentication server, and authenticator. In fact, the existing 3 party exchange could be viewed as the degenerate case of "PMK sharing". When the AP asserts possession of the PMK the supplicant has no way of knowing whether that AP is a valid, trusted AP or is an attacker that has compromised another AP (or the AP <--> AS connection) and is playing man-in-the-middle. The reason this is so is because the supplicant never told the authentication server to share the PMK with an entity identified by a particular BSSID (and the authentication server does not maintain a relationship with an entity identified by BSSID anyway), nor did the AP provide some "ticket" to the supplicant proving that it is trusted by the authentication server to know this secret. Either of which would've made this exchange more secure. Can you show me some deterministic way for a supplicant to distinguish between these two: 1. the AAA client (entity trusted by the AS) and radio (that entity identified by a BSSID that the client is speaking to) are different parts of the same device and within the same security boundary. 2. the AAA client is on an AP that has been compromised by an attacker and the radio with which the supplicant is communicating is on the attacker. The attacker relays the EAP exchange through the compromised AP and obtains the PMK. If not then I maintain that there is no less security by doing "PMK sharing". You're including two things in a cryptographic boundary-- the AAA client and radio-- that are not cryptographically bound and are asking the supplicant to make a leap of faith. I can just as easily draw a different cryptographic boundary and ask the supplicant to make an _identical_ leap of faith. You can't have it both ways, if it's OK for the existing 3 party exchange then it's OK for "PMK sharing". Dan. On Mon, 25 Oct 2004 15:44:13 PDT you wrote > Dan, > > Let me go through this yet again. > > In the 802.11i we discussion we said over and over and over and over > again that the PMK must be kept within a single crypto boundary or it is > compromised. > > Now, if you have two classical APs, they represent separate crypto > boundaries, because if you share a PMK between them and you compromise > one AP, then the client's traffic is compromised at the other, while if > you don't share PMKs between them then compromise of one does not lead > to compromise of the client's traffic at the other. > > It follows from the crypto boundaries argument, that different classical > APs must be provisioned with independent PMKs. When this is not done, > the client must treat its own PMK shared across different classical APs > as a violation of its (the client's) security policy, because PMK > sharing explicitly violates the crypto boundaries principle. > > Under 802.11, 802.11i, 802.1X, and EAP the client does not learn whether > an AP is a classical AP or a new switched AP such as what would be > described by CAPWAP. The only thing 802.11 and 802.11i and 802.1X and > EAP provide the client to distinguish one AP from another is the AP's > BSSID. This means every AP looks like a classical AP to a client using > the existing standardized 802.1, 802.11i, 802.1X, and EAP. > > Since the client cannot tell a classical AP from a switched AP, it > follows that a switched AP cannot share PMKs among its different > light-weight APs, because doing so violates the client's security > policy. That is, unless and until it receives evidence to the contrary, > the client must assume that it is communicating with a classical AP, and > PMK reuse between two classical APs violates its policy by violating the > crypto boundary principle. The reason why it must assume this is that it > does not and cannot know the contrary, and security says the client must > make the most conservative assumption consistent with the facts known to > it (performance, manageability, etc., might argue something else, but we > are discussing security here). > > I don't know what is not clear about this. > > -- Jesse > > -----Original Message----- > From: Dan Harkins [mailto:dharkins@trpz.com] > Sent: Monday, October 25, 2004 3:05 PM > To: Walker, Jesse > Cc: Yang, Lily L; capwap@frascone.com; housley@vigilsec.com > Subject: Re: FW: [Capwap] Important: please provide input on comment > resolution for CAPWAP Taxonomy draft > > Jesse, > > You are not addressing any of the issues I raised in response to > your previous demand for a deterministic algorithm, you're just > repeating yourself. I was trying to point out how the security of > the system is not lessened by the lack of such an algorithm. I > asked you to show me where in that email I was wrong and how I > was wrong. I even added some more analysis of what I think is the > crux of the matter. You ignored it all. > > Sigh, > > Dan. > > On Mon, 25 Oct 2004 14:28:16 PDT you wrote > > Dan, > > > > I have already explained this, but will do so again out of common > > courtesy. Please provide a deterministic algorithm by which a client > > determines whether PMK sharing between AP1 and AP2 is acceptable or > > represents a compromise, using information available to it under > > 802.11i. If you produce such an algorithm, then I withdraw my claim > and > > apologize. If you cannot, then my assertion stands. > > > > -- Jesse > > > > -----Original Message----- > > From: Dan Harkins [mailto:dharkins@trpz.com] > > Sent: Monday, October 25, 2004 1:56 PM > > To: Walker, Jesse > > Cc: Yang, Lily L; capwap@frascone.com; housley@vigilsec.com > > Subject: Re: FW: [Capwap] Important: please provide input on comment > > resolution for CAPWAP Taxonomy draft > > > > Jesse, > > > > Common courtesy dictates that one should not merely state "you are > > wrong" but to explain exactly where one is wrong. > > > > Abstract language is getting in the way of my point so let me > > just use common vernacular that is descriptive of what is deployed > > today: > > > > If I can try to boil this down I think the residue we will be left > > with is that you believe that there is a one-to-one relationship > > between a RADIUS client and a BSSID that a supplicant speaks to and > > that the identity of the RADIUS client and BSSID are interchangable. > > It is that belief, I believe, that causes you to infer a binding of > > PMK to BSSID when, strictly speaking, none exists. > > > > The RADIUS server has a trust relationship with a RADIUS client. > > That RADIUS client is identified, to the RADIUS server, with an IP > > address. You are assuming that that RADIUS client, identified by > > its IP address, has one and only one BSSID. This is incorrect. > > Furthermore you are assuming that this 3 way protocol between the > > supplicant, the RADIUS server, and the RADIUS client is 1) secure; > > and 2) extensible to a different identity of the RADIUS client, a > > BSSID, without loss of security. > > > > Feel free to tell me I'm wrong again, but please tell me where > > and how. > > > > Dan. > > > > On Mon, 25 Oct 2004 13:03:24 PDT you wrote > > > Dan, > > > > > > You are wrong. The problem is there is no Needham-Shroeder-eseque > > > protocol in the back end. > > > > > > -- Jesse > > > > > > -----Original Message----- > > > From: Dan Harkins [mailto:dharkins@trpz.com] > > > Sent: Monday, October 25, 2004 12:58 PM > > > To: Yang, Lily L > > > Cc: capwap@frascone.com; Walker, Jesse; housley@vigilsec.com > > > Subject: Re: FW: [Capwap] Important: please provide input on comment > > > resolution for CAPWAP Taxonomy draft > > > > > > I beg to differ. > > > > > > If this was a Needham-Schroeder-esqe protocol Jesse might have a > > > point. But it's not. > > > > > > There is no way for a "properly implemented" client to know that > the > > > AP it is speaking to is trusted by the authentication server since > > > nothing in the exchange that derives the PMK includes anything about > > > the AP. It's merely a man-in-the-middle. The AP proves knowledge of > > the > > > PMK so the client is just supposed to assume it's trusted! What is > > being > > > asked here is just ignore that unpleasant > > > security issue and believe we have a > > > secure > > > 3-party authenticaiton system here so that we can then condemn a > > scheme > > > that suffers from that same unpleasant security issue. > > > > > > How does a "properly implemented" client know that AP2 is not a > > > attacker which compromised AP1? By the same technique that it used > > > to know that AP1 was not an attacker which compromised the authen- > > > tication server (or the link between the authentication server and a > > > legitimate authenticator). Since a "properly implemented" client can > > > do the latter it can take the same steps to do the former. > > > > > > If mere proof of possession of the PMK is enough to legitimize AP1 > > > to the client then mere proof of possession of the PMK is enough to > > > legitimize AP2 to the client. You cannot reasonably claim otherwise. > > > > > > This is not to say that Jesse's suggestions of (a) or (b) below > > > are not needed, I would welcome either of those. I would also like > > > to note that Jesse's mention of (c) is an explicit acknowledgment > > > that "PMK sharing" is permitted by the existing specification. > > > > > > Dan. > > > > > > On Mon, 25 Oct 2004 09:33:05 PDT you wrote > > > > I solicited input from Jesse Walker and Russ Housley on the issue > of > > > PMK > > > > sharing, and here is the response from Jesse. He agrees to let me > > > > forward this to the CAPWAP list. I also cc Jesse and Russ here. > > Since > > > > Russ posted the original comment in IESG review, and Jesse is the > > > > technical editor of 11i, I think it would be good that we keep > them > > in > > > > the loop with regard this discussion. So please cc them in your > > email > > > > posting on this issue as they are not in the CAPWAP list. > > > > > > > > -----Original Message----- > > > > From: Walker, Jesse > > > > Sent: Saturday, October 23, 2004 7:05 PM > > > > To: Yang, Lily L; 'housley@vigilsec.com' > > > > Subject: RE: [Capwap] Important: please provide input on comment > > > > resolution for CAPWAP Taxonomy draft > > > > > > > > Lily, > > > > > > > > Dan's reasoning is invalid, unless he or someone else can produce > a > > > > deterministic algorithm that allows the client to distinguish the > > > > following two cases: > > > > > > > > Case 1: AP1 and AP2 are classical access points. An attacker > > > compromises > > > > AP1 and AP2 and moves the client's PMK from AP1 and AP2. > > > > > > > > Case 2: AP1 and AP2 are two light-weight access points that are > part > > > of > > > > the same switch S. The switch S uses the same PMK with both AP1 > and > > > AP2. > > > > > > > > If no one can demonstrate a deterministic algorithm the client can > > use > > > > to distinguish the two cases, then a properly implemented client > > will > > > > always assume its PMK has been compromised when it sees either > case. > > I > > > > suspect no one can, because the client lacks the necessary state. > > > > > > > > It appears to me there are three possible solutions: > > > > > > > > a. The first is the necessary state is somehow delivered to the > > client > > > > in an attestable fashion. The only party that client trusts is the > > AAA > > > > server, so this implies a new binding protocol between the AAA > > server > > > > and the EAP Peer. > > > > > > > b. The second is to define a new protocol that delivers the AP's > > > > authenticated identifier to the EAP Peer in an attestable fashion, > > and > > > > to change the 802.11i key confirmation handshake to use this > > > identifier > > > > instead of the BSSID of the APs. > > > > > > > > c. The text that permits this usage should be removed. > > > > > > > > I believe possibilities (a) or (b) are the right way to address > this > > > > issue. > > > > > > > > -- Jesse > > > > > > > > -----Original Message----- > > > > From: Yang, Lily L > > > > Sent: Friday, October 22, 2004 12:03 PM > > > > To: Walker, Jesse; housley@vigilsec.com > > > > Subject: FW: [Capwap] Important: please provide input on comment > > > > resolution for CAPWAP Taxonomy draft > > > > Importance: High > > > > > > > > Jesse and Russ -- > > > > > > > > CAPWAP WG has had some email discussion regarding the comment from > > you > > > > on PMK sharing. I don't think either of you are on the list, so I > am > > > > forwarding to you this and I would like to hear what you think > about > > > > these responses. > > > > > > > > Lily > > > > > > > > -----Original Message----- > > > > From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] > > On > > > > Behalf Of Dan Harkins > > > > Sent: Thursday, October 21, 2004 9:47 AM > > > > To: Chunduru Rama Krishna Prasad > > > > Cc: capwap@frascone.com > > > > Subject: Re: [Capwap] Important: please provide input on comment > > > > resolution for CAPWAP Taxonomy draft > > > > > > > > Strictly speaking the PMK is shared between the supplicant and > the > > > > authentication server, not the authenticator. There are no MAC > > > addresses > > > > bound to the PMK or used in the derivation of the PMK. > > > > > > > > As the person who got PMK caching and PMKIDs into the 802.11i > > draft > > > > let me explain the steps we went through: > > > > > > > > - first motion was to indicate the ability of a STA to do "PMK > > > > caching" > > > > in an associate request. If the authenticator had a cached PMK > > for > > > > the STA it would respond with the 1st message of the 4way > > > handshake, > > > > otherwise it would respond with an 802.1x encapsulated EAP > > > Identity > > > > request. That enabled the functionality you describe below-- > > "the > > > > station is reassociating with an AP to with it already > > established > > > > the PMK before..." It prevented a STA in a difficult RF > > > environment > > > > from ping-ponging back and forth between APs and hammering an > > > > authentication server. > > > > > > > > - it soon became apparent that an authenticator may have > multiple > > > PMKs > > > > for a particular STA in its cache. How? Via something like a > > > > pro-active > > > > key pushing mechanism using neighbor graphs (Bill Arbaugh > > > presented > > > > this idea). So the next motion was to name PMKs with a PMKID > to > > > > indicate which PMK a STA is asserting in its associate > request. > > > > This eliminated the ambiguity. > > > > > > > > So the very reason that we have PMKIDs, and not just blind > > assertions > > > of > > > > a cached PMK, is because the PMK may be used to derive a PTK for > > > > multiple APs. The statement "If PMK is shared across multiple > WTPs" > > > is, > > > > indeed, valid. > > > > > > > > Addressing Russ's comment, the PMK is already leaked because it > is > > > > given to the authenticator by the authentication server. When > > > discussing > > > "the number of other people who know my secret" there are 3 possible > > > > values: 0, 1 and infinity. If 0 other people know your secret > there > > > are > > > > certain cryptographic properties associated with that state. If 1 > > > other > > > > person knows your secret there are other cryptographic properties > > > > associated with that state (message source authentication for > > > instance), > > > > but if more than 1 person knows your secret then it doesn't matter > > if > > > > it's 2 or 22, the cryptographic properties are the same (it is > > > possible > > > > for someone to impersonate you, forge your messages, read your > > > > messages, etc). > > > > > > > > Of course you can say that in the 802.11i case the authenticator > > is > > > > "trusted" and therefore it's OK for the authentication server to > > leak > > > > the secret to the authenticator (and have 3 people know the > secret). > > > > OK, fine. The other AP is also "trusted" to have the PMK so now 4 > > > people > > > > know the secret (or 5 "trusted" people or 10 "trusted" people). > > > Nothing > > > > changed. > > > > > > > > In the case of a switch hosting multiple APs the switch is the > > > > authenticator and the APs are merely tentacles of the same > octopus. > > > The > > > > PMK isn't shared among the APs, it resides on the switch. There is > > > even > > > > one company I know of (I won't name it but it shouldn't be > difficult > > > to > > > > guess) in which the switch plays the role of the authentication > > server > > > > so the PMK is known only by the switch and the STA. This "PMK > > sharing" > > > > situation is even MORE secure than the traditional deployment > where > > a > > > > STA > > > > establishes a PMK with a RADIUS server and that PMK is leaked to > an > > > AP. > > > > > > > > Dan. > > > > > > > > On Thu, 21 Oct 2004 14:56:37 +0530 you wrote > > > > > hi all, > > > > > > > > > > I am not sure, I am right on this. My impression is that, PMK is > > on > > > > per > > > > > Authenticator MAC address. > > > > > If the station is re-associated with new WTP (different MAC > > > address), > > > > then > > > > > it would not even send > > > > > PMKID of old AP. If there is no PMKID found in reassoc event, AC > > > would > > > > > > > > > start with full 802.1x > > > > > authentication. If the station is reassociating with an AP, to > > which > > > > it > > > > > already established PMK before, > > > > > then station sends PMKID and in that case only 4 way key > handshake > > > is > > > > > requried to get the PTK. > > > > > With respect to this, I am not sure whether the statement > > > > > 'If PMK is shared across multiple WTP' is valid. If not, the > whole > > > > > > > statement can be removed > > > > > from the draft > > > > > > > > > > Regards > > > > > Rama Krishna Prasad > > > > > > > > > > > > > > > > > > > > Ch. Rama Krishna Prasad > > > > > Intoto Software(I) Pvt Ltd, > > > > > Uma Plaza, Nagarjuna circle, > > > > > Panjagutta. Hyderabad, AP > > > > > Tel No:s 2335 8927/8928/8434 > > > > > > > > > > _______________________________________________ > > > > > Capwap mailing list > > > > > Capwap@frascone.com > > > > > http://mail.frascone.com/mailman/listinfo/capwap > > > > _______________________________________________ > > > > Capwap mailing list > > > > Capwap@frascone.com > > > > http://mail.frascone.com/mailman/listinfo/capwap > > > > _______________________________________________ > > > > Capwap mailing list > > > > Capwap@frascone.com > > > > http://mail.frascone.com/mailman/listinfo/capwap > > > > > > > > > > _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Tue Oct 26 12:40:11 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21275 for ; Tue, 26 Oct 2004 12:40:10 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 6DDA21FC64; Tue, 26 Oct 2004 12:40:08 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id A9ACE1FC79; Tue, 26 Oct 2004 12:40:04 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 284FA1FC64 for ; Tue, 26 Oct 2004 12:39:47 -0400 (EDT) Received: from hermes.jf.intel.com (fmr05.intel.com [134.134.136.6]) by mail.frascone.com (Postfix) with ESMTP id CD3231FC0F for ; Tue, 26 Oct 2004 12:39:43 -0400 (EDT) Received: from talaria.jf.intel.com (talaria.jf.intel.com [10.7.209.7]) by hermes.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-outer.mc,v 1.15 2004/01/30 18:16:28 root Exp $) with ESMTP id i9QGhbDa029810; Tue, 26 Oct 2004 16:43:37 GMT Received: from orsmsxvs040.jf.intel.com (orsmsxvs040.jf.intel.com [192.168.65.206]) by talaria.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.11 2004/07/29 22:51:53 root Exp $) with SMTP id i9QGVcV7007878; Tue, 26 Oct 2004 16:33:01 GMT Received: from orsmsx332.amr.corp.intel.com ([192.168.65.60]) by orsmsxvs040.jf.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004102609393523786 ; Tue, 26 Oct 2004 09:39:35 -0700 Received: from orsmsx408.amr.corp.intel.com ([192.168.65.52]) by orsmsx332.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 26 Oct 2004 09:39:35 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: FW: [Capwap] Important: please provide input on comment resolution for CAPWAP Taxonomy draft Message-ID: <2AF68A477DD44C4EBCBE338C24E7A9EE02828928@orsmsx408> Thread-Topic: FW: [Capwap] Important: please provide input on comment resolution for CAPWAP Taxonomy draft Thread-Index: AcS7dO0Y4F5/NP8WSVWHDgKA3otxgwABIl5w From: "Yang, Lily L" To: Cc: , "Walker, Jesse" X-OriginalArrivalTime: 26 Oct 2004 16:39:35.0397 (UTC) FILETIME=[60949150:01C4BB7A] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Tue, 26 Oct 2004 09:39:32 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: quoted-printable Didn't work last time. One more try. Sorry if you receive duplicates of this. ________________________________________ From: Yang, Lily L=20 Sent: Tuesday, October 26, 2004 9:01 AM To: Walker, Jesse; 'Dan Harkins'; 'housley@vigilsec.com' Cc: 'capwap@frascone.com' Subject: RE: FW: [Capwap] Important: please provide input on comment resolution for CAPWAP Taxonomy draft=20 I tried to send this out last night but it never made it into the list due to its size... here I truncated all the previous trailing postings and hope it will make it to the list this time. -------------- First of all, let me thank all of you, for the lively discussion we've had on this important issue. It certainly helps me a lot personally to understand the issue better. IMHO, the debate and confusion here highlights one of the challenges that Centralized Architecture brings to the current 802.11 standard: while "WTP+AC"=3D"Logical AP" seems like a logical assertion, it is not always true that such functional split produces no ambiguity with respect to the 802.11 standard.=20 Most of time, when .11 standard talks about an AP, we can take it as a logical AP, not a physical device, and the standard remains valid even if the logical AP functions are implemented across two physical devices. However, when 11i talks about AP as the "authenticator", I take it that it means the AP in the physical sense, that is, a *single physical device*. But when we split 11i functions into WTP and AC, unless one device (that is, either AC or WTP, but not both) consistently plays the role of "authenticator" in all the 11i functions, including 4-way handshake, authenticator state machine, etc, we would be in trouble because we are violating the basic architecture assumption that 11i makes. Therefore it is important to acknowledge the potential security risks associated with 11i functional split.=20 On the other hand, it is not within the scope of CAPWAP taxonomy draft to explicitly identify the potential solutions and where such solutions should come from, etc. It is valuable discussion that we should have sooner or later in some forum (either here or somewhere else), but it is not yet critically important for us to resolve that within this draft. But it *is* critically important for us to resolve how to fix the taxonomy draft so that the additional security concerns due to the functional split are properly documented so that we can close on this draft and move on to the next steps. Therefore, I would encourage that we focus our discussion on how to best describe the additional security challenges for client data protection. Remember that one of the motivations to use Centralized Architecture is to enhance the security, not to lessen it, relatively to the traditional "Autonomous Architecture". The paragraph in question is 4.8.1: "If the PMK (Pairwise Master Key) is reused across multiple WTPs, then requiring a 4-way handshake for each WTP that the station associates to, followed by the transfer of that PTK from the AC to the WTP, would ensure that a different PTK is used at each WTP." The issue at hand is whether or not PMK can be reused across multiple WTPs as defined in 11i today, without introducing additional security risks. I would like to take a step back, and go back to the original categories that Inderpreet provided and refine on it and see if we can agree on the following analysis: Case 1: If AC handles all 11i functions (key mgmt, privacy & integrity encryption, etc.) and functions fully as the "authenticator" without WTP getting invovled, then there is no additional security issue from 11i's point of view. (Note we are talking about client data security here only in 4.8.1, not AC-WTP control message security which is covered in 4.8.2). Case 2: If 11i is split between AC and WTP in the way that AC handles all Authentication and Key Management (for PMK and PTK), but WTP handles privacy and integrity encryption, then it is necessary for WTP to possess PTK (but not PMK), therefore it is necessary to guarantee a secure way to transfer PTK from AC to WTP. Provided that this additional requirement is met, this functional split is still a relatively safe usage model with respect to 11i, because only the AC (acting as the authenticator) possesses PMK, similar to the case in Autonomous Architecture where AP possesses PMK. But I would argue that this split still maintain the security "advantage" argument of Centralized Architecture because AC typically can assume better physical security than AP, and there are typically significantly fewer ACs in Centralized Architecture than the APs. Case 3: If 11i is split between AC and WTP in the way that AC handles .1X/EAP Authentication (as the authenticator, possesses PMK), but WTP handles 4-way handshake and encryption, then it is necessary for WTP (in addition to AC) to possess PMK as well. I would argue that such split would weaken the network security, because now PMK is exposed to WTP, and the physical security of a large number of WTPs is one of the challenges that motivated the Centralized Architecture at the first place. If PMK is shared among multiple WTPs (to support roaming or whatever other functions), it would further weaken the security of the network as explained by Jesse. Therefore, such a functional split seems to present more security challenges than Case 1 and 2. It doesn't mean that it can't be done; it just means that additional work on security might be necessary to ensure that the security of the network is not in any way reduced (similar to the goal in 11r as articulated by Clint).=20 So it seems to me that the security considerations would vary depending on how the 11i functions are split between AC and WTP. The CAPWAP taxonomy draft should highlight the different security considerations without getting into the solution space. Lily _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Tue Oct 26 13:06:10 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23624 for ; Tue, 26 Oct 2004 13:06:08 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 334551FC0F; Tue, 26 Oct 2004 13:06:09 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 414C31FC79; Tue, 26 Oct 2004 13:06:05 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id CF0C21FC79 for ; Tue, 26 Oct 2004 13:05:50 -0400 (EDT) Received: from homebrew.trpz.com (66-7-225-40.cust.telepacific.net [66.7.225.40]) by mail.frascone.com (Postfix) with ESMTP id 7E2DF1FC0F for ; Tue, 26 Oct 2004 13:05:48 -0400 (EDT) Received: from trpz.com (localhost.trpz.com [127.0.0.1]) by homebrew.trpz.com (8.13.1/8.13.1) with ESMTP id i9QH4vJZ083285; Tue, 26 Oct 2004 10:04:57 -0700 (PDT) (envelope-from dharkins@trpz.com) Message-Id: <200410261704.i9QH4vJZ083285@homebrew.trpz.com> To: "Walker, Jesse" Cc: "Yang, Lily L" , capwap@frascone.com, housley@vigilsec.com Subject: Re: FW: [Capwap] Important: please provide input on comment resolution for CAPWAP Taxonomy draft In-Reply-To: Your message of "Tue, 26 Oct 2004 06:46:17 PDT." MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <83283.1098810297.1@trpz.com> From: Dan Harkins X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Tue, 26 Oct 2004 10:04:57 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Jesse, I know you didn't appeal to the 3 party protocol; I did. I was pointing out that it suffers from exactly what you claim "PMK sharing" suffers from. I cannot provide you with a deterministic algorithm to allow a supplicant to know whether or not the PMK was compromised when doing "PMK sharing" but you also cannot provide a deterministic algorithm to allow a supplicant to know whether or not the PMK was compromised in the 3 party protocol (i.e. even without "PMK sharing"). It seems somewhat disingenuous for you to claim that "PMK sharing" is bad and insist on someone providing you with a deterministic algorithm while simultaneously ignoring exactly the same problems with the 3 party protocol (and conveniently not demanding a deterministic algorithm for that). Earlier in this thread you asked how a "properly implemented" supplicant would know, when PMKs are shared, whether AP2 was an attacker that compromised AP1 or not. I said by exactly the same method a "properly implemented" supplicant knows that the PMK asserted by the AP in the 3 party protocol was compromised or not. You seem to think there is a reason for the supplicant to believe in the 3 party protocol. OK, great! Then by that same reasoning it should believe in the integrity of a PMK that is shared. Let me close this increasingly tedious thread by noting: - "PMK sharing" is, indeed, allowed in the 11i draft as Jesse alluded to earlier when he mentioned, as option (c), that the text could be removed. - "PMK sharing" is not free of security considerations, but then 11i is based on a protocol which, itself, is not free of security considerations and suffers from exactly the same issues that "PMK sharing" does. - The upside of "PMK sharing" is that a AAA server will not be hammered by supplicants in problematic RF environments, and handoffs can happen in sub 50ms. The downside is that there are security considerations to it, but then if those security considerations were enough to make you not support "PMK sharing" then you should not support 11i. Dan. On Tue, 26 Oct 2004 06:46:17 PDT you wrote > Dan, > > Please reread my last message. Nowhere did I appeal to the use of a > 3-party protocol. The argument was based solely on the configuration of > state, regardless of how it was delivered. The problem is the quite > reasonable usage CAPWAP wants to make never took into account that the > infrastructure has to recognize and accommodate the EAP Peer's security > policy as well as vice versa. There are at least two ways CAPWAP could > accommodate the EAP Peer's security policy. One way is to not share > keys. A second way is to rely on a key binding protocol. Either approach > can be made to work. > > You are right in one way; the discussion isn't just about CAPWAP; there > is a problem with the basic EAP keying model, and that, not CAPWAP, is > the prey in this hunt. The problem with the EAP keying model is that it > never establishes a contract governing the behavior of the EAP Peer's > and NAS's use of what it calls the MSK. > > -- Jesse > > -----Original Message----- > From: Dan Harkins [mailto:dharkins@trpz.com] > Sent: Monday, October 25, 2004 4:54 PM > To: Walker, Jesse > Cc: Yang, Lily L; capwap@frascone.com; housley@vigilsec.com > Subject: Re: FW: [Capwap] Important: please provide input on comment > resolution for CAPWAP Taxonomy draft > > Jesse, > > That same argument can be made against the existing 3 party exchange > between the supplicant, authentication server, and authenticator. > In fact, the existing 3 party exchange could be viewed as the degenerate > case of "PMK sharing". > > When the AP asserts possession of the PMK the supplicant has no > way of knowing whether that AP is a valid, trusted AP or is an attacker > that has compromised another AP (or the AP <--> AS connection) and > is playing man-in-the-middle. > > The reason this is so is because the supplicant never told the > authentication server to share the PMK with an entity identified by > a particular BSSID (and the authentication server does not maintain > a relationship with an entity identified by BSSID anyway), nor did > the AP provide some "ticket" to the supplicant proving that it is > trusted by the authentication server to know this secret. Either of > which would've made this exchange more secure. > > Can you show me some deterministic way for a supplicant to distinguish > between these two: > > 1. the AAA client (entity trusted by the AS) and radio (that > entity identified by a BSSID that the client is speaking to) are > different parts of the same device and within the same security > boundary. > > 2. the AAA client is on an AP that has been compromised by an > attacker and the radio with which the supplicant is communicating > is on the attacker. The attacker relays the EAP exchange through > the compromised AP and obtains the PMK. > > If not then I maintain that there is no less security by doing "PMK > sharing". You're including two things in a cryptographic boundary-- > the AAA client and radio-- that are not cryptographically bound > and are asking the supplicant to make a leap of faith. I can just > as easily draw a different cryptographic boundary and ask the > supplicant to make an _identical_ leap of faith. You can't have it > both ways, if it's OK for the existing 3 party exchange then it's > OK for "PMK sharing". > > Dan. > > On Mon, 25 Oct 2004 15:44:13 PDT you wrote > > Dan, > > > > Let me go through this yet again. > > > > In the 802.11i we discussion we said over and over and over and over > > again that the PMK must be kept within a single crypto boundary or it > is > > compromised. > > > > Now, if you have two classical APs, they represent separate crypto > > boundaries, because if you share a PMK between them and you compromise > > one AP, then the client's traffic is compromised at the other, while > if > > you don't share PMKs between them then compromise of one does not lead > > to compromise of the client's traffic at the other. > > > > It follows from the crypto boundaries argument, that different > classical > > APs must be provisioned with independent PMKs. When this is not done, > > the client must treat its own PMK shared across different classical > APs > > as a violation of its (the client's) security policy, because PMK > > sharing explicitly violates the crypto boundaries principle. > > > > Under 802.11, 802.11i, 802.1X, and EAP the client does not learn > whether > > an AP is a classical AP or a new switched AP such as what would be > > described by CAPWAP. The only thing 802.11 and 802.11i and 802.1X and > > EAP provide the client to distinguish one AP from another is the AP's > > BSSID. This means every AP looks like a classical AP to a client using > > the existing standardized 802.1, 802.11i, 802.1X, and EAP. > > > > Since the client cannot tell a classical AP from a switched AP, it > > follows that a switched AP cannot share PMKs among its different > > light-weight APs, because doing so violates the client's security > > policy. That is, unless and until it receives evidence to the > contrary, > > the client must assume that it is communicating with a classical AP, > and > > PMK reuse between two classical APs violates its policy by violating > the > > crypto boundary principle. The reason why it must assume this is that > it > > does not and cannot know the contrary, and security says the client > must > > make the most conservative assumption consistent with the facts known > to > > it (performance, manageability, etc., might argue something else, but > we > > are discussing security here). > > > > I don't know what is not clear about this. > > > > -- Jesse > > > > -----Original Message----- > > From: Dan Harkins [mailto:dharkins@trpz.com] > > Sent: Monday, October 25, 2004 3:05 PM > > To: Walker, Jesse > > Cc: Yang, Lily L; capwap@frascone.com; housley@vigilsec.com > > Subject: Re: FW: [Capwap] Important: please provide input on comment > > resolution for CAPWAP Taxonomy draft > > > > Jesse, > > > > You are not addressing any of the issues I raised in response to > > your previous demand for a deterministic algorithm, you're just > > repeating yourself. I was trying to point out how the security of > > the system is not lessened by the lack of such an algorithm. I > > asked you to show me where in that email I was wrong and how I > > was wrong. I even added some more analysis of what I think is the > > crux of the matter. You ignored it all. > > > > Sigh, > > > > Dan. > > > > On Mon, 25 Oct 2004 14:28:16 PDT you wrote > > > Dan, > > > > > > I have already explained this, but will do so again out of common > > > courtesy. Please provide a deterministic algorithm by which a client > > > determines whether PMK sharing between AP1 and AP2 is acceptable or > > > represents a compromise, using information available to it under > > > 802.11i. If you produce such an algorithm, then I withdraw my claim > > and > > > apologize. If you cannot, then my assertion stands. > > > > > > -- Jesse > > > > > > -----Original Message----- > > > From: Dan Harkins [mailto:dharkins@trpz.com] > > > Sent: Monday, October 25, 2004 1:56 PM > > > To: Walker, Jesse > > > Cc: Yang, Lily L; capwap@frascone.com; housley@vigilsec.com > > > Subject: Re: FW: [Capwap] Important: please provide input on comment > > > resolution for CAPWAP Taxonomy draft > > > > > > Jesse, > > > > > > Common courtesy dictates that one should not merely state "you are > > > wrong" but to explain exactly where one is wrong. > > > > > > Abstract language is getting in the way of my point so let me > > > just use common vernacular that is descriptive of what is deployed > > > today: > > > > > > If I can try to boil this down I think the residue we will be left > > > with is that you believe that there is a one-to-one relationship > > > between a RADIUS client and a BSSID that a supplicant speaks to and > > > that the identity of the RADIUS client and BSSID are interchangable. > > > It is that belief, I believe, that causes you to infer a binding of > > > PMK to BSSID when, strictly speaking, none exists. > > > > > > The RADIUS server has a trust relationship with a RADIUS client. > > > That RADIUS client is identified, to the RADIUS server, with an IP > > > address. You are assuming that that RADIUS client, identified by > > > its IP address, has one and only one BSSID. This is incorrect. > > > Furthermore you are assuming that this 3 way protocol between the > > > supplicant, the RADIUS server, and the RADIUS client is 1) secure; > > > and 2) extensible to a different identity of the RADIUS client, a > > > BSSID, without loss of security. > > > > > > Feel free to tell me I'm wrong again, but please tell me where > > > and how. > > > > > > Dan. > > > > > > On Mon, 25 Oct 2004 13:03:24 PDT you wrote > > > > Dan, > > > > > > > > You are wrong. The problem is there is no Needham-Shroeder-eseque > > > > protocol in the back end. > > > > > > > > -- Jesse > > > > > > > > -----Original Message----- > > > > From: Dan Harkins [mailto:dharkins@trpz.com] > > > > Sent: Monday, October 25, 2004 12:58 PM > > > > To: Yang, Lily L > > > > Cc: capwap@frascone.com; Walker, Jesse; housley@vigilsec.com > > > > Subject: Re: FW: [Capwap] Important: please provide input on > comment > > > > resolution for CAPWAP Taxonomy draft > > > > > > > > I beg to differ. > > > > > > > > If this was a Needham-Schroeder-esqe protocol Jesse might have a > > > > point. But it's not. > > > > > > > > There is no way for a "properly implemented" client to know that > > the > > > > AP it is speaking to is trusted by the authentication server since > > > > nothing in the exchange that derives the PMK includes anything > about > > > > the AP. It's merely a man-in-the-middle. The AP proves knowledge > of > > > the > > > > PMK so the client is just supposed to assume it's trusted! What is > > > being > > > > asked here is just ignore that > unpleasant > > > > security issue and believe we have > a > > > > secure > > > > 3-party authenticaiton system here so that we can then condemn a > > > scheme > > > > that suffers from that same unpleasant security issue. > > > > > > > > How does a "properly implemented" client know that AP2 is not a > > > > attacker which compromised AP1? By the same technique that it used > > > > to know that AP1 was not an attacker which compromised the authen- > > > > tication server (or the link between the authentication server and > a > > > > legitimate authenticator). Since a "properly implemented" client > can > > > > do the latter it can take the same steps to do the former. > > > > > > > > If mere proof of possession of the PMK is enough to legitimize > AP1 > > > > to the client then mere proof of possession of the PMK is enough > to > > > > legitimize AP2 to the client. You cannot reasonably claim > otherwise. > > > > > > > > This is not to say that Jesse's suggestions of (a) or (b) below > > > > are not needed, I would welcome either of those. I would also like > > > > to note that Jesse's mention of (c) is an explicit acknowledgment > > > > that "PMK sharing" is permitted by the existing specification. > > > > > > > > Dan. > > > > > > > > On Mon, 25 Oct 2004 09:33:05 PDT you wrote > > > > > I solicited input from Jesse Walker and Russ Housley on the > issue > > of > > > > PMK > > > > > sharing, and here is the response from Jesse. He agrees to let > me > > > > > forward this to the CAPWAP list. I also cc Jesse and Russ here. > > > Since > > > > > Russ posted the original comment in IESG review, and Jesse is > the > > > > > technical editor of 11i, I think it would be good that we keep > > them > > > in > > > > > the loop with regard this discussion. So please cc them in your > > > email > > > > > posting on this issue as they are not in the CAPWAP list. > > > > > > > > > > -----Original Message----- > > > > > From: Walker, Jesse > > > > > Sent: Saturday, October 23, 2004 7:05 PM > > > > > To: Yang, Lily L; 'housley@vigilsec.com' > > > > > Subject: RE: [Capwap] Important: please provide input on comment > > > > > resolution for CAPWAP Taxonomy draft > > > > > > > > > > Lily, > > > > > > > > > > Dan's reasoning is invalid, unless he or someone else can > produce > > a > > > > > deterministic algorithm that allows the client to distinguish > the > > > > > following two cases: > > > > > > > > > > Case 1: AP1 and AP2 are classical access points. An attacker > > > > compromises > > > > > AP1 and AP2 and moves the client's PMK from AP1 and AP2. > > > > > > > > > > Case 2: AP1 and AP2 are two light-weight access points that are > > part > > > > of > > > > > the same switch S. The switch S uses the same PMK with both AP1 > > and > > > > AP2. > > > > > > > > > > If no one can demonstrate a deterministic algorithm the client > can > > > use > > > > > to distinguish the two cases, then a properly implemented client > > > will > > > > > always assume its PMK has been compromised when it sees either > > case. > > > I > > > > > suspect no one can, because the client lacks the necessary > state. > > > > > > > > > > It appears to me there are three possible solutions: > > > > > > > > > > a. The first is the necessary state is somehow delivered to the > > > client > > > > > in an attestable fashion. The only party that client trusts is > the > > > AAA > > > > > server, so this implies a new binding protocol between the AAA > > > server > > > > > and the EAP Peer. > > > > > > > > > b. The second is to define a new protocol that delivers the AP's > > > > > authenticated identifier to the EAP Peer in an attestable > fashion, > > > and > > > > > to change the 802.11i key confirmation handshake to use this > > > > identifier > > > > > instead of the BSSID of the APs. > > > > > > > > > > c. The text that permits this usage should be removed. > > > > > > > > > > I believe possibilities (a) or (b) are the right way to address > > this > > > > > issue. > > > > > > > > > > -- Jesse > > > > > > > > > > -----Original Message----- > > > > > From: Yang, Lily L > > > > > Sent: Friday, October 22, 2004 12:03 PM > > > > > To: Walker, Jesse; housley@vigilsec.com > > > > > Subject: FW: [Capwap] Important: please provide input on comment > > > > > resolution for CAPWAP Taxonomy draft > > > > > Importance: High > > > > > > > > > > Jesse and Russ -- > > > > > > > > > > CAPWAP WG has had some email discussion regarding the comment > from > > > you > > > > > on PMK sharing. I don't think either of you are on the list, so > I > > am > > > > > forwarding to you this and I would like to hear what you think > > about > > > > > these responses. > > > > > > > > > > Lily > > > > > > > > > > -----Original Message----- > > > > > From: capwap-admin@frascone.com > [mailto:capwap-admin@frascone.com] > > > On > > > > > Behalf Of Dan Harkins > > > > > Sent: Thursday, October 21, 2004 9:47 AM > > > > > To: Chunduru Rama Krishna Prasad > > > > > Cc: capwap@frascone.com > > > > > Subject: Re: [Capwap] Important: please provide input on comment > > > > > resolution for CAPWAP Taxonomy draft > > > > > > > > > > Strictly speaking the PMK is shared between the supplicant and > > the > > > > > authentication server, not the authenticator. There are no MAC > > > > addresses > > > > > bound to the PMK or used in the derivation of the PMK. > > > > > > > > > > As the person who got PMK caching and PMKIDs into the 802.11i > > > draft > > > > > let me explain the steps we went through: > > > > > > > > > > - first motion was to indicate the ability of a STA to do "PMK > > > > > caching" > > > > > in an associate request. If the authenticator had a cached > PMK > > > for > > > > > the STA it would respond with the 1st message of the 4way > > > > handshake, > > > > > otherwise it would respond with an 802.1x encapsulated EAP > > > > Identity > > > > > request. That enabled the functionality you describe below-- > > > "the > > > > > station is reassociating with an AP to with it already > > > established > > > > > the PMK before..." It prevented a STA in a difficult RF > > > > environment > > > > > from ping-ponging back and forth between APs and hammering > an > > > > > authentication server. > > > > > > > > > > - it soon became apparent that an authenticator may have > > multiple > > > > PMKs > > > > > for a particular STA in its cache. How? Via something like a > > > > > pro-active > > > > > key pushing mechanism using neighbor graphs (Bill Arbaugh > > > > presented > > > > > this idea). So the next motion was to name PMKs with a PMKID > > to > > > > > indicate which PMK a STA is asserting in its associate > > request. > > > > > This eliminated the ambiguity. > > > > > > > > > > So the very reason that we have PMKIDs, and not just blind > > > assertions > > > > of > > > > > a cached PMK, is because the PMK may be used to derive a PTK for > > > > > > multiple APs. The statement "If PMK is shared across multiple > > WTPs" > > > > is, > > > > > indeed, valid. > > > > > > > > > > Addressing Russ's comment, the PMK is already leaked because > it > > is > > > > > given to the authenticator by the authentication server. When > > > > discussing > > > > "the number of other people who know my secret" there are 3 > possible > > > > > values: 0, 1 and infinity. If 0 other people know your secret > > there > > > > are > > > > > certain cryptographic properties associated with that state. If > 1 > > > > other > > > > > person knows your secret there are other cryptographic > properties > > > > > associated with that state (message source authentication for > > > > instance), > > > > > but if more than 1 person knows your secret then it doesn't > matter > > > if > > > > > it's 2 or 22, the cryptographic properties are the same (it is > > > > possible > > > > > for someone to impersonate you, forge your messages, read your > > > > > messages, etc). > > > > > > > > > > Of course you can say that in the 802.11i case the > authenticator > > > is > > > > > "trusted" and therefore it's OK for the authentication server to > > > leak > > > > > the secret to the authenticator (and have 3 people know the > > secret). > > > > > OK, fine. The other AP is also "trusted" to have the PMK so now > 4 > > > > people > > > > > know the secret (or 5 "trusted" people or 10 "trusted" people). > > > > Nothing > > > > > changed. > > > > > > > > > > In the case of a switch hosting multiple APs the switch is the > > > > > authenticator and the APs are merely tentacles of the same > > octopus. > > > > The > > > > > PMK isn't shared among the APs, it resides on the switch. There > is > > > > even > > > > > one company I know of (I won't name it but it shouldn't be > > difficult > > > to > > > > > guess) in which the switch plays the role of the authentication > > > server > > > > > so the PMK is known only by the switch and the STA. This "PMK > > > sharing" > > > > > situation is even MORE secure than the traditional deployment > > where > > > a > > > > > STA > > > > > establishes a PMK with a RADIUS server and that PMK is leaked to > > an > > > > AP. > > > > > > > > > > Dan. > > > > > > > > > > On Thu, 21 Oct 2004 14:56:37 +0530 you wrote > > > > > > hi all, > > > > > > > > > > > > I am not sure, I am right on this. My impression is that, PMK > is > > > on > > > > > per > > > > > > Authenticator MAC address. > > > > > > If the station is re-associated with new WTP (different MAC > > > > address), > > > > > then > > > > > > it would not even send > > > > > > PMKID of old AP. If there is no PMKID found in reassoc event, > AC > > > > would > > > > > > > > > > > start with full 802.1x > > > > > > authentication. If the station is reassociating with an AP, to > > > which > > > > > it > > > > > > already established PMK before, > > > > > > then station sends PMKID and in that case only 4 way key > > handshake > > > > is > > > > > > requried to get the PTK. > > > > > > With respect to this, I am not sure whether the statement > > > > > > 'If PMK is shared across multiple WTP' is valid. If not, the > > whole > > > > > > > > > statement can be removed > > > > > > from the draft > > > > > > > > > > > > Regards > > > > > > Rama Krishna Prasad > > > > > > > > > > > > > > > > > > > > > > > > Ch. Rama Krishna Prasad > > > > > > Intoto Software(I) Pvt Ltd, > > > > > > Uma Plaza, Nagarjuna circle, > > > > > > Panjagutta. Hyderabad, AP > > > > > > Tel No:s 2335 8927/8928/8434 > > > > > > > > > > > > _______________________________________________ > > > > > > Capwap mailing list > > > > > > Capwap@frascone.com > > > > > > http://mail.frascone.com/mailman/listinfo/capwap > > > > > _______________________________________________ > > > > > Capwap mailing list > > > > > Capwap@frascone.com > > > > > http://mail.frascone.com/mailman/listinfo/capwap > > > > > _______________________________________________ > > > > > Capwap mailing list > > > > > Capwap@frascone.com > > > > > http://mail.frascone.com/mailman/listinfo/capwap > > > > > > > > > > > > > > > _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Tue Oct 26 16:39:12 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15529 for ; Tue, 26 Oct 2004 16:39:09 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id F368F1FC0F; Tue, 26 Oct 2004 16:39:08 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id B4D281FCC0; Tue, 26 Oct 2004 16:39:04 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id E579F1FC79 for ; Tue, 26 Oct 2004 09:46:25 -0400 (EDT) Received: from orsfmr001.jf.intel.com (fmr12.intel.com [134.134.136.15]) by mail.frascone.com (Postfix) with ESMTP id 929BD1FC64 for ; Tue, 26 Oct 2004 09:46:23 -0400 (EDT) Received: from talaria.jf.intel.com (talaria.jf.intel.com [10.7.209.7]) by orsfmr001.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-outer.mc,v 1.15 2004/01/30 18:16:28 root Exp $) with ESMTP id i9QDl17Z023159; Tue, 26 Oct 2004 13:47:02 GMT Received: from orsmsxvs041.jf.intel.com (orsmsxvs041.jf.intel.com [192.168.65.54]) by talaria.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.11 2004/07/29 22:51:53 root Exp $) with SMTP id i9QDdTUT012031; Tue, 26 Oct 2004 13:39:42 GMT Received: from orsmsx332.amr.corp.intel.com ([192.168.65.60]) by orsmsxvs041.jf.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004102606461803320 ; Tue, 26 Oct 2004 06:46:18 -0700 Received: from orsmsx401.amr.corp.intel.com ([192.168.65.207]) by orsmsx332.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 26 Oct 2004 06:46:18 -0700 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: FW: [Capwap] Important: please provide input on comment resolution for CAPWAP Taxonomy draft Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Message-ID: Thread-Topic: FW: [Capwap] Important: please provide input on comment resolution for CAPWAP Taxonomy draft Thread-Index: AcS67id+TVOd/36BQlim8exLfAO5cwAcEmXg From: "Walker, Jesse" To: "Dan Harkins" Cc: "Yang, Lily L" , , X-OriginalArrivalTime: 26 Oct 2004 13:46:18.0544 (UTC) FILETIME=[2B92B300:01C4BB62] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Tue, 26 Oct 2004 06:46:17 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: quoted-printable Dan, Please reread my last message. Nowhere did I appeal to the use of a 3-party protocol. The argument was based solely on the configuration of state, regardless of how it was delivered. The problem is the quite reasonable usage CAPWAP wants to make never took into account that the infrastructure has to recognize and accommodate the EAP Peer's security policy as well as vice versa. There are at least two ways CAPWAP could accommodate the EAP Peer's security policy. One way is to not share keys. A second way is to rely on a key binding protocol. Either approach can be made to work. You are right in one way; the discussion isn't just about CAPWAP; there is a problem with the basic EAP keying model, and that, not CAPWAP, is the prey in this hunt. The problem with the EAP keying model is that it never establishes a contract governing the behavior of the EAP Peer's and NAS's use of what it calls the MSK. -- Jesse -----Original Message----- From: Dan Harkins [mailto:dharkins@trpz.com]=20 Sent: Monday, October 25, 2004 4:54 PM To: Walker, Jesse Cc: Yang, Lily L; capwap@frascone.com; housley@vigilsec.com Subject: Re: FW: [Capwap] Important: please provide input on comment resolution for CAPWAP Taxonomy draft=20 Jesse, That same argument can be made against the existing 3 party exchange between the supplicant, authentication server, and authenticator. In fact, the existing 3 party exchange could be viewed as the degenerate case of "PMK sharing". When the AP asserts possession of the PMK the supplicant has no way of knowing whether that AP is a valid, trusted AP or is an attacker that has compromised another AP (or the AP <--> AS connection) and is playing man-in-the-middle. The reason this is so is because the supplicant never told the authentication server to share the PMK with an entity identified by a particular BSSID (and the authentication server does not maintain a relationship with an entity identified by BSSID anyway), nor did the AP provide some "ticket" to the supplicant proving that it is trusted by the authentication server to know this secret. Either of which would've made this exchange more secure. Can you show me some deterministic way for a supplicant to distinguish between these two: 1. the AAA client (entity trusted by the AS) and radio (that entity identified by a BSSID that the client is speaking to) are different parts of the same device and within the same security boundary. 2. the AAA client is on an AP that has been compromised by an attacker and the radio with which the supplicant is communicating is on the attacker. The attacker relays the EAP exchange through the compromised AP and obtains the PMK. If not then I maintain that there is no less security by doing "PMK sharing". You're including two things in a cryptographic boundary-- the AAA client and radio-- that are not cryptographically bound and are asking the supplicant to make a leap of faith. I can just as easily draw a different cryptographic boundary and ask the supplicant to make an _identical_ leap of faith. You can't have it both ways, if it's OK for the existing 3 party exchange then it's OK for "PMK sharing".=20 Dan. On Mon, 25 Oct 2004 15:44:13 PDT you wrote > Dan, >=20 > Let me go through this yet again. >=20 > In the 802.11i we discussion we said over and over and over and over > again that the PMK must be kept within a single crypto boundary or it is > compromised. >=20 > Now, if you have two classical APs, they represent separate crypto > boundaries, because if you share a PMK between them and you compromise > one AP, then the client's traffic is compromised at the other, while if > you don't share PMKs between them then compromise of one does not lead > to compromise of the client's traffic at the other. >=20 > It follows from the crypto boundaries argument, that different classical > APs must be provisioned with independent PMKs. When this is not done, > the client must treat its own PMK shared across different classical APs > as a violation of its (the client's) security policy, because PMK > sharing explicitly violates the crypto boundaries principle. >=20 > Under 802.11, 802.11i, 802.1X, and EAP the client does not learn whether > an AP is a classical AP or a new switched AP such as what would be > described by CAPWAP. The only thing 802.11 and 802.11i and 802.1X and > EAP provide the client to distinguish one AP from another is the AP's > BSSID. This means every AP looks like a classical AP to a client using > the existing standardized 802.1, 802.11i, 802.1X, and EAP. >=20 > Since the client cannot tell a classical AP from a switched AP, it > follows that a switched AP cannot share PMKs among its different > light-weight APs, because doing so violates the client's security > policy. That is, unless and until it receives evidence to the contrary, > the client must assume that it is communicating with a classical AP, and > PMK reuse between two classical APs violates its policy by violating the > crypto boundary principle. The reason why it must assume this is that it > does not and cannot know the contrary, and security says the client must > make the most conservative assumption consistent with the facts known to > it (performance, manageability, etc., might argue something else, but we > are discussing security here). >=20 > I don't know what is not clear about this. >=20 > -- Jesse=20 >=20 > -----Original Message----- > From: Dan Harkins [mailto:dharkins@trpz.com]=20 > Sent: Monday, October 25, 2004 3:05 PM > To: Walker, Jesse > Cc: Yang, Lily L; capwap@frascone.com; housley@vigilsec.com > Subject: Re: FW: [Capwap] Important: please provide input on comment > resolution for CAPWAP Taxonomy draft=20 >=20 > Jesse, >=20 > You are not addressing any of the issues I raised in response to > your previous demand for a deterministic algorithm, you're just > repeating yourself. I was trying to point out how the security of > the system is not lessened by the lack of such an algorithm. I > asked you to show me where in that email I was wrong and how I > was wrong. I even added some more analysis of what I think is the > crux of the matter. You ignored it all.=20 >=20 > Sigh, >=20 > Dan. >=20 > On Mon, 25 Oct 2004 14:28:16 PDT you wrote > > Dan, > >=20 > > I have already explained this, but will do so again out of common > > courtesy. Please provide a deterministic algorithm by which a client > > determines whether PMK sharing between AP1 and AP2 is acceptable or > > represents a compromise, using information available to it under > > 802.11i. If you produce such an algorithm, then I withdraw my claim > and > > apologize. If you cannot, then my assertion stands. > >=20 > > -- Jesse > >=20 > > -----Original Message----- > > From: Dan Harkins [mailto:dharkins@trpz.com]=20 > > Sent: Monday, October 25, 2004 1:56 PM > > To: Walker, Jesse > > Cc: Yang, Lily L; capwap@frascone.com; housley@vigilsec.com > > Subject: Re: FW: [Capwap] Important: please provide input on comment > > resolution for CAPWAP Taxonomy draft=20 > >=20 > > Jesse, > >=20 > > Common courtesy dictates that one should not merely state "you are > > wrong" but to explain exactly where one is wrong. > >=20 > > Abstract language is getting in the way of my point so let me > > just use common vernacular that is descriptive of what is deployed > > today: > >=20 > > If I can try to boil this down I think the residue we will be left > > with is that you believe that there is a one-to-one relationship > > between a RADIUS client and a BSSID that a supplicant speaks to and > > that the identity of the RADIUS client and BSSID are interchangable. > > It is that belief, I believe, that causes you to infer a binding of > > PMK to BSSID when, strictly speaking, none exists. > >=20 > > The RADIUS server has a trust relationship with a RADIUS client. > > That RADIUS client is identified, to the RADIUS server, with an IP > > address. You are assuming that that RADIUS client, identified by > > its IP address, has one and only one BSSID. This is incorrect. > > Furthermore you are assuming that this 3 way protocol between the > > supplicant, the RADIUS server, and the RADIUS client is 1) secure; > > and 2) extensible to a different identity of the RADIUS client, a > > BSSID, without loss of security. > >=20 > > Feel free to tell me I'm wrong again, but please tell me where > > and how. > >=20 > > Dan. > >=20 > > On Mon, 25 Oct 2004 13:03:24 PDT you wrote > > > Dan, > > >=20 > > > You are wrong. The problem is there is no Needham-Shroeder-eseque > > > protocol in the back end. > > >=20 > > > -- Jesse > > >=20 > > > -----Original Message----- > > > From: Dan Harkins [mailto:dharkins@trpz.com]=20 > > > Sent: Monday, October 25, 2004 12:58 PM > > > To: Yang, Lily L > > > Cc: capwap@frascone.com; Walker, Jesse; housley@vigilsec.com > > > Subject: Re: FW: [Capwap] Important: please provide input on comment > > > resolution for CAPWAP Taxonomy draft=20 > > >=20 > > > I beg to differ. > > >=20 > > > If this was a Needham-Schroeder-esqe protocol Jesse might have a > > > point. But it's not. > > >=20 > > > There is no way for a "properly implemented" client to know that > the > > > AP it is speaking to is trusted by the authentication server since > > > nothing in the exchange that derives the PMK includes anything about > > > the AP. It's merely a man-in-the-middle. The AP proves knowledge of > > the > > > PMK so the client is just supposed to assume it's trusted! What is > > being > > > asked here is just ignore that unpleasant > > > security issue and believe we have a > > > secure > > > 3-party authenticaiton system here so that we can then condemn a > > scheme > > > that suffers from that same unpleasant security issue. > > >=20 > > > How does a "properly implemented" client know that AP2 is not a > > > attacker which compromised AP1? By the same technique that it used > > > to know that AP1 was not an attacker which compromised the authen- > > > tication server (or the link between the authentication server and a > > > legitimate authenticator). Since a "properly implemented" client can > > > do the latter it can take the same steps to do the former. > > >=20 > > > If mere proof of possession of the PMK is enough to legitimize AP1 > > > to the client then mere proof of possession of the PMK is enough to > > > legitimize AP2 to the client. You cannot reasonably claim otherwise. > > >=20 > > > This is not to say that Jesse's suggestions of (a) or (b) below > > > are not needed, I would welcome either of those. I would also like > > > to note that Jesse's mention of (c) is an explicit acknowledgment > > > that "PMK sharing" is permitted by the existing specification. > > >=20 > > > Dan. > > >=20 > > > On Mon, 25 Oct 2004 09:33:05 PDT you wrote > > > > I solicited input from Jesse Walker and Russ Housley on the issue > of > > > PMK > > > > sharing, and here is the response from Jesse. He agrees to let me > > > > forward this to the CAPWAP list. I also cc Jesse and Russ here. > > Since > > > > Russ posted the original comment in IESG review, and Jesse is the > > > > technical editor of 11i, I think it would be good that we keep > them > > in > > > > the loop with regard this discussion. So please cc them in your > > email > > > > posting on this issue as they are not in the CAPWAP list. > > > >=20 > > > > -----Original Message----- > > > > From: Walker, Jesse=20 > > > > Sent: Saturday, October 23, 2004 7:05 PM > > > > To: Yang, Lily L; 'housley@vigilsec.com' > > > > Subject: RE: [Capwap] Important: please provide input on comment > > > > resolution for CAPWAP Taxonomy draft=20 > > > >=20 > > > > Lily, > > > >=20 > > > > Dan's reasoning is invalid, unless he or someone else can produce > a > > > > deterministic algorithm that allows the client to distinguish the > > > > following two cases: > > > >=20 > > > > Case 1: AP1 and AP2 are classical access points. An attacker > > > compromises > > > > AP1 and AP2 and moves the client's PMK from AP1 and AP2. > > > >=20 > > > > Case 2: AP1 and AP2 are two light-weight access points that are > part > > > of > > > > the same switch S. The switch S uses the same PMK with both AP1 > and > > > AP2. > > > >=20 > > > > If no one can demonstrate a deterministic algorithm the client can > > use > > > > to distinguish the two cases, then a properly implemented client > > will > > > > always assume its PMK has been compromised when it sees either > case. > > I > > > > suspect no one can, because the client lacks the necessary state. > > > >=20 > > > > It appears to me there are three possible solutions: > > > >=20 > > > > a. The first is the necessary state is somehow delivered to the > > client > > > > in an attestable fashion. The only party that client trusts is the > > AAA > > > > server, so this implies a new binding protocol between the AAA > > server > > > > and the EAP Peer. > > >=20 > > > > b. The second is to define a new protocol that delivers the AP's > > > > authenticated identifier to the EAP Peer in an attestable fashion, > > and > > > > to change the 802.11i key confirmation handshake to use this > > > identifier > > > > instead of the BSSID of the APs. > > > >=20 > > > > c. The text that permits this usage should be removed. > > > >=20 > > > > I believe possibilities (a) or (b) are the right way to address > this > > > > issue. > > > >=20 > > > > -- Jesse > > > >=20 > > > > -----Original Message----- > > > > From: Yang, Lily L=20 > > > > Sent: Friday, October 22, 2004 12:03 PM > > > > To: Walker, Jesse; housley@vigilsec.com > > > > Subject: FW: [Capwap] Important: please provide input on comment > > > > resolution for CAPWAP Taxonomy draft=20 > > > > Importance: High > > > >=20 > > > > Jesse and Russ -- > > > >=20 > > > > CAPWAP WG has had some email discussion regarding the comment from > > you > > > > on PMK sharing. I don't think either of you are on the list, so I > am > > > > forwarding to you this and I would like to hear what you think > about > > > > these responses.=20 > > > >=20 > > > > Lily > > > >=20 > > > > -----Original Message----- > > > > From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] > > On > > > > Behalf Of Dan Harkins > > > > Sent: Thursday, October 21, 2004 9:47 AM > > > > To: Chunduru Rama Krishna Prasad > > > > Cc: capwap@frascone.com > > > > Subject: Re: [Capwap] Important: please provide input on comment > > > > resolution for CAPWAP Taxonomy draft=20 > > > >=20 > > > > Strictly speaking the PMK is shared between the supplicant and > the > > > > authentication server, not the authenticator. There are no MAC > > > addresses > > > > bound to the PMK or used in the derivation of the PMK. > > > >=20 > > > > As the person who got PMK caching and PMKIDs into the 802.11i > > draft > > > > let me explain the steps we went through: > > > >=20 > > > > - first motion was to indicate the ability of a STA to do "PMK > > > > caching" > > > > in an associate request. If the authenticator had a cached PMK > > for > > > > the STA it would respond with the 1st message of the 4way > > > handshake, > > > > otherwise it would respond with an 802.1x encapsulated EAP > > > Identity > > > > request. That enabled the functionality you describe below-- > > "the > > > > station is reassociating with an AP to with it already > > established > > > > the PMK before..." It prevented a STA in a difficult RF > > > environment > > > > from ping-ponging back and forth between APs and hammering an=20 > > > > authentication server. > > > >=20 > > > > - it soon became apparent that an authenticator may have > multiple > > > PMKs > > > > for a particular STA in its cache. How? Via something like a > > > > pro-active > > > > key pushing mechanism using neighbor graphs (Bill Arbaugh > > > presented > > > > this idea). So the next motion was to name PMKs with a PMKID > to > > > > indicate which PMK a STA is asserting in its associate > request. > > > > This eliminated the ambiguity. > > > >=20 > > > > So the very reason that we have PMKIDs, and not just blind > > assertions > > > of > > > > a cached PMK, is because the PMK may be used to derive a PTK for > > > > multiple APs. The statement "If PMK is shared across multiple > WTPs" > > > is, > > > > indeed, valid. > > > >=20 > > > > Addressing Russ's comment, the PMK is already leaked because it > is > > > > given to the authenticator by the authentication server. When > > > discussing > > > "the number of other people who know my secret" there are 3 possible > > > > values: 0, 1 and infinity. If 0 other people know your secret > there > > > are > > > > certain cryptographic properties associated with that state. If 1 > > > other > > > > person knows your secret there are other cryptographic properties > > > > associated with that state (message source authentication for > > > instance), > > > > but if more than 1 person knows your secret then it doesn't matter > > if > > > > it's 2 or 22, the cryptographic properties are the same (it is > > > possible > > > > for someone to impersonate you, forge your messages, read your > > > > messages, etc). > > > >=20 > > > > Of course you can say that in the 802.11i case the authenticator > > is > > > > "trusted" and therefore it's OK for the authentication server to > > leak > > > > the secret to the authenticator (and have 3 people know the > secret). > > > > OK, fine. The other AP is also "trusted" to have the PMK so now 4 > > > people > > > > know the secret (or 5 "trusted" people or 10 "trusted" people). > > > Nothing > > > > changed. > > > >=20 > > > > In the case of a switch hosting multiple APs the switch is the > > > > authenticator and the APs are merely tentacles of the same > octopus. > > > The > > > > PMK isn't shared among the APs, it resides on the switch. There is > > > even > > > > one company I know of (I won't name it but it shouldn't be > difficult > > > to > > > > guess) in which the switch plays the role of the authentication > > server > > > > so the PMK is known only by the switch and the STA. This "PMK > > sharing" > > > > situation is even MORE secure than the traditional deployment > where > > a > > > > STA > > > > establishes a PMK with a RADIUS server and that PMK is leaked to > an > > > AP. > > > >=20 > > > > Dan. > > > >=20 > > > > On Thu, 21 Oct 2004 14:56:37 +0530 you wrote > > > > > hi all, > > > > >=20 > > > > > I am not sure, I am right on this. My impression is that, PMK is > > on > > > > per=20 > > > > > Authenticator MAC address. > > > > > If the station is re-associated with new WTP (different MAC > > > address), > > > > then=20 > > > > > it would not even send > > > > > PMKID of old AP. If there is no PMKID found in reassoc event, AC > > > would > > > >=20 > > > > > start with full 802.1x > > > > > authentication. If the station is reassociating with an AP, to > > which > > > > it=20 > > > > > already established PMK before, > > > > > then station sends PMKID and in that case only 4 way key > handshake > > > is=20 > > > > > requried to get the PTK. > > > > > With respect to this, I am not sure whether the statement > > > > > 'If PMK is shared across multiple WTP' is valid. If not, the > whole > >=20 > > > > > statement can be removed > > > > > from the draft > > > > >=20 > > > > > Regards > > > > > Rama Krishna Prasad > > > > >=20 > > > > >=20 > > > > >=20 > > > > > Ch. Rama Krishna Prasad > > > > > Intoto Software(I) Pvt Ltd, > > > > > Uma Plaza, Nagarjuna circle, > > > > > Panjagutta. Hyderabad, AP > > > > > Tel No:s 2335 8927/8928/8434 > > > > >=20 > > > > > _______________________________________________ > > > > > Capwap mailing list > > > > > Capwap@frascone.com > > > > > http://mail.frascone.com/mailman/listinfo/capwap > > > > _______________________________________________ > > > > Capwap mailing list > > > > Capwap@frascone.com > > > > http://mail.frascone.com/mailman/listinfo/capwap > > > > _______________________________________________ > > > > Capwap mailing list > > > > Capwap@frascone.com > > > > http://mail.frascone.com/mailman/listinfo/capwap > > > >=20 > > >=20 > >=20 >=20 _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Tue Oct 26 16:39:40 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15672 for ; Tue, 26 Oct 2004 16:39:30 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id D2E9B1FCC2; Tue, 26 Oct 2004 16:39:21 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id A6CC71FCCF; Tue, 26 Oct 2004 16:39:16 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id E861A1FC79 for ; Tue, 26 Oct 2004 12:05:51 -0400 (EDT) Received: from hermes.jf.intel.com (fmr05.intel.com [134.134.136.6]) by mail.frascone.com (Postfix) with ESMTP id 5C88D1FC64 for ; Tue, 26 Oct 2004 12:05:48 -0400 (EDT) Received: from petasus.jf.intel.com (petasus.jf.intel.com [10.7.209.6]) by hermes.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-outer.mc,v 1.15 2004/01/30 18:16:28 root Exp $) with ESMTP id i9QG9hDa003080; Tue, 26 Oct 2004 16:09:44 GMT Received: from orsmsxvs040.jf.intel.com (orsmsxvs040.jf.intel.com [192.168.65.206]) by petasus.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.11 2004/07/29 22:51:53 root Exp $) with SMTP id i9QG9KKt007761; Tue, 26 Oct 2004 16:09:22 GMT Received: from orsmsx331.amr.corp.intel.com ([192.168.65.56]) by orsmsxvs040.jf.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004102609003714770 ; Tue, 26 Oct 2004 09:00:37 -0700 Received: from orsmsx408.amr.corp.intel.com ([192.168.65.52]) by orsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 26 Oct 2004 09:00:36 -0700 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C4BB74.ED9BF40C" X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Subject: RE: FW: [Capwap] Important: please provide input on comment resolution for CAPWAP Taxonomy draft Message-ID: <2AF68A477DD44C4EBCBE338C24E7A9EE02828834@orsmsx408> Thread-Topic: RE: FW: [Capwap] Important: please provide input on comment resolution for CAPWAP Taxonomy draft Thread-Index: AcS7dO0Y4F5/NP8WSVWHDgKA3otxgw== From: "Yang, Lily L" To: "Walker, Jesse" , "Dan Harkins" , Cc: "capwap@frascone.com" <'capwap@frascone.com'.cnri.reston.va.us> X-OriginalArrivalTime: 26 Oct 2004 16:00:36.0771 (UTC) FILETIME=[EEA68F30:01C4BB74] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Tue, 26 Oct 2004 09:00:34 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) This is a multi-part message in MIME format. ------_=_NextPart_001_01C4BB74.ED9BF40C Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I tried to send this out last night but it never made it into the list due to its size... here I truncated all the previous trailing postings and hope it will make it to the list this time. -------------- =20 First of all, let me thank all of you, for the lively discussion we've had on this important issue. It certainly helps me a lot personally to understand the issue better. =20 IMHO, the debate and confusion here highlights one of the challenges that Centralized Architecture brings to the current 802.11 standard: while "WTP+AC"=3D"Logical AP" seems like a logical assertion, it is not always true that such functional split produces no ambiguity with respect to the 802.11 standard.=20 =20 Most of time, when .11 standard talks about an AP, we can take it as a logical AP, not a physical device, and the standard remains valid even if the logical AP functions are implemented across two physical devices. However, when 11i talks about AP as the "authenticator", I take it that it means the AP in the physical sense, that is, a *single physical device*. But when we split 11i functions into WTP and AC, unless one device (that is, either AC or WTP, but not both) consistently plays the role of "authenticator" in all the 11i functions, including 4-way handshake, authenticator state machine, etc, we would be in trouble because we are violating the basic architecture assumption that 11i makes. Therefore it is important to acknowledge the potential security risks associated with 11i functional split.=20 =20 On the other hand, it is not within the scope of CAPWAP taxonomy draft to explicitly identify the potential solutions and where such solutions should come from, etc. It is valuable discussion that we should have sooner or later in some forum (either here or somewhere else), but it is not yet critically important for us to resolve that within this draft. =20 But it *is* critically important for us to resolve how to fix the taxonomy draft so that the additional security concerns due to the functional split are properly documented so that we can close on this draft and move on to the next steps. =20 Therefore, I would encourage that we focus our discussion on how to best describe the additional security challenges for client data protection. Remember that one of the motivations to use Centralized Architecture is to enhance the security, not to lessen it, relatively to the traditional "Autonomous Architecture". =20 The paragraph in question is 4.8.1: "If the PMK (Pairwise Master Key) is reused across multiple WTPs, then requiring a 4-way handshake for each WTP that the station associates to, followed by the transfer of that PTK from the AC to the WTP, would ensure that a different PTK is used at each WTP." =20 The issue at hand is whether or not PMK can be reused across multiple WTPs as defined in 11i today, without introducing additional security risks. =20 I would like to take a step back, and go back to the original categories that Inderpreet provided and refine on it and see if we can agree on the following analysis: =20 Case 1: If AC handles all 11i functions (key mgmt, privacy & integrity encryption, etc.) and functions fully as the "authenticator" without WTP getting invovled, then there is no additional security issue from 11i's point of view. (Note we are talking about client data security here only in 4.8.1, not AC-WTP control message security which is covered in 4.8.2). =20 Case 2: If 11i is split between AC and WTP in the way that AC handles all Authentication and Key Management (for PMK and PTK), but WTP handles privacy and integrity encryption, then it is necessary for WTP to possess PTK (but not PMK), therefore it is necessary to guarantee a secure way to transfer PTK from AC to WTP. Provided that this additional requirement is met, this functional split is still a relatively safe usage model with respect to 11i, because only the AC (acting as the authenticator) possesses PMK, similar to the case in Autonomous Architecture where AP possesses PMK. But I would argue that this split still maintain the security "advantage" argument of Centralized Architecture because AC typically can assume better physical security than AP, and there are typically significantly fewer ACs in Centralized Architecture than the APs. =20 Case 3: If 11i is split between AC and WTP in the way that AC handles .1X/EAP Authentication (as the authenticator, possesses PMK), but WTP handles 4-way handshake and encryption, then it is necessary for WTP (in addition to AC) to possess PMK as well. I would argue that such split would weaken the network security, because now PMK is exposed to WTP, and the physical security of a large number of WTPs is one of the challenges that motivated the Centralized Architecture at the first place. If PMK is shared among multiple WTPs (to support roaming or whatever other functions), it would further weaken the security of the network as explained by Jesse. Therefore, such a functional split seems to present more security challenges than Case 1 and 2. It doesn't mean that it can't be done; it just means that additional work on security might be necessary to ensure that the security of the network is not in any way reduced (similar to the goal in 11r as articulated by Clint).=20 =20 So it seems to me that the security considerations would vary depending on how the 11i functions are split between AC and WTP. The CAPWAP taxonomy draft should highlight the different security considerations without getting into the solution space. =20 =20 Lily =20 =20 ------_=_NextPart_001_01C4BB74.ED9BF40C Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I tried to send this out last night but it never made it into the list due to = its size… here I truncated all the previous trailing postings and hope it will = make it to the list this time.

--------------

 

First of all, let me thank all of you, for the lively discussion we've had on = this important issue. It certainly helps me a lot personally to understand = the issue better.

 

IMHO, the debate and confusion here highlights one of the challenges that = Centralized Architecture brings to the current 802.11 standard: while "WTP+AC"=3D"Logical AP" seems like a logical = assertion, it is not always true that such functional split produces no ambiguity with = respect to the 802.11 standard.

 

Most of time, when .11 standard talks about an AP, we can take it as a logical = AP, not a physical device, and the standard remains valid even if the logical AP functions are implemented across two physical devices. However, when 11i = talks about AP as the "authenticator", I take it that it means the = AP in the physical sense, that is, a *single physical device*. But when we split 11i functions into WTP = and AC, unless one device (that is, either AC or WTP, but not both) consistently = plays the role of "authenticator" in all the 11i functions, = including 4-way handshake, authenticator state machine, etc, we would be in trouble = because we are violating the basic architecture assumption that 11i makes. = Therefore it is important to acknowledge the potential security risks associated with = 11i functional split.

 

On the other hand, it is not within the scope of CAPWAP taxonomy draft to = explicitly identify the potential solutions and where such solutions should come = from, etc. It is valuable discussion that we should have sooner or later in = some forum (either here or somewhere else), but it is not yet critically = important for us to resolve that within this draft.

 

But it *is* critically important for us to resolve how to fix the taxonomy = draft so that the additional security concerns due to the functional split are = properly documented so that we can close on this draft and move on to the next = steps.

 

Therefore, I would encourage that we focus our discussion on how to best describe = the additional security challenges for client data protection. Remember that = one of the motivations to use Centralized Architecture is to enhance the = security, not to lessen it, relatively to the traditional “Autonomous = Architecture”.

 

The paragraph in question is 4.8.1:

"If the PMK (Pairwise Master Key) is reused across multiple
WTPs, then requiring a 4-way handshake for each WTP that the station
associates to, followed by the transfer of that PTK from the AC to the = WTP, would ensure that a different PTK is used at each = WTP."

 

The issue at hand is whether or not PMK can be reused across multiple WTPs = as defined in 11i today, without introducing additional security = risks.

 

I would like to take a step back, and go back to the original categories that Inderpreet provided and refine on it and see if we can agree on the = following analysis:

 

Case 1: If AC handles all 11i functions (key mgmt, privacy & integrity = encryption, etc.) and functions fully as the “authenticator” without WTP = getting invovled, then there is no additional security issue from 11i's point of view. = (Note we are talking about client data security here only in 4.8.1, not AC-WTP = control message security which is covered in 4.8.2).

 

Case 2: If 11i is split between AC and WTP in the way that AC handles all Authentication and Key Management (for PMK and PTK), but WTP handles = privacy and integrity encryption, then it is necessary for WTP to possess PTK = (but not PMK), therefore it is necessary to guarantee a secure way to transfer = PTK from AC to WTP. Provided that this additional requirement is met, this = functional split is still a relatively safe usage model with respect to 11i, = because only the AC (acting as the authenticator) possesses PMK, similar to the case = in Autonomous Architecture where AP possesses PMK. But I would argue that = this split still maintain the security “advantage” argument of = Centralized Architecture because AC typically can assume better physical security = than AP, and there are typically significantly fewer ACs in Centralized = Architecture than the APs.

 

Case 3: If 11i is split between AC and WTP in the way that AC handles .1X/EAP Authentication (as the authenticator, possesses PMK), but WTP handles = 4-way handshake and encryption, then it is necessary for WTP (in addition to = AC) to possess PMK as well. I would argue that such split would weaken the = network security, because now PMK is exposed to WTP, and the physical security = of a large number of WTPs is one of the challenges that motivated the = Centralized Architecture at the first place. If PMK is shared among multiple WTPs = (to support roaming or whatever other functions), it would further weaken = the security of the network as explained by Jesse. Therefore, such a = functional split seems to present more security challenges than Case 1 and 2. It = doesn’t mean that it can’t be done; it just means that additional work on = security might be necessary to ensure that the security of the network is not in = any way reduced (similar to the goal in 11r as articulated by Clint). =

 

So it seems to me that the security considerations would vary depending on how = the 11i functions are split between AC and WTP. The CAPWAP taxonomy draft = should highlight the different security considerations without getting into the solution space.

 

 

Lily

 <= /span>

 

------_=_NextPart_001_01C4BB74.ED9BF40C-- _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Tue Oct 26 16:40:07 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15787 for ; Tue, 26 Oct 2004 16:39:58 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 529D11FCD0; Tue, 26 Oct 2004 16:39:38 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 3B3D31FDD9; Tue, 26 Oct 2004 16:39:32 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 6BFE81FC64 for ; Tue, 26 Oct 2004 13:44:21 -0400 (EDT) Received: from caduceus.jf.intel.com (fmr06.intel.com [134.134.136.7]) by mail.frascone.com (Postfix) with ESMTP id 1D4D81FC0F for ; Tue, 26 Oct 2004 13:44:18 -0400 (EDT) Received: from petasus.jf.intel.com (petasus.jf.intel.com [10.7.209.6]) by caduceus.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-outer.mc,v 1.15 2004/01/30 18:16:28 root Exp $) with ESMTP id i9QHhoR5003061; Tue, 26 Oct 2004 17:43:53 GMT Received: from orsmsxvs041.jf.intel.com (orsmsxvs041.jf.intel.com [192.168.65.54]) by petasus.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.11 2004/07/29 22:51:53 root Exp $) with SMTP id i9QHlhKt004604; Tue, 26 Oct 2004 17:47:47 GMT Received: from orsmsx332.amr.corp.intel.com ([192.168.65.60]) by orsmsxvs041.jf.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004102610433418463 ; Tue, 26 Oct 2004 10:43:38 -0700 Received: from orsmsx401.amr.corp.intel.com ([192.168.65.207]) by orsmsx332.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 26 Oct 2004 10:43:24 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: FW: [Capwap] Important: please provide input on comment resolution for CAPWAP Taxonomy draft Message-ID: Thread-Topic: FW: [Capwap] Important: please provide input on comment resolution for CAPWAP Taxonomy draft Thread-Index: AcS7fiAqUeUE/LxuToOI/Kp2OZW0FAABP6Jg From: "Walker, Jesse" To: "Dan Harkins" Cc: "Yang, Lily L" , , X-OriginalArrivalTime: 26 Oct 2004 17:43:24.0720 (UTC) FILETIME=[4B08E300:01C4BB83] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Tue, 26 Oct 2004 10:43:24 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: quoted-printable Dan, My arguments are not convincing to you, and yours are not to me. We will just have to disagree. Best wishes on your position. -- Jesse -----Original Message----- From: Dan Harkins [mailto:dharkins@trpz.com]=20 Sent: Tuesday, October 26, 2004 10:05 AM To: Walker, Jesse Cc: Yang, Lily L; capwap@frascone.com; housley@vigilsec.com Subject: Re: FW: [Capwap] Important: please provide input on comment resolution for CAPWAP Taxonomy draft=20 Jesse, I know you didn't appeal to the 3 party protocol; I did. I was pointing out that it suffers from exactly what you claim "PMK sharing" suffers from.=20 I cannot provide you with a deterministic algorithm to allow a supplicant to know whether or not the PMK was compromised when doing "PMK sharing" but you also cannot provide a deterministic algorithm to allow a supplicant to know whether or not the PMK was compromised in the 3 party protocol (i.e. even without "PMK sharing").=20 It seems somewhat disingenuous for you to claim that "PMK sharing" is bad and insist on someone providing you with a deterministic algorithm while simultaneously ignoring exactly the same problems with the 3 party protocol (and conveniently not demanding a deterministic algorithm for that). Earlier in this thread you asked how a "properly implemented"=20 supplicant would know, when PMKs are shared, whether AP2 was an attacker that compromised AP1 or not. I said by exactly the same method a "properly implemented" supplicant knows that the PMK asserted by the AP in the 3 party protocol was compromised or not. You seem to think there is a reason for the supplicant to believe in the 3 party protocol. OK, great! Then by that same reasoning it should believe in the integrity of a PMK that is shared. Let me close this increasingly tedious thread by noting: - "PMK sharing" is, indeed, allowed in the 11i draft as Jesse alluded to earlier when he mentioned, as option (c), that the text could be removed. - "PMK sharing" is not free of security considerations, but then 11i is based on a protocol which, itself, is not free of security considerations and suffers from exactly the same issues that "PMK sharing" does. - The upside of "PMK sharing" is that a AAA server will not be hammered by supplicants in problematic RF environments, and handoffs can happen in sub 50ms. The downside is that there are security considerations to it, but then if those security considerations were enough to make you not support "PMK sharing" then you should not support 11i. Dan. On Tue, 26 Oct 2004 06:46:17 PDT you wrote > Dan, >=20 > Please reread my last message. Nowhere did I appeal to the use of a > 3-party protocol. The argument was based solely on the configuration of > state, regardless of how it was delivered. The problem is the quite > reasonable usage CAPWAP wants to make never took into account that the > infrastructure has to recognize and accommodate the EAP Peer's security > policy as well as vice versa. There are at least two ways CAPWAP could > accommodate the EAP Peer's security policy. One way is to not share > keys. A second way is to rely on a key binding protocol. Either approach > can be made to work. >=20 > You are right in one way; the discussion isn't just about CAPWAP; there > is a problem with the basic EAP keying model, and that, not CAPWAP, is > the prey in this hunt. The problem with the EAP keying model is that it > never establishes a contract governing the behavior of the EAP Peer's > and NAS's use of what it calls the MSK. >=20 > -- Jesse >=20 > -----Original Message----- > From: Dan Harkins [mailto:dharkins@trpz.com]=20 > Sent: Monday, October 25, 2004 4:54 PM > To: Walker, Jesse > Cc: Yang, Lily L; capwap@frascone.com; housley@vigilsec.com > Subject: Re: FW: [Capwap] Important: please provide input on comment > resolution for CAPWAP Taxonomy draft=20 >=20 > Jesse, >=20 > That same argument can be made against the existing 3 party exchange > between the supplicant, authentication server, and authenticator. > In fact, the existing 3 party exchange could be viewed as the degenerate > case of "PMK sharing". >=20 > When the AP asserts possession of the PMK the supplicant has no > way of knowing whether that AP is a valid, trusted AP or is an attacker > that has compromised another AP (or the AP <--> AS connection) and > is playing man-in-the-middle. >=20 > The reason this is so is because the supplicant never told the > authentication server to share the PMK with an entity identified by > a particular BSSID (and the authentication server does not maintain > a relationship with an entity identified by BSSID anyway), nor did > the AP provide some "ticket" to the supplicant proving that it is > trusted by the authentication server to know this secret. Either of > which would've made this exchange more secure. >=20 > Can you show me some deterministic way for a supplicant to distinguish > between these two: >=20 > 1. the AAA client (entity trusted by the AS) and radio (that > entity identified by a BSSID that the client is speaking to) are > different parts of the same device and within the same security > boundary. >=20 > 2. the AAA client is on an AP that has been compromised by an > attacker and the radio with which the supplicant is communicating > is on the attacker. The attacker relays the EAP exchange through > the compromised AP and obtains the PMK. >=20 > If not then I maintain that there is no less security by doing "PMK > sharing". You're including two things in a cryptographic boundary-- > the AAA client and radio-- that are not cryptographically bound > and are asking the supplicant to make a leap of faith. I can just > as easily draw a different cryptographic boundary and ask the > supplicant to make an _identical_ leap of faith. You can't have it > both ways, if it's OK for the existing 3 party exchange then it's > OK for "PMK sharing".=20 >=20 > Dan. >=20 > On Mon, 25 Oct 2004 15:44:13 PDT you wrote > > Dan, > >=20 > > Let me go through this yet again. > >=20 > > In the 802.11i we discussion we said over and over and over and over > > again that the PMK must be kept within a single crypto boundary or it > is > > compromised. > >=20 > > Now, if you have two classical APs, they represent separate crypto > > boundaries, because if you share a PMK between them and you compromise > > one AP, then the client's traffic is compromised at the other, while > if > > you don't share PMKs between them then compromise of one does not lead > > to compromise of the client's traffic at the other. > >=20 > > It follows from the crypto boundaries argument, that different > classical > > APs must be provisioned with independent PMKs. When this is not done, > > the client must treat its own PMK shared across different classical > APs > > as a violation of its (the client's) security policy, because PMK > > sharing explicitly violates the crypto boundaries principle. > >=20 > > Under 802.11, 802.11i, 802.1X, and EAP the client does not learn > whether > > an AP is a classical AP or a new switched AP such as what would be > > described by CAPWAP. The only thing 802.11 and 802.11i and 802.1X and > > EAP provide the client to distinguish one AP from another is the AP's > > BSSID. This means every AP looks like a classical AP to a client using > > the existing standardized 802.1, 802.11i, 802.1X, and EAP. > >=20 > > Since the client cannot tell a classical AP from a switched AP, it > > follows that a switched AP cannot share PMKs among its different > > light-weight APs, because doing so violates the client's security > > policy. That is, unless and until it receives evidence to the > contrary, > > the client must assume that it is communicating with a classical AP, > and > > PMK reuse between two classical APs violates its policy by violating > the > > crypto boundary principle. The reason why it must assume this is that > it > > does not and cannot know the contrary, and security says the client > must > > make the most conservative assumption consistent with the facts known > to > > it (performance, manageability, etc., might argue something else, but > we > > are discussing security here). > >=20 > > I don't know what is not clear about this. > >=20 > > -- Jesse=20 > >=20 > > -----Original Message----- > > From: Dan Harkins [mailto:dharkins@trpz.com]=20 > > Sent: Monday, October 25, 2004 3:05 PM > > To: Walker, Jesse > > Cc: Yang, Lily L; capwap@frascone.com; housley@vigilsec.com > > Subject: Re: FW: [Capwap] Important: please provide input on comment > > resolution for CAPWAP Taxonomy draft=20 > >=20 > > Jesse, > >=20 > > You are not addressing any of the issues I raised in response to > > your previous demand for a deterministic algorithm, you're just > > repeating yourself. I was trying to point out how the security of > > the system is not lessened by the lack of such an algorithm. I > > asked you to show me where in that email I was wrong and how I > > was wrong. I even added some more analysis of what I think is the > > crux of the matter. You ignored it all.=20 > >=20 > > Sigh, > >=20 > > Dan. > >=20 > > On Mon, 25 Oct 2004 14:28:16 PDT you wrote > > > Dan, > > >=20 > > > I have already explained this, but will do so again out of common > > > courtesy. Please provide a deterministic algorithm by which a client > > > determines whether PMK sharing between AP1 and AP2 is acceptable or > > > represents a compromise, using information available to it under > > > 802.11i. If you produce such an algorithm, then I withdraw my claim > > and > > > apologize. If you cannot, then my assertion stands. > > >=20 > > > -- Jesse > > >=20 > > > -----Original Message----- > > > From: Dan Harkins [mailto:dharkins@trpz.com]=20 > > > Sent: Monday, October 25, 2004 1:56 PM > > > To: Walker, Jesse > > > Cc: Yang, Lily L; capwap@frascone.com; housley@vigilsec.com > > > Subject: Re: FW: [Capwap] Important: please provide input on comment > > > resolution for CAPWAP Taxonomy draft=20 > > >=20 > > > Jesse, > > >=20 > > > Common courtesy dictates that one should not merely state "you are > > > wrong" but to explain exactly where one is wrong. > > >=20 > > > Abstract language is getting in the way of my point so let me > > > just use common vernacular that is descriptive of what is deployed > > > today: > > >=20 > > > If I can try to boil this down I think the residue we will be left > > > with is that you believe that there is a one-to-one relationship > > > between a RADIUS client and a BSSID that a supplicant speaks to and > > > that the identity of the RADIUS client and BSSID are interchangable. > > > It is that belief, I believe, that causes you to infer a binding of > > > PMK to BSSID when, strictly speaking, none exists. > > >=20 > > > The RADIUS server has a trust relationship with a RADIUS client. > > > That RADIUS client is identified, to the RADIUS server, with an IP > > > address. You are assuming that that RADIUS client, identified by > > > its IP address, has one and only one BSSID. This is incorrect. > > > Furthermore you are assuming that this 3 way protocol between the > > > supplicant, the RADIUS server, and the RADIUS client is 1) secure; > > > and 2) extensible to a different identity of the RADIUS client, a > > > BSSID, without loss of security. > > >=20 > > > Feel free to tell me I'm wrong again, but please tell me where > > > and how. > > >=20 > > > Dan. > > >=20 > > > On Mon, 25 Oct 2004 13:03:24 PDT you wrote > > > > Dan, > > > >=20 > > > > You are wrong. The problem is there is no Needham-Shroeder-eseque > > > > protocol in the back end. > > > >=20 > > > > -- Jesse > > > >=20 > > > > -----Original Message----- > > > > From: Dan Harkins [mailto:dharkins@trpz.com]=20 > > > > Sent: Monday, October 25, 2004 12:58 PM > > > > To: Yang, Lily L > > > > Cc: capwap@frascone.com; Walker, Jesse; housley@vigilsec.com > > > > Subject: Re: FW: [Capwap] Important: please provide input on > comment > > > > resolution for CAPWAP Taxonomy draft=20 > > > >=20 > > > > I beg to differ. > > > >=20 > > > > If this was a Needham-Schroeder-esqe protocol Jesse might have a > > > > point. But it's not. > > > >=20 > > > > There is no way for a "properly implemented" client to know that > > the > > > > AP it is speaking to is trusted by the authentication server since > > > > nothing in the exchange that derives the PMK includes anything > about > > > > the AP. It's merely a man-in-the-middle. The AP proves knowledge > of > > > the > > > > PMK so the client is just supposed to assume it's trusted! What is > > > being > > > > asked here is just ignore that > unpleasant > > > > security issue and believe we have > a > > > > secure > > > > 3-party authenticaiton system here so that we can then condemn a > > > scheme > > > > that suffers from that same unpleasant security issue. > > > >=20 > > > > How does a "properly implemented" client know that AP2 is not a > > > > attacker which compromised AP1? By the same technique that it used > > > > to know that AP1 was not an attacker which compromised the authen- > > > > tication server (or the link between the authentication server and > a > > > > legitimate authenticator). Since a "properly implemented" client > can > > > > do the latter it can take the same steps to do the former. > > > >=20 > > > > If mere proof of possession of the PMK is enough to legitimize > AP1 > > > > to the client then mere proof of possession of the PMK is enough > to > > > > legitimize AP2 to the client. You cannot reasonably claim > otherwise. > > > >=20 > > > > This is not to say that Jesse's suggestions of (a) or (b) below > > > > are not needed, I would welcome either of those. I would also like > > > > to note that Jesse's mention of (c) is an explicit acknowledgment > > > > that "PMK sharing" is permitted by the existing specification. > > > >=20 > > > > Dan. > > > >=20 > > > > On Mon, 25 Oct 2004 09:33:05 PDT you wrote > > > > > I solicited input from Jesse Walker and Russ Housley on the > issue > > of > > > > PMK > > > > > sharing, and here is the response from Jesse. He agrees to let > me > > > > > forward this to the CAPWAP list. I also cc Jesse and Russ here. > > > Since > > > > > Russ posted the original comment in IESG review, and Jesse is > the > > > > > technical editor of 11i, I think it would be good that we keep > > them > > > in > > > > > the loop with regard this discussion. So please cc them in your > > > email > > > > > posting on this issue as they are not in the CAPWAP list. > > > > >=20 > > > > > -----Original Message----- > > > > > From: Walker, Jesse=20 > > > > > Sent: Saturday, October 23, 2004 7:05 PM > > > > > To: Yang, Lily L; 'housley@vigilsec.com' > > > > > Subject: RE: [Capwap] Important: please provide input on comment > > > > > resolution for CAPWAP Taxonomy draft=20 > > > > >=20 > > > > > Lily, > > > > >=20 > > > > > Dan's reasoning is invalid, unless he or someone else can > produce > > a > > > > > deterministic algorithm that allows the client to distinguish > the > > > > > following two cases: > > > > >=20 > > > > > Case 1: AP1 and AP2 are classical access points. An attacker > > > > compromises > > > > > AP1 and AP2 and moves the client's PMK from AP1 and AP2. > > > > >=20 > > > > > Case 2: AP1 and AP2 are two light-weight access points that are > > part > > > > of > > > > > the same switch S. The switch S uses the same PMK with both AP1 > > and > > > > AP2. > > > > >=20 > > > > > If no one can demonstrate a deterministic algorithm the client > can > > > use > > > > > to distinguish the two cases, then a properly implemented client > > > will > > > > > always assume its PMK has been compromised when it sees either > > case. > > > I > > > > > suspect no one can, because the client lacks the necessary > state. > > > > >=20 > > > > > It appears to me there are three possible solutions: > > > > >=20 > > > > > a. The first is the necessary state is somehow delivered to the > > > client > > > > > in an attestable fashion. The only party that client trusts is > the > > > AAA > > > > > server, so this implies a new binding protocol between the AAA > > > server > > > > > and the EAP Peer. > > > >=20 > > > > > b. The second is to define a new protocol that delivers the AP's > > > > > authenticated identifier to the EAP Peer in an attestable > fashion, > > > and > > > > > to change the 802.11i key confirmation handshake to use this > > > > identifier > > > > > instead of the BSSID of the APs. > > > > >=20 > > > > > c. The text that permits this usage should be removed. > > > > >=20 > > > > > I believe possibilities (a) or (b) are the right way to address > > this > > > > > issue. > > > > >=20 > > > > > -- Jesse > > > > >=20 > > > > > -----Original Message----- > > > > > From: Yang, Lily L=20 > > > > > Sent: Friday, October 22, 2004 12:03 PM > > > > > To: Walker, Jesse; housley@vigilsec.com > > > > > Subject: FW: [Capwap] Important: please provide input on comment > > > > > resolution for CAPWAP Taxonomy draft=20 > > > > > Importance: High > > > > >=20 > > > > > Jesse and Russ -- > > > > >=20 > > > > > CAPWAP WG has had some email discussion regarding the comment > from > > > you > > > > > on PMK sharing. I don't think either of you are on the list, so > I > > am > > > > > forwarding to you this and I would like to hear what you think > > about > > > > > these responses.=20 > > > > >=20 > > > > > Lily > > > > >=20 > > > > > -----Original Message----- > > > > > From: capwap-admin@frascone.com > [mailto:capwap-admin@frascone.com] > > > On > > > > > Behalf Of Dan Harkins > > > > > Sent: Thursday, October 21, 2004 9:47 AM > > > > > To: Chunduru Rama Krishna Prasad > > > > > Cc: capwap@frascone.com > > > > > Subject: Re: [Capwap] Important: please provide input on comment > > > > > resolution for CAPWAP Taxonomy draft=20 > > > > >=20 > > > > > Strictly speaking the PMK is shared between the supplicant and > > the > > > > > authentication server, not the authenticator. There are no MAC > > > > addresses > > > > > bound to the PMK or used in the derivation of the PMK. > > > > >=20 > > > > > As the person who got PMK caching and PMKIDs into the 802.11i > > > draft > > > > > let me explain the steps we went through: > > > > >=20 > > > > > - first motion was to indicate the ability of a STA to do "PMK > > > > > caching" > > > > > in an associate request. If the authenticator had a cached > PMK > > > for > > > > > the STA it would respond with the 1st message of the 4way > > > > handshake, > > > > > otherwise it would respond with an 802.1x encapsulated EAP > > > > Identity > > > > > request. That enabled the functionality you describe below-- > > > "the > > > > > station is reassociating with an AP to with it already > > > established > > > > > the PMK before..." It prevented a STA in a difficult RF > > > > environment > > > > > from ping-ponging back and forth between APs and hammering > an=20 > > > > > authentication server. > > > > >=20 > > > > > - it soon became apparent that an authenticator may have > > multiple > > > > PMKs > > > > > for a particular STA in its cache. How? Via something like a > > > > > pro-active > > > > > key pushing mechanism using neighbor graphs (Bill Arbaugh > > > > presented > > > > > this idea). So the next motion was to name PMKs with a PMKID > > to > > > > > indicate which PMK a STA is asserting in its associate > > request. > > > > > This eliminated the ambiguity. > > > > >=20 > > > > > So the very reason that we have PMKIDs, and not just blind > > > assertions > > > > of > > > > > a cached PMK, is because the PMK may be used to derive a PTK for >=20 > > > > > multiple APs. The statement "If PMK is shared across multiple > > WTPs" > > > > is, > > > > > indeed, valid. > > > > >=20 > > > > > Addressing Russ's comment, the PMK is already leaked because > it > > is > > > > > given to the authenticator by the authentication server. When > > > > discussing > > > > "the number of other people who know my secret" there are 3 > possible > > > > > values: 0, 1 and infinity. If 0 other people know your secret > > there > > > > are > > > > > certain cryptographic properties associated with that state. If > 1 > > > > other > > > > > person knows your secret there are other cryptographic > properties > > > > > associated with that state (message source authentication for > > > > instance), > > > > > but if more than 1 person knows your secret then it doesn't > matter > > > if > > > > > it's 2 or 22, the cryptographic properties are the same (it is > > > > possible > > > > > for someone to impersonate you, forge your messages, read your > > > > > messages, etc). > > > > >=20 > > > > > Of course you can say that in the 802.11i case the > authenticator > > > is > > > > > "trusted" and therefore it's OK for the authentication server to > > > leak > > > > > the secret to the authenticator (and have 3 people know the > > secret). > > > > > OK, fine. The other AP is also "trusted" to have the PMK so now > 4 > > > > people > > > > > know the secret (or 5 "trusted" people or 10 "trusted" people). > > > > Nothing > > > > > changed. > > > > >=20 > > > > > In the case of a switch hosting multiple APs the switch is the > > > > > authenticator and the APs are merely tentacles of the same > > octopus. > > > > The > > > > > PMK isn't shared among the APs, it resides on the switch. There > is > > > > even > > > > > one company I know of (I won't name it but it shouldn't be > > difficult > > > to > > > > > guess) in which the switch plays the role of the authentication > > > server > > > > > so the PMK is known only by the switch and the STA. This "PMK > > > sharing" > > > > > situation is even MORE secure than the traditional deployment > > where > > > a > > > > > STA > > > > > establishes a PMK with a RADIUS server and that PMK is leaked to > > an > > > > AP. > > > > >=20 > > > > > Dan. > > > > >=20 > > > > > On Thu, 21 Oct 2004 14:56:37 +0530 you wrote > > > > > > hi all, > > > > > >=20 > > > > > > I am not sure, I am right on this. My impression is that, PMK > is > > > on > > > > > per=20 > > > > > > Authenticator MAC address. > > > > > > If the station is re-associated with new WTP (different MAC > > > > address), > > > > > then=20 > > > > > > it would not even send > > > > > > PMKID of old AP. If there is no PMKID found in reassoc event, > AC > > > > would > > > > >=20 > > > > > > start with full 802.1x > > > > > > authentication. If the station is reassociating with an AP, to > > > which > > > > > it=20 > > > > > > already established PMK before, > > > > > > then station sends PMKID and in that case only 4 way key > > handshake > > > > is=20 > > > > > > requried to get the PTK. > > > > > > With respect to this, I am not sure whether the statement > > > > > > 'If PMK is shared across multiple WTP' is valid. If not, the > > whole > > >=20 > > > > > > statement can be removed > > > > > > from the draft > > > > > >=20 > > > > > > Regards > > > > > > Rama Krishna Prasad > > > > > >=20 > > > > > >=20 > > > > > >=20 > > > > > > Ch. Rama Krishna Prasad > > > > > > Intoto Software(I) Pvt Ltd, > > > > > > Uma Plaza, Nagarjuna circle, > > > > > > Panjagutta. Hyderabad, AP > > > > > > Tel No:s 2335 8927/8928/8434 > > > > > >=20 > > > > > > _______________________________________________ > > > > > > Capwap mailing list > > > > > > Capwap@frascone.com > > > > > > http://mail.frascone.com/mailman/listinfo/capwap > > > > > _______________________________________________ > > > > > Capwap mailing list > > > > > Capwap@frascone.com > > > > > http://mail.frascone.com/mailman/listinfo/capwap > > > > > _______________________________________________ > > > > > Capwap mailing list > > > > > Capwap@frascone.com > > > > > http://mail.frascone.com/mailman/listinfo/capwap > > > > >=20 > > > >=20 > > >=20 > >=20 >=20 _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Tue Oct 26 17:34:14 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27816 for ; Tue, 26 Oct 2004 17:34:09 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 2DF651FCC0; Tue, 26 Oct 2004 17:34:09 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 261ED1FCC1; Tue, 26 Oct 2004 17:34:05 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id BA6A11FCC1 for ; Tue, 26 Oct 2004 17:33:25 -0400 (EDT) Received: from WNIMAIL.WoodsideNet.Com (wnifwl.woodsidenet.com [65.192.186.2]) by mail.frascone.com (Postfix) with ESMTP id 4F7B01FCC0 for ; Tue, 26 Oct 2004 17:33:22 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: FW: [Capwap] Important: please provide input on comment resolution for CAPWAP Taxonomy draft Message-ID: <3FFBC907DD03A34CA4410C5C745DEB1204A2312A@wnimail.WoodsideNet.Com> Thread-Topic: FW: [Capwap] Important: please provide input on comment resolution for CAPWAP Taxonomy draft Thread-Index: AcS7fiAqUeUE/LxuToOI/Kp2OZW0FAABP6JgAAfaHCA= From: "Paul Lambert" To: "Walker, Jesse" , "Dan Harkins" Cc: "Yang, Lily L" , , X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Tue, 26 Oct 2004 14:33:20 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: quoted-printable Jesse, I think I see your point ..., let me try to rephrase: How does a client obtain the PMK and associated PMKID in a 'secure' manner?=20 This is an open 'problem' that allows vendors to field proprietary mechanisms to establish the PMK and PMKID bindings. Now, I thought this was a planned feature ... that requires future work for interoperability. So, I think I see your point, more work is required, but we really should allow multiple BSSIDs to share the same PMKID and PMK. Future work is required to provide the automated distribution if the BSSIDs are not co-located. Paul > -----Original Message----- > From: capwap-admin@frascone.com=20 > [mailto:capwap-admin@frascone.com] On Behalf Of Walker, Jesse > Sent: Tuesday, October 26, 2004 10:43 AM > To: Dan Harkins > Cc: Yang, Lily L; capwap@frascone.com; housley@vigilsec.com > Subject: RE: FW: [Capwap] Important: please provide input on=20 > comment resolution for CAPWAP Taxonomy draft=20 >=20 > Dan, >=20 > My arguments are not convincing to you, and yours are not to=20 > me. We will just have to disagree. Best wishes on your position. >=20 > -- Jesse >=20 > -----Original Message----- > From: Dan Harkins [mailto:dharkins@trpz.com] > Sent: Tuesday, October 26, 2004 10:05 AM > To: Walker, Jesse > Cc: Yang, Lily L; capwap@frascone.com; housley@vigilsec.com > Subject: Re: FW: [Capwap] Important: please provide input on=20 > comment resolution for CAPWAP Taxonomy draft=20 >=20 > Jesse, >=20 > I know you didn't appeal to the 3 party protocol; I did. I=20 > was pointing out that it suffers from exactly what you claim=20 > "PMK sharing" suffers from.=20 >=20 > I cannot provide you with a deterministic algorithm to=20 > allow a supplicant to know whether or not the PMK was=20 > compromised when doing "PMK sharing" but you also cannot=20 > provide a deterministic algorithm to allow a supplicant to=20 > know whether or not the PMK was compromised in the 3 party=20 > protocol (i.e. even without "PMK sharing").=20 >=20 > It seems somewhat disingenuous for you to claim that "PMK sharing" > is bad and insist on someone providing you with a=20 > deterministic algorithm while simultaneously ignoring exactly=20 > the same problems with the 3 party protocol (and conveniently=20 > not demanding a deterministic algorithm for that). >=20 > Earlier in this thread you asked how a "properly implemented"=20 > supplicant would know, when PMKs are shared, whether AP2 was=20 > an attacker that compromised AP1 or not. I said by exactly=20 > the same method a "properly implemented" supplicant knows=20 > that the PMK asserted by the AP in the 3 party protocol was=20 > compromised or not. > You seem to think there is a reason for the supplicant to=20 > believe in the 3 party protocol. OK, great! Then by that same=20 > reasoning it should believe in the integrity of a PMK that is shared. >=20 > Let me close this increasingly tedious thread by noting: >=20 > - "PMK sharing" is, indeed, allowed in the 11i draft > as Jesse alluded to earlier when he mentioned, as > option (c), that the text could be removed. >=20 > - "PMK sharing" is not free of security considerations, > but then 11i is based on a protocol which, itself, > is not free of security considerations and suffers > from exactly the same issues that "PMK sharing" does. >=20 > - The upside of "PMK sharing" is that a AAA server will > not be hammered by supplicants in problematic RF > environments, and handoffs can happen in sub 50ms. > The downside is that there are security considerations > to it, but then if those security considerations were > enough to make you not support "PMK sharing" then > you should not support 11i. >=20 > Dan. >=20 > On Tue, 26 Oct 2004 06:46:17 PDT you wrote > > Dan, > >=20 > > Please reread my last message. Nowhere did I appeal to the use of a=20 > > 3-party protocol. The argument was based solely on the configuration > of > > state, regardless of how it was delivered. The problem is the quite=20 > > reasonable usage CAPWAP wants to make never took into=20 > account that the=20 > > infrastructure has to recognize and accommodate the EAP Peer's > security > > policy as well as vice versa. There are at least two ways=20 > CAPWAP could=20 > > accommodate the EAP Peer's security policy. One way is to not share=20 > > keys. A second way is to rely on a key binding protocol. Either > approach > > can be made to work. > >=20 > > You are right in one way; the discussion isn't just about CAPWAP; > there > > is a problem with the basic EAP keying model, and that, not=20 > CAPWAP, is=20 > > the prey in this hunt. The problem with the EAP keying model is that > it > > never establishes a contract governing the behavior of the=20 > EAP Peer's=20 > > and NAS's use of what it calls the MSK. > >=20 > > -- Jesse > >=20 > > -----Original Message----- > > From: Dan Harkins [mailto:dharkins@trpz.com] > > Sent: Monday, October 25, 2004 4:54 PM > > To: Walker, Jesse > > Cc: Yang, Lily L; capwap@frascone.com; housley@vigilsec.com > > Subject: Re: FW: [Capwap] Important: please provide input=20 > on comment=20 > > resolution for CAPWAP Taxonomy draft > >=20 > > Jesse, > >=20 > > That same argument can be made against the existing 3=20 > party exchange=20 > > between the supplicant, authentication server, and authenticator. > > In fact, the existing 3 party exchange could be viewed as the > degenerate > > case of "PMK sharing". > >=20 > > When the AP asserts possession of the PMK the supplicant=20 > has no way=20 > > of knowing whether that AP is a valid, trusted AP or is an > attacker > > that has compromised another AP (or the AP <--> AS=20 > connection) and is=20 > > playing man-in-the-middle. > >=20 > > The reason this is so is because the supplicant never told the=20 > > authentication server to share the PMK with an entity=20 > identified by a=20 > > particular BSSID (and the authentication server does not maintain a=20 > > relationship with an entity identified by BSSID anyway),=20 > nor did the=20 > > AP provide some "ticket" to the supplicant proving that it=20 > is trusted=20 > > by the authentication server to know this secret. Either of which=20 > > would've made this exchange more secure. > >=20 > > Can you show me some deterministic way for a supplicant to > distinguish > > between these two: > >=20 > > 1. the AAA client (entity trusted by the AS) and radio (that > > entity identified by a BSSID that the client is=20 > speaking to) are > > different parts of the same device and within the same security > > boundary. > >=20 > > 2. the AAA client is on an AP that has been compromised by an > > attacker and the radio with which the supplicant is=20 > communicating > > is on the attacker. The attacker relays the EAP=20 > exchange through > > the compromised AP and obtains the PMK. > >=20 > > If not then I maintain that there is no less security by doing "PMK=20 > > sharing". You're including two things in a cryptographic boundary--=20 > > the AAA client and radio-- that are not cryptographically bound and=20 > > are asking the supplicant to make a leap of faith. I can just as=20 > > easily draw a different cryptographic boundary and ask the=20 > supplicant=20 > > to make an _identical_ leap of faith. You can't have it=20 > both ways, if=20 > > it's OK for the existing 3 party exchange then it's OK for "PMK=20 > > sharing". > >=20 > > Dan. > >=20 > > On Mon, 25 Oct 2004 15:44:13 PDT you wrote > > > Dan, > > >=20 > > > Let me go through this yet again. > > >=20 > > > In the 802.11i we discussion we said over and over and=20 > over and over=20 > > > again that the PMK must be kept within a single crypto boundary or > it > > is > > > compromised. > > >=20 > > > Now, if you have two classical APs, they represent=20 > separate crypto=20 > > > boundaries, because if you share a PMK between them and you > compromise > > > one AP, then the client's traffic is compromised at the=20 > other, while > > if > > > you don't share PMKs between them then compromise of one does not > lead > > > to compromise of the client's traffic at the other. > > >=20 > > > It follows from the crypto boundaries argument, that different > > classical > > > APs must be provisioned with independent PMKs. When this is not > done, > > > the client must treat its own PMK shared across different=20 > classical > > APs > > > as a violation of its (the client's) security policy, because PMK=20 > > > sharing explicitly violates the crypto boundaries principle. > > >=20 > > > Under 802.11, 802.11i, 802.1X, and EAP the client does not learn > > whether > > > an AP is a classical AP or a new switched AP such as what=20 > would be=20 > > > described by CAPWAP. The only thing 802.11 and 802.11i and 802.1X > and > > > EAP provide the client to distinguish one AP from another is the > AP's > > > BSSID. This means every AP looks like a classical AP to a client > using > > > the existing standardized 802.1, 802.11i, 802.1X, and EAP. > > >=20 > > > Since the client cannot tell a classical AP from a=20 > switched AP, it=20 > > > follows that a switched AP cannot share PMKs among its different=20 > > > light-weight APs, because doing so violates the client's security=20 > > > policy. That is, unless and until it receives evidence to the > > contrary, > > > the client must assume that it is communicating with a=20 > classical AP, > > and > > > PMK reuse between two classical APs violates its policy=20 > by violating > > the > > > crypto boundary principle. The reason why it must assume this is > that > > it > > > does not and cannot know the contrary, and security says=20 > the client > > must > > > make the most conservative assumption consistent with the facts > known > > to > > > it (performance, manageability, etc., might argue something else, > but > > we > > > are discussing security here). > > >=20 > > > I don't know what is not clear about this. > > >=20 > > > -- Jesse > > >=20 > > > -----Original Message----- > > > From: Dan Harkins [mailto:dharkins@trpz.com] > > > Sent: Monday, October 25, 2004 3:05 PM > > > To: Walker, Jesse > > > Cc: Yang, Lily L; capwap@frascone.com; housley@vigilsec.com > > > Subject: Re: FW: [Capwap] Important: please provide input=20 > on comment=20 > > > resolution for CAPWAP Taxonomy draft > > >=20 > > > Jesse, > > >=20 > > > You are not addressing any of the issues I raised in=20 > response to=20 > > > your previous demand for a deterministic algorithm, you're just=20 > > > repeating yourself. I was trying to point out how the security of=20 > > > the system is not lessened by the lack of such an=20 > algorithm. I asked=20 > > > you to show me where in that email I was wrong and how I=20 > was wrong.=20 > > > I even added some more analysis of what I think is the=20 > crux of the=20 > > > matter. You ignored it all. > > >=20 > > > Sigh, > > >=20 > > > Dan. > > >=20 > > > On Mon, 25 Oct 2004 14:28:16 PDT you wrote > > > > Dan, > > > >=20 > > > > I have already explained this, but will do so again out=20 > of common=20 > > > > courtesy. Please provide a deterministic algorithm by which a > client > > > > determines whether PMK sharing between AP1 and AP2 is acceptable > or > > > > represents a compromise, using information available to=20 > it under=20 > > > > 802.11i. If you produce such an algorithm, then I withdraw my > claim > > > and > > > > apologize. If you cannot, then my assertion stands. > > > >=20 > > > > -- Jesse > > > >=20 > > > > -----Original Message----- > > > > From: Dan Harkins [mailto:dharkins@trpz.com] > > > > Sent: Monday, October 25, 2004 1:56 PM > > > > To: Walker, Jesse > > > > Cc: Yang, Lily L; capwap@frascone.com; housley@vigilsec.com > > > > Subject: Re: FW: [Capwap] Important: please provide input on > comment > > > > resolution for CAPWAP Taxonomy draft > > > >=20 > > > > Jesse, > > > >=20 > > > > Common courtesy dictates that one should not merely state "you > are > > > > wrong" but to explain exactly where one is wrong. > > > >=20 > > > > Abstract language is getting in the way of my point so let me=20 > > > > just use common vernacular that is descriptive of what=20 > is deployed > > > > today: > > > >=20 > > > > If I can try to boil this down I think the residue we will be > left > > > > with is that you believe that there is a one-to-one=20 > relationship=20 > > > > between a RADIUS client and a BSSID that a supplicant speaks to > and > > > > that the identity of the RADIUS client and BSSID are > interchangable. > > > > It is that belief, I believe, that causes you to infer a binding > of > > > > PMK to BSSID when, strictly speaking, none exists. > > > >=20 > > > > The RADIUS server has a trust relationship with a=20 > RADIUS client. > > > > That RADIUS client is identified, to the RADIUS server,=20 > with an IP=20 > > > > address. You are assuming that that RADIUS client,=20 > identified by=20 > > > > its IP address, has one and only one BSSID. This is incorrect. > > > > Furthermore you are assuming that this 3 way protocol=20 > between the=20 > > > > supplicant, the RADIUS server, and the RADIUS client is=20 > 1) secure;=20 > > > > and 2) extensible to a different identity of the RADIUS=20 > client, a=20 > > > > BSSID, without loss of security. > > > >=20 > > > > Feel free to tell me I'm wrong again, but please tell=20 > me where=20 > > > > and how. > > > >=20 > > > > Dan. > > > >=20 > > > > On Mon, 25 Oct 2004 13:03:24 PDT you wrote > > > > > Dan, > > > > >=20 > > > > > You are wrong. The problem is there is no > Needham-Shroeder-eseque > > > > > protocol in the back end. > > > > >=20 > > > > > -- Jesse > > > > >=20 > > > > > -----Original Message----- > > > > > From: Dan Harkins [mailto:dharkins@trpz.com] > > > > > Sent: Monday, October 25, 2004 12:58 PM > > > > > To: Yang, Lily L > > > > > Cc: capwap@frascone.com; Walker, Jesse; housley@vigilsec.com > > > > > Subject: Re: FW: [Capwap] Important: please provide input on > > comment > > > > > resolution for CAPWAP Taxonomy draft > > > > >=20 > > > > > I beg to differ. > > > > >=20 > > > > > If this was a Needham-Schroeder-esqe protocol Jesse=20 > might have > a > > > > > point. But it's not. > > > > >=20 > > > > > There is no way for a "properly implemented" client to know > that > > > the > > > > > AP it is speaking to is trusted by the authentication server > since > > > > > nothing in the exchange that derives the PMK includes anything > > about > > > > > the AP. It's merely a man-in-the-middle. The AP=20 > proves knowledge > > of > > > > the > > > > > PMK so the client is just supposed to assume it's=20 > trusted! What > is > > > > being > > > > > asked here is just ignore that > > unpleasant > > > > > security issue and believe we > have > > a > > > > > secure > > > > > 3-party authenticaiton system here so that we can=20 > then condemn a > > > > scheme > > > > > that suffers from that same unpleasant security issue. > > > > >=20 > > > > > How does a "properly implemented" client know that=20 > AP2 is not > a > > > > > attacker which compromised AP1? By the same technique that it > used > > > > > to know that AP1 was not an attacker which compromised the > authen- > > > > > tication server (or the link between the authentication server > and > > a > > > > > legitimate authenticator). Since a "properly=20 > implemented" client > > can > > > > > do the latter it can take the same steps to do the former. > > > > >=20 > > > > > If mere proof of possession of the PMK is enough to=20 > legitimize > > AP1 > > > > > to the client then mere proof of possession of the=20 > PMK is enough > > to > > > > > legitimize AP2 to the client. You cannot reasonably claim > > otherwise. > > > > >=20 > > > > > This is not to say that Jesse's suggestions of (a) or (b) > below > > > > > are not needed, I would welcome either of those. I would also > like > > > > > to note that Jesse's mention of (c) is an explicit > acknowledgment > > > > > that "PMK sharing" is permitted by the existing specification. > > > > >=20 > > > > > Dan. > > > > >=20 > > > > > On Mon, 25 Oct 2004 09:33:05 PDT you wrote > > > > > > I solicited input from Jesse Walker and Russ Housley on the > > issue > > > of > > > > > PMK > > > > > > sharing, and here is the response from Jesse. He=20 > agrees to let > > me > > > > > > forward this to the CAPWAP list. I also cc Jesse and Russ > here. > > > > Since > > > > > > Russ posted the original comment in IESG review,=20 > and Jesse is > > the > > > > > > technical editor of 11i, I think it would be good=20 > that we keep > > > them > > > > in > > > > > > the loop with regard this discussion. So please cc them in > your > > > > email > > > > > > posting on this issue as they are not in the CAPWAP list. > > > > > >=20 > > > > > > -----Original Message----- > > > > > > From: Walker, Jesse > > > > > > Sent: Saturday, October 23, 2004 7:05 PM > > > > > > To: Yang, Lily L; 'housley@vigilsec.com' > > > > > > Subject: RE: [Capwap] Important: please provide input on > comment > > > > > > resolution for CAPWAP Taxonomy draft > > > > > >=20 > > > > > > Lily, > > > > > >=20 > > > > > > Dan's reasoning is invalid, unless he or someone else can > > produce > > > a > > > > > > deterministic algorithm that allows the client to=20 > distinguish > > the > > > > > > following two cases: > > > > > >=20 > > > > > > Case 1: AP1 and AP2 are classical access points. An attacker > > > > > compromises > > > > > > AP1 and AP2 and moves the client's PMK from AP1 and AP2. > > > > > >=20 > > > > > > Case 2: AP1 and AP2 are two light-weight access points that > are > > > part > > > > > of > > > > > > the same switch S. The switch S uses the same PMK with both > AP1 > > > and > > > > > AP2. > > > > > >=20 > > > > > > If no one can demonstrate a deterministic algorithm=20 > the client > > can > > > > use > > > > > > to distinguish the two cases, then a properly implemented > client > > > > will > > > > > > always assume its PMK has been compromised when it=20 > sees either > > > case. > > > > I > > > > > > suspect no one can, because the client lacks the necessary > > state. > > > > > >=20 > > > > > > It appears to me there are three possible solutions: > > > > > >=20 > > > > > > a. The first is the necessary state is somehow delivered to > the > > > > client > > > > > > in an attestable fashion. The only party that=20 > client trusts is > > the > > > > AAA > > > > > > server, so this implies a new binding protocol=20 > between the AAA > > > > server > > > > > > and the EAP Peer. > > > > >=20 > > > > > > b. The second is to define a new protocol that delivers the > AP's > > > > > > authenticated identifier to the EAP Peer in an attestable > > fashion, > > > > and > > > > > > to change the 802.11i key confirmation handshake to use this > > > > > identifier > > > > > > instead of the BSSID of the APs. > > > > > >=20 > > > > > > c. The text that permits this usage should be removed. > > > > > >=20 > > > > > > I believe possibilities (a) or (b) are the right way to > address > > > this > > > > > > issue. > > > > > >=20 > > > > > > -- Jesse > > > > > >=20 > > > > > > -----Original Message----- > > > > > > From: Yang, Lily L > > > > > > Sent: Friday, October 22, 2004 12:03 PM > > > > > > To: Walker, Jesse; housley@vigilsec.com > > > > > > Subject: FW: [Capwap] Important: please provide input on > comment > > > > > > resolution for CAPWAP Taxonomy draft > > > > > > Importance: High > > > > > >=20 > > > > > > Jesse and Russ -- > > > > > >=20 > > > > > > CAPWAP WG has had some email discussion regarding=20 > the comment > > from > > > > you > > > > > > on PMK sharing. I don't think either of you are on the list, > so > > I > > > am > > > > > > forwarding to you this and I would like to hear=20 > what you think > > > about > > > > > > these responses.=20 > > > > > >=20 > > > > > > Lily > > > > > >=20 > > > > > > -----Original Message----- > > > > > > From: capwap-admin@frascone.com > > [mailto:capwap-admin@frascone.com] > > > > On > > > > > > Behalf Of Dan Harkins > > > > > > Sent: Thursday, October 21, 2004 9:47 AM > > > > > > To: Chunduru Rama Krishna Prasad > > > > > > Cc: capwap@frascone.com > > > > > > Subject: Re: [Capwap] Important: please provide input on > comment > > > > > > resolution for CAPWAP Taxonomy draft > > > > > >=20 > > > > > > Strictly speaking the PMK is shared between the supplicant > and > > > the > > > > > > authentication server, not the authenticator. There=20 > are no MAC > > > > > addresses > > > > > > bound to the PMK or used in the derivation of the PMK. > > > > > >=20 > > > > > > As the person who got PMK caching and PMKIDs into the > 802.11i > > > > draft > > > > > > let me explain the steps we went through: > > > > > >=20 > > > > > > - first motion was to indicate the ability of a STA to do > "PMK > > > > > > caching" > > > > > > in an associate request. If the authenticator=20 > had a cached > > PMK > > > > for > > > > > > the STA it would respond with the 1st message=20 > of the 4way > > > > > handshake, > > > > > > otherwise it would respond with an 802.1x=20 > encapsulated EAP > > > > > Identity > > > > > > request. That enabled the functionality you describe > below-- > > > > "the > > > > > > station is reassociating with an AP to with it already > > > > established > > > > > > the PMK before..." It prevented a STA in a difficult RF > > > > > environment > > > > > > from ping-ponging back and forth between APs=20 > and hammering > > an > > > > > > authentication server. > > > > > >=20 > > > > > > - it soon became apparent that an authenticator may have > > > multiple > > > > > PMKs > > > > > > for a particular STA in its cache. How? Via=20 > something like > a > > > > > > pro-active > > > > > > key pushing mechanism using neighbor graphs=20 > (Bill Arbaugh > > > > > presented > > > > > > this idea). So the next motion was to name PMKs with a > PMKID > > > to > > > > > > indicate which PMK a STA is asserting in its associate > > > request. > > > > > > This eliminated the ambiguity. > > > > > >=20 > > > > > > So the very reason that we have PMKIDs, and not just blind > > > > assertions > > > > > of > > > > > > a cached PMK, is because the PMK may be used to derive a PTK > for > >=20 > > > > > > multiple APs. The statement "If PMK is shared=20 > across multiple > > > WTPs" > > > > > is, > > > > > > indeed, valid. > > > > > >=20 > > > > > > Addressing Russ's comment, the PMK is already=20 > leaked because > > it > > > is > > > > > > given to the authenticator by the authentication=20 > server. When > > > > > discussing > > > > > "the number of other people who know my secret" there are 3 > > possible > > > > > > values: 0, 1 and infinity. If 0 other people know=20 > your secret > > > there > > > > > are > > > > > > certain cryptographic properties associated with that state. > If > > 1 > > > > > other > > > > > > person knows your secret there are other cryptographic > > properties > > > > > > associated with that state (message source=20 > authentication for > > > > > instance), > > > > > > but if more than 1 person knows your secret then it doesn't > > matter > > > > if > > > > > > it's 2 or 22, the cryptographic properties are the=20 > same (it is > > > > > possible > > > > > > for someone to impersonate you, forge your=20 > messages, read your=20 > > > > > > messages, etc). > > > > > >=20 > > > > > > Of course you can say that in the 802.11i case the > > authenticator > > > > is > > > > > > "trusted" and therefore it's OK for the=20 > authentication server > to > > > > leak > > > > > > the secret to the authenticator (and have 3 people know the > > > secret). > > > > > > OK, fine. The other AP is also "trusted" to have the PMK so > now > > 4 > > > > > people > > > > > > know the secret (or 5 "trusted" people or 10 "trusted" > people). > > > > > Nothing > > > > > > changed. > > > > > >=20 > > > > > > In the case of a switch hosting multiple APs the switch is > the > > > > > > authenticator and the APs are merely tentacles of the same > > > octopus. > > > > > The > > > > > > PMK isn't shared among the APs, it resides on the switch. > There > > is > > > > > even > > > > > > one company I know of (I won't name it but it shouldn't be > > > difficult > > > > to > > > > > > guess) in which the switch plays the role of the > authentication > > > > server > > > > > > so the PMK is known only by the switch and the STA.=20 > This "PMK > > > > sharing" > > > > > > situation is even MORE secure than the traditional=20 > deployment > > > where > > > > a > > > > > > STA > > > > > > establishes a PMK with a RADIUS server and that PMK=20 > is leaked > to > > > an > > > > > AP. > > > > > >=20 > > > > > > Dan. > > > > > >=20 > > > > > > On Thu, 21 Oct 2004 14:56:37 +0530 you wrote > > > > > > > hi all, > > > > > > >=20 > > > > > > > I am not sure, I am right on this. My impression is that, > PMK > > is > > > > on > > > > > > per > > > > > > > Authenticator MAC address. > > > > > > > If the station is re-associated with new WTP=20 > (different MAC > > > > > address), > > > > > > then > > > > > > > it would not even send > > > > > > > PMKID of old AP. If there is no PMKID found in reassoc > event, > > AC > > > > > would > > > > > >=20 > > > > > > > start with full 802.1x > > > > > > > authentication. If the station is reassociating=20 > with an AP, > to > > > > which > > > > > > it > > > > > > > already established PMK before, then station=20 > sends PMKID and=20 > > > > > > > in that case only 4 way key > > > handshake > > > > > is > > > > > > > requried to get the PTK. > > > > > > > With respect to this, I am not sure whether the statement=20 > > > > > > > 'If PMK is shared across multiple WTP' is valid.=20 > If not, the > > > whole > > > >=20 > > > > > > > statement can be removed > > > > > > > from the draft > > > > > > >=20 > > > > > > > Regards > > > > > > > Rama Krishna Prasad > > > > > > >=20 > > > > > > >=20 > > > > > > >=20 > > > > > > > Ch. Rama Krishna Prasad > > > > > > > Intoto Software(I) Pvt Ltd, > > > > > > > Uma Plaza, Nagarjuna circle, Panjagutta.=20 > Hyderabad, AP Tel=20 > > > > > > > No:s 2335 8927/8928/8434 > > > > > > >=20 > > > > > > > _______________________________________________ > > > > > > > Capwap mailing list > > > > > > > Capwap@frascone.com > > > > > > > http://mail.frascone.com/mailman/listinfo/capwap > > > > > > _______________________________________________ > > > > > > Capwap mailing list > > > > > > Capwap@frascone.com > > > > > > http://mail.frascone.com/mailman/listinfo/capwap > > > > > > _______________________________________________ > > > > > > Capwap mailing list > > > > > > Capwap@frascone.com > > > > > > http://mail.frascone.com/mailman/listinfo/capwap > > > > > >=20 > > > > >=20 > > > >=20 > > >=20 > >=20 > _______________________________________________ > Capwap mailing list > Capwap@frascone.com > http://mail.frascone.com/mailman/listinfo/capwap >=20 _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Thu Oct 28 13:11:08 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22058 for ; Thu, 28 Oct 2004 13:11:08 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id F41C81FD4A; Thu, 28 Oct 2004 13:11:08 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 395371FD4C; Thu, 28 Oct 2004 13:11:05 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 2C8131FD4C for ; Thu, 28 Oct 2004 13:10:50 -0400 (EDT) Received: from ihemail2.lucent.com (ihemail2.lucent.com [192.11.222.163]) by mail.frascone.com (Postfix) with ESMTP id 6203D1FD4A for ; Thu, 28 Oct 2004 13:10:47 -0400 (EDT) Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by ihemail2.lucent.com (8.12.11/8.12.11) with ESMTP id i9SHAjWF013932 for ; Thu, 28 Oct 2004 12:10:45 -0500 (CDT) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2657.72) id <4M32LL6H>; Thu, 28 Oct 2004 19:10:44 +0200 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B15503C79E41@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: "Capwap (E-mail)" MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="UTF-8" X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [Capwap] CAPWAP Re-Charter approved Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Thu, 28 Oct 2004 19:10:43 +0200 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) The re-charter has been approved by IESG. The formal announcement will follow from the IESG secretariat in the next few days. Bert _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap