Re: Issue 199: EAPoL-Key message generation at WTP or AC
From: Bob O'Hara (boohara) (booharacisco.com)
Date: Tue, 5 Sep 2006 08:24:46 -0700 (PDT)
 
Saranavan,

EAPOL-key message generation is not a cryptographic function.  As is
very clear, if you understand how the EAPOL-key message and the KeyRSC
are used in 802.11i, it is not necessary to implement the proposal you
requested between AC and WTP, regardless of where the cryptographic
functions reside.  Therefore, the objective is met by the currently
defined protocol.

 -Bob
 
-----Original Message-----
From: Saravanan Govindan [mailto:Saravanan.Govindan [at] sg.panasonic.com] 
Sent: Monday, September 04, 2006 11:02 PM
To: Bob O'Hara (boohara); Capwap [at] frascone.com
Subject: RE: [Capwap] Issue 199: EAPoL-Key message generation at WTP or
AC

Bob,

The objective for this issue addresses designs where the 802.11i
authenticator is located at the AC and cryptographic functions are on
the WTP. This is made very clear in the requirement. 

What the protocol currently needs is a way to specify prevailing KeyRSC
information (maintained by the WTP) to EAPoL messages (generated by the
AC). The proposal so far is to let the AC send EAPoL messages (with
unassigned KeyRSC field) to the WTP. Then the WTP assigns the prevailing
KeyRSC and forwards to the wireless station. 

The objective and corresponding proposal are very clear. 

Saravanan


 



-----Original Message-----
From: Bob O'Hara (boohara) [mailto:boohara [at] cisco.com] 
Sent: Tuesday, September 05, 2006 1:51 AM
To: Capwap [at] frascone.com
Subject: Re: [Capwap] Issue 199: EAPoL-Key message generation at WTP or
AC

Saranavan,

The current protocol, as it is specified in -02, does meet the stated
objectives.  It supports both local MAC and split MAC architectures, as
those architectures are described in the taxonomy document.  

There is no requirement in the objectives that the protocol support any
other arbitrary split of functionality between the AC and WTP.
Otherwise, we would have to negotiate EVERY possible frame that might be
exchanged between a mobile node and the 802.11 access point, to
determine if it is generated in the AC or the WTP.  For example, do the
objectives require that the protocol must support the Association
Request being processed in the AC and the Association Response being
generated in the WTP for a split MAC architecture?

 -Bob
 
-----Original Message-----
From: Saravanan Govindan [mailto:Saravanan.Govindan [at] sg.panasonic.com] 
Sent: Sunday, September 03, 2006 7:01 PM
To: Pat Calhoun (pacalhou); Capwap [at] frascone.com
Subject: Re: [Capwap] Issue 199: EAPoL-Key message generation at WTP or
AC

Pat,

This is not a new functionality, but one that is mandatory by the
Objectives. 

Also, I do not think this is an issue of where the EAPoL-Key is
generated, but rather "how" EAPoL messages are exchanged in local-MAC
and split-MAC architectures. 

I have made a number of proposals with both text and figures that direct
address the mandatory objective. 

I am not comfortable with a protocol that does not support explicitly
stated objectives. 

Saravanan




-----Original Message-----
From: Pat Calhoun (pacalhou) [mailto:pcalhoun [at] cisco.com] 
Sent: Friday, September 01, 2006 7:32 AM
To: Capwap [at] frascone.com
Subject: [Capwap] Issue 199: EAPoL-Key message generation at WTP or AC

This issue was opened to add a new mode of operation to the CAPWAP
protocol, allowing the WTP to generate the EAPOL messages. I do not
agree with this request, and would like to see this one rejected. We
really need to focus on getting a protocol completed, and I just don't
see a burning need to add this new functionality. 
 

Pat Calhoun
CTO, Wireless Networking Business Unit
Cisco Systems
_________________________________________________________________
To unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/capwap

Archives: http://lists.frascone.com/pipermail/capwap

_________________________________________________________________
To unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/capwap

Archives: http://lists.frascone.com/pipermail/capwap
_________________________________________________________________
To unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/capwap

Archives: http://lists.frascone.com/pipermail/capwap

Results generated by Tiger Technologies using MHonArc.