Subject: [Capwap] draft-ietf-capwap-arch-05.txt ready for WG Last Call

From: "Yang, Lily L" <[email-masked]>
Date: Fri, 27 Aug 2004 14:53:36 -0700

Hi, all 

We now have v05 of the CAPWAP Architecture Taxonomy draft submitted to
the IETF repository. I believe this revision incorporated ALL the
comments we received from IEEE and IETF. A detailed change log can be
found below.
Among all the people who helped to pull this revision together, I want
to especially thank Inderpreet who spent time and effort to resolve
comments on the security section, which is the main reason for this
revision.

Chairs: I think we are ready for WG Last Call on this document. 

Thank you all,
Lily

---------  Change log from v04 to v05 --------

1) 4.8.1:"Client Data Security"
[change reason]First paragrah is expanded into 3 paragraphs to discuss
the two different cases in more details.
[old] 
The survey shows clearly that the termination point for "over the air"
802.11 encryption (802.11i) can be implemented either in the WTP or in
the AC. Furthermore, the 802.1x/EAP functionality is also distributed
between the WTP and the AC where, in almost all cases, the AC performs
the necessary functions as the authenticator in the 802.1x exchange. If
the encryption is done at the WTPs, the resultant cryptographic keys for
the session are required to be securely pushed from the AC to the WTP.
Since this keying material is part of the control and provisioning of
the WTPs, a secure encrypted tunnel for control frames is employed to
transport the keying material. In the case where the 802.11i
encryption/decryption is performed in the AC, the authentication and key
management is also fully performed in the AC. 
[new]
   The survey shows clearly that the termination point for "over the
   air" 802.11 encryption [5] can be implemented either in the WTP or in
   the AC.  Furthermore, the 802.1X/EAP [7] functionality is also
   distributed between the WTP and the AC where, in almost all cases,
   the AC performs the necessary functions as the authenticator in the
   802.1x exchange.

   If the STA and AC are the parties in the 4-way handshake (defined in
   [5]), and the encryption/decryption happens at the WTP, then the PTK
   (Pairwise Transient Key) has to be transferred from the AC to the
   WTP.  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.
   Since the keying material is part of the control and provisioning of
   the WTPs, a secure encrypted tunnel for control frames is employed to
   transport the keying material.

   In the case where the 802.11i encryption/decryption is performed in
   the AC, the key exchange and state transitions occur between the AC
   and STA.  Therefore, there is no need to transfer any crypto material
   between the AC and the WTP.

2)  4.8.2 "Security of control channel between WTP and AC"
[change reason] security state should also be included.
[old] "Secure management of WTPs and ACs, including mechanisms for
securely setting and resetting secrets."
[new]"Secure management of WTPs and ACs, including mechanisms for
securely setting and resetting secrets and state".

3) A new subsection is added to address the physical security issue more
explicitly:
[new addition] 4.8.3 "Physical Security of WTPs and Acs" 

   In order to provide comprehensive radio coverage, WTPs are often
   installed in locations that are difficult to secure physically; while
   it is relatively easier to secure the AC physically.  If high-value
   secrets, such as a RADIUS shared secret, are stored in the AC instead
   of WTPs, then the physical loss of an WTP does not compromise these
   secrets.  Hence, the Centralized Architecture may reduce the security
   consequences of a stolen WTP.

   On the other hand, concentrating all of the high-value secrets in one
   place makes the AC an attractive target, so strict physical,
   procedural and technical controls are needed to protect the secrets.

4) 5.1 - include integrity and replay protection.
[old] "It is often recommended that all communication between mesh nodes
be encrypted, since they may carry user traffic that is not. For this
reason, the operator should always encrypt mesh links, in order to fully
secure the network."
[new] "It is often recommended that all communication between mesh nodes
be secured by some mechanism of confidentiality, integrity and replay
protection, since they may carry user traffic that is not. For this
reason, the operator should always encrypt and protect mesh links, in
order to fully secure the network."

5) Reorgnanization of Section 5: structure the existing content into two
subsections:
5.1  "Common Characteristics"
and
5.2  "Security".
The content basically stays the same, except that integrity and replay
protection is more explicitly called out in the security subsection.

6) 7 "Security Considerations"
[change reason] add a discussion of replay. 
[old] "need to be securely transported from AC to WTP; secure discovery
of WTP and AC is required, mutual authentication of WTPs and AC is
needed, man-in-the-middle attacks to the control channel between WTP and
AC, confidentiality and integrity of control channel frames, and theft
of WTPs for extraction of embedded secrets within."

[new] "need to be securely transported from AC to WTP; secure discovery
of WTP and AC is required, mutual authentication of WTPs and AC is
needed, man-in-the-middle attacks to the control channel between WTP and
AC, confidentiality, integrity and replay protection of control channel
frames, and theft of WTPs for extraction of embedded secrets within."

---------- end of v05 change log ----------------------

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of 
> [email-masked]
> Sent: Friday, August 27, 2004 12:42 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject: [Capwap] I-D ACTION:draft-ietf-capwap-arch-05.txt
> 
> A New Internet-Draft is available from the on-line 
> Internet-Drafts directories.
> This draft is a work item of the Control And Provisioning of 
> Wireless Access Points Working Group of the IETF.
> 
> 	Title		: Architecture Taxonomy for Control and 
> Provisioning of 
> 			  Wireless Access Points(CAPWAP)
> 	Author(s)	: L. Yang, et al.
> 	Filename	: draft-ietf-capwap-arch-05.txt
> 	Pages		: 42
> 	Date		: 2004-8-27
> 	
> This document provides a taxonomy of the architectures employed in
>    the existing IEEE 802.11 products in the market, by analyzing WLAN
>    (Wireless LAN) functions and services and describing the different
>    variants in distributing these functions and services among the
>    architectural entities.
> 
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-capwap-arch-05.txt
> 
> To remove yourself from the I-D Announcement list, send a 
> message to [email-masked] 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-ietf-capwap-arch-05.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:
> 	[email-masked].
> In the body type:
> 	"FILE /internet-drafts/draft-ietf-capwap-arch-05.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.
> 
_______________________________________________
Capwap mailing list
[email-masked]
http://mail.frascone.com/mailman/listinfo/capwap