Subject: [Capwap] IESG Review - Update

From: "Saravanan Govindan" <[email-masked]>
Date: Mon, 6 Mar 2006 16:03:22 +0800

Hi All,

Based on feedback from the Chairs, this is an update to the responses
for the IESG review. Your comments/acceptance would be much appreciated.

Cheers,

Saravanan

 

Brian Carpenter's Review:

1. Section: 5.1.8 CAPWAP Protocol Security, Protocol Requirement

Comment: 

"Does that [secured] mean encrypted or integrity-protected?"

Original text: 

"The CAPWAP protocol MUST support mutual authentication of WTPs and the
centralized controller.  It must also ensure that information exchanges
between them are secured."

Suggested new text: From Charles Clancy - 

"The CAPWAP protocol MUST support mutual authentication of WTPs and the
centralized controller. It also MUST ensure that information exchanges
are integrity protected, and SHOULD ensure confidentiality through
encryption."

--XX--

2. Section: 5.1.9 System-wide Security, Protocol Requirement

Comment: 

"Strange phrasing" of requirement

Original text:
 "The design of the CAPWAP protocol MUST NOT allow for any compromises
to the WLAN system by external entities."

Suggested new text: 

No new text is suggested. Clarification on the requirement is provided
below.

Clarification: From Mani - 

The intent [of the requirement] was to emphasize that the protocol MUST
not introduce additional threats weakening the security of WLAN system.
CAPWAP protocol by itself is not intended to and cannot protect against
all compromises to the WLAN system which is broader than the scope of
the protocol.

--XX-

3. Section: 5.1.12 Protocol Specifications

Comment: 

"Since this is a basic requirement of all IETF standards, why is it
listed?"

Original text: 
"Any WTP or WLAN controller vendor or any person MUST be able to
implement the CAPWAP protocol from the specification itself and by that
it is required that all such implementations do interoperate."

Suggested new text: 

No new text is suggested. Clarification on the need for this objective
is provided below.

Clarification: 
This objective arose during discussions on the scope of the CAPWAP
protocol in managing WLAN systems. The intent was to highlight the
'completeness' of protocol in terms of achieving its interoperability
goals.
--XX-

4. Section: 5.2 Desirable Objectives
 
Comment: 
"Why aren't the items in this section listed as SHOULD instead of MUST?"
 
Original text:
Protocol Requirements for all objectives categorized as Desirable
Objectives include those in subsections 5.2.1 through 5.2.5. 

Suggested new text: 

No new text is suggested. Clarification on the need for this objective
is provided below.

Clarification: 
The Desirable Objectives as a category can be listed as 'SHOULD'.
However, the individual objectives that make up the category are still
'MUST', because they represent mandatory operations for the protocol -
provided that the protocol chooses to realize a Desirable Objective.
--XX-

Sam Hartman's Review

5. Section: 5.1.8 CAPWAP Protocol Security, Description
 
Comment: 
"Section 5.1.8 implies that an authenticated key exchange is optional. I
think that BCP 107 will require an authenticated key exchange for this
protocol."
 
Original text: (Last paragraph of Description)
"CAPWAP MUST NOT prevent the use of asymmetric authentication. The
security considerations of such asymmetric authentication are described
in the Security Considerations section."
 
Suggested new text: From Charles Clancy [To be inserted after
above-paragraph of original text] - 
"If the CAPWAP protocol meets the criteria to require automated key
management per BCP 107, then mutual authentication MUST be accomplished
via an authenticated key exchange."
 
Suggested new text: 
Add reference to BCP 107.
--XX-

6. Section: 5.1.8 CAPWAP Protocol Security, Description, Paragraph 5
 
Comment: 
In the following text, please describe what security services are meant;
probable services include integrity and confidentiality.
 
> Once WTPs and WLAN controller have been mutually authenticated,
information exchanges between them
> must be secured against various security threats.
 
Original text:
Once WTPs and WLAN controller have been mutually authenticated,
information exchanges between them must be secured against various
security threats.
 
Suggested text: From Charles Clancy- 
"Once WTPs and WLAN controller have been mutually authenticated,
information exchanges between them must be secured against various
security threats. So the CAPWAP protocol MUST provide
integrity-protection and replay-protection. The protocol SHOULD provide
confidentiality through encryption."
--XX-

7. Section: 5 Objectives, Introduction
 
Comment: 
"The introduction to section 5 implies that operator requirements are
valued less than non-objectives.  I don't think that is the message the
IETF wants to send to the operator community."
 
Original text:
"The objectives described in this document have been prioritized based
on their immediate significance in the development and evaluation of a
control and provisioning protocol for large-scale WLAN deployments.
Additionally, one category is provided for requirements gathered from
network service operators.  These are specific need that arise from
operators' experiencese in deploying and managing large-scale WLANs. The
priorities are;
 
   i.  Mandatory and Accepted Objectives
   ii.  Desirable Objectives
   iii.  Non-Objectives
   iv.  Operator Requirements
 
The priorities have been assigned to individual objectives in accordance
with working group discussions."

Suggested new text: 
"The objectives described in this document have been prioritized based
on their immediate significance in the development and evaluation of a
control and provisioning protocol for large-scale WLAN deployments.
 
The priorities are;
 
i.  Mandatory and Accepted Objectives
ii.  Desirable Objectives
iii.  Non-Objectives
 
The priorities have been assigned to individual objectives in accordance
with working group discussions.
 
Furthermore, a distinct category of objectives is provided based on
requirements gathered from network service operators.  These are
specific needs that arise from operators' experiences in deploying and
managing large-scale WLANs.
 
a. Operator Requirements"

--XX-

 

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

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

---

From: "Wijnen, Bert (Bert)" <[email-masked]>
Date: Tue, 14 Mar 2006 13:26:54 +0100

As a result of the below, I have now recorded the following "Notes to RFC-Editor"
 
Note to RFC Editor
 
- Please clarify section 5 on page 8.
  OLD:
   The objectives described in this document have been prioritized based
   on their immediate significance in the development and evaluation of
   a control and provisioning protocol for large-scale WLAN deployments.
   Additionally, one category is provided for requirements gathered from
   network service operators.  These are specific need that arise from
   operators' experiencese in deploying and managing large-scale WLANs.
   The priorities are;

   The priorities have been assigned to individual objectives in
   accordance with working group discussions.
 
  NEW:
 
   The objectives described in this document have been prioritized based
   on their immediate significance in the development and evaluation of
   a control and provisioning protocol for large-scale WLAN deployments.
   The priorities are;

   The priorities have been assigned to individual objectives in
   accordance with working group discussions.
 
   Furthermore, a distinct category of objectives is provided based on
   requirements gathered from network service operators.  These are
   specific needs that arise from operators' experiences in deploying
   and managing large-scale WLANs.
 
   a. Operator Requirements
 
- Pls add some text in Section 5.1.8, in the 4th para on page 15
  OLD:
  Once WTPs and WLAN controller have been mutually authenticated,
  information exchanges between them must be secured against various
  security threats.  This should cover illegitimate modifications to
  ...
  NEW:
  Once WTPs and WLAN controller have been mutually authenticated,
  information exchanges between them must be secured against various
  security threats.  So the CAPWAP protocol MUST provide
  integrity-protection and replay-protection. The protocol SHOULD
  provide confidentiality through encryption.  This should cover
  illegitimate modifications to
  ...
- Pls insert a para in Section: 5.1.8, after last para on page 15
  OLD:
   CAPWAP MUST NOT prevent the use of asymmetric authentication.  The
   security considerations of such asymmetric authentication are
   described in the Security Considerations section.
  NEW:
   CAPWAP MUST NOT prevent the use of asymmetric authentication.  The
   security considerations of such asymmetric authentication are
   described in the Security Considerations section.
 
   If the CAPWAP protocol meets the criteria to require automated key
   management per BCP 107, then mutual authentication MUST be
   accomplished via an authenticated key exchange.
 
- Pls fix in Section: 5.1.8, first para on page 16
  OLD:
   The CAPWAP protocol MUST support mutual authentication of WTPs and
   the centralized controller.  It must also ensure that information
   exchanges between them are secured.
  NEW:
   The CAPWAP protocol MUST support mutual authentication of WTPs and
   the centralized controller. It also MUST ensure that information
   exchanges are integrity protected, and SHOULD ensure confidentiality
   through encryption."

- Please list all refrences as Normative.
  OLD:
  9.  References
 
   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.
 
   [RFC3990]  O'Hara, B., Calhoun, P., and J. Kempf, "Configuration and
              Provisioning for Wireless Access Points (CAPWAP) Problem
              Statement", RFC 3990, February 2005.
 
   [RFC4118]  Yang, L., Zerfos, P., and E. Sadot, "Architecture Taxonomy
              for Control and Provisioning of Wireless Access Points
              (CAPWAP)", RFC 4118, June 2005.
 
  NEW:
  9. Normative References
 
   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.
 
   [RFC3990]  O'Hara, B., Calhoun, P., and J. Kempf, "Configuration and
              Provisioning for Wireless Access Points (CAPWAP) Problem
              Statement", RFC 3990, February 2005.
 
   [RFC4118]  Yang, L., Zerfos, P., and E. Sadot, "Architecture Taxonomy
              for Control and Provisioning of Wireless Access Points
              (CAPWAP)", RFC 4118, June 2005.

Bert

-----Original Message-----
From: Saravanan Govindan [mailto:[email-masked]]
Sent: Monday, March 06, 2006 09:03
To: [email-masked]
Cc: [email-masked]; Mani, Mahalingam (Mani); [email-masked]; [email-masked]; [email-masked]; [email-masked]; Cheng Hong
Subject: IESG Review - Update

Hi All,

Based on feedback from the Chairs, this is an update to the responses for the IESG review. Your comments/acceptance would be much appreciated.

Cheers,

Saravanan

 

Comment: 

Original text: 

"The CAPWAP protocol MUST support mutual authentication of WTPs and the centralized controller.  It must also ensure that information exchanges between them are secured."

"The CAPWAP protocol MUST support mutual authentication of WTPs and the centralized controller. It also MUST ensure that information exchanges are integrity protected, and SHOULD ensure confidentiality through encryption."

--XX--

Comment: 

Original text:
 "The design of the CAPWAP protocol MUST NOT allow for any compromises to the WLAN system by external entities."

Suggested new text: 

No new text is suggested. Clarification on the requirement is provided below.

The intent [of the requirement] was to emphasize that the protocol MUST not introduce additional threats weakening the security of WLAN system. CAPWAP protocol by itself is not intended to and cannot protect against all compromises to the WLAN system which is broader than the scope of the protocol.

--XX-

Comment: 

"Since this is a basic requirement of all IETF standards, why is it listed?"

Original text: 
"Any WTP or WLAN controller vendor or any person MUST be able to implement the CAPWAP protocol from the specification itself and by that it is required that all such implementations do interoperate."

Suggested new text: 

No new text is suggested. Clarification on the need for this objective is provided below.

Clarification: 
This objective arose during discussions on the scope of the CAPWAP protocol in managing WLAN systems. The intent was to highlight the 'completeness' of protocol in terms of achieving its interoperability goals.
--XX-

Comment: 
 
Original text:
Protocol Requirements for all objectives categorized as Desirable Objectives include those in subsections 5.2.1 through 5.2.5. 

Suggested new text: 

No new text is suggested. Clarification on the need for this objective is provided below.

Clarification: 
The Desirable Objectives as a category can be listed as 'SHOULD'. However, the individual objectives that make up the category are still 'MUST', because they represent mandatory operations for the protocol - provided that the protocol chooses to realize a Desirable Objective.
--XX-

Sam Hartman's Review

Comment: 
"Section 5.1.8 implies that an authenticated key exchange is optional. I think that BCP 107 will require an authenticated key exchange for this protocol."
 
Original text: (Last paragraph of Description)
"CAPWAP MUST NOT prevent the use of asymmetric authentication. The security considerations of such asymmetric authentication are described in the Security Considerations section."
 
Suggested new text: From Charles Clancy [To be inserted after above-paragraph of original text] - 
"If the CAPWAP protocol meets the criteria to require automated key management per BCP 107, then mutual authentication MUST be accomplished via an authenticated key exchange."
 
Suggested new text: 

Comment: 
In the following text, please describe what security services are meant; probable services include integrity and confidentiality.
 
> Once WTPs and WLAN controller have been mutually authenticated, information exchanges between them
 
Original text:
Once WTPs and WLAN controller have been mutually authenticated, information exchanges between them must be secured against various security threats.
 
Suggested text: From Charles Clancy- 
"Once WTPs and WLAN controller have been mutually authenticated, information exchanges between them must be secured against various security threats. So the CAPWAP protocol MUST provide integrity-protection and replay-protection. The protocol SHOULD provide confidentiality through encryption."
--XX-

Comment: 
"The introduction to section 5 implies that operator requirements are valued less than non-objectives.  I don't think that is the message the IETF wants to send to the operator community."
 
Original text:
"The objectives described in this document have been prioritized based on their immediate significance in the development and evaluation of a control and provisioning protocol for large-scale WLAN deployments. Additionally, one category is provided for requirements gathered from network service operators.  These are specific need that arise from operators' experiencese in deploying and managing large-scale WLANs. The priorities are;

The priorities have been assigned to individual objectives in accordance with working group discussions."

Suggested new text: 
"The objectives described in this document have been prioritized based on their immediate significance in the development and evaluation of a control and provisioning protocol for large-scale WLAN deployments.
 
The priorities are;

The priorities have been assigned to individual objectives in accordance with working group discussions.
 
Furthermore, a distinct category of objectives is provided based on requirements gathered from network service operators.  These are specific needs that arise from operators' experiences in deploying and managing large-scale WLANs.

--XX-