Subject: Re:FW: [Capwap] IESG Review (CAPWAP protocol should support NULL-Authentication)

From: zhaoyujin 31390 <[email-masked]>
Date: Thu, 23 Feb 2006 10:35:31 +0500

Hi all:

   I agree "The CAPWAP must support mutual authentication".

   And I also recommend that "The CAPWAP need support one authentication method-NULL Authentication".  Based on this feature, CAPWAP can satisfy some small customers simple scenario.

Best regards
Yujin Zhao

>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."
>
>Suggestion: 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."
>
><RG> I agree with the suggestion though we may have to see if the base CAPWAP protocol >does have a specification for this.

If there are no futher objections from the WG to the proposed responses
to the IESG Review for the CAPWAP Objectives draft, we will respond to
the IESG with the  text provided by Saravanan and Richard.
 
Thanks,
Dorothy
 
________________________________

From: ext Richard Gwee [mailto:[email-masked]] 
Sent: Tuesday, February 21, 2006 12:08 AM
To: Saravanan Govindan; [email-masked]
Cc: [email-masked]; Cheng Hong; [email-masked]
Subject: RE: [Capwap] IESG Review

Hi, 

My two cents' worth of thought.

I understand that there may exist a need to change some of the text in
the CAPWAP objectives. In any cases, I feel that the changes will have
to be carefully thought through, especially since we have evaluated the
four proposals based on these objectives. We do not certainly want to
see some efforts wasted.

My feedback are inline.

Thanks and regards

Richard Gwee 

________________________________

From: Saravanan Govindan [mailto:[email-masked]] 
Sent: Monday, February 20, 2006 2:41 PM
To: [email-masked]
Cc: [email-masked]; Cheng Hong; [email-masked]
Subject: [Capwap] IESG Review

Hi All,

This is a list of comments from the IESG and suggested responses.
Feedback would be appreciated.

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."

Suggestion: 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."

<RG> I agree with the suggestion though we may have to see if the base
CAPWAP protocol does have a specification for this.

--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."

Clarification: From Mani - "the intent 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."

<RG> May I boldly suggest that we change the text to be "The design of
the CAPWAP protocol MUST NOT introduce new security threats that can
weaken existing security measures of WLAN system." Feel free to discuss
more on this one.

--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."
 
Clarification: From Saravanan - "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."
 
<RG> I will certainly think that this objective may not be necessary to
a certain extent based on the comments from IESG. 
 
--XX-
 
4. Section: 5.2 Desirable Objectives
 
Comment: "Why aren't the items in this section listed as SHOULD instead
of MUST?"
 
Clarification: From Saravanan - "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."
 
<RG> I agree with the clarification.
--XX-

Sam Hartman's Review
 
5. Section: 5.1.8 CAPWAP Protocol Security
 
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."
 
Suggestion: From Charles Clancy [To be inserted as last paragraph of
Description] - "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."
 
[Reference to BCP 107 to be included.]
 
<RG> No comments on this one.
--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.
 
Suggestion: From Saravanan - "Once WTPs and WLAN controller have been
mutually authenticated, information exchanges between them must be
secured against various security threats by providing confidentiality
and integrity protection."
 
<RG> I agree with the suggestion.
-
-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."
 
Suggestion: From Saravanan, Reorganize introduction paragraph. 
 
"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 need that arise from operators' experiencese [Note: Should be
"experiences"] in deploying and managing large-scale WLANs.
 
a. Operator Requirements"
--XX-
 <RG> I agree with the suggestion.

 Thanks and regards

Richard Gwee

________________________________

Republic Polytechnic, Tanglin Campus, 1 Kay Siang Road, Singapore 248922
. www.rp.sg <http://www.rp.sg>  . Fax: +65 6415-1310 . 
 From March 2006, we will be located in our new home at 9 Woodlands
Avenue 9, Singapore 738964.

Republic Polytechnic, the first Institute of Higher Learning to fully
adopt the Problem-Based Learning approach in Singapore, continues to
strive towards best practices and maintain excellence in service
standards with the following certifications: Singapore Innovation Class
(SIC), Singapore Quality Class (SQC), People Developer Standards and
QEHS (ISO 9001, 14001 and OHSAS 18001)

________________________________

CONFIDENTIALITY CAUTION: This message is intended only for the use of
the individual or entity to whom it is addressed and contains
information that is privileged and confidential. If you, the reader of
this message, are not the intended recipient, you should not
disseminate, distribute or copy this communication. If you have received
this communication in error, please notify us immediately by return
email and delete the original message. Thank you. 	
_________________________________________________________________
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

---

From: Charles Clancy <[email-masked]>
Date: Thu, 23 Feb 2006 07:51:05 -0500

I think "NULL authentication" is too vague.  Do you still want packet 
encryption?  This could one of many different possibilities:

1. key exchange with manufacturer-signed certs (either DH or RSA-based)
2. key exchange with unsigned keys (either DH or RSA-based)
3. key exchange with SSH-style key caching
4. nonce exchange with unkeyed PRF acting as KDF for session keys
5. for DTLS, simply not use the DTLS tunnel

Regardless, I don't think the requirement for NULL authentication should 
be part of the objectives draft.  There's nothing in the objectives 
draft that explicitly forbids it, so it can be added later if there is 
consensus on its necessity.

IMHO, DTLS with an RSA key exchange using SSH-style key caching might be 
something potentially useful, and better than turning security off 
completely.

[ t. charles clancy ]--[ [email-masked] ]--[ www.cs.umd.edu/~clancy ]
[ computer science ]-----[ university of maryland | college park ]

---

From: Scott G Kelly <[email-masked]>
Date: Thu, 23 Feb 2006 05:02:20 -0800

zhaoyujin 31390 wrote:
> And I also recommend that "The CAPWAP need support one authentication
> method-NULL Authentication".  Based on this feature, CAPWAP can
> satisfy some small customers simple scenario.
> 
> Best regards Yujin Zhao

Like Charles, I'm not sure exactly what you're looking for. So far, 
we've considered control channel security (endpoint authentication, 
confidentiality, and data integrity) to be required. My guess is you'd 
like to turn *all* of this off (make security optional), but you could 
also be asking to simply turn off endpoint authencation, since that's 
what the text regarding "mutual authentication" below refers to.

Please clarify your intent.

>> 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."
>> 
>> Suggestion: 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."
>> 
>> <RG> I agree with the suggestion though we may have to see if the
>> base CAPWAP protocol >does have a specification for this.
> 
> 
> 
> 
> ------------------------------------------------------------------------
> 
> 
> If there are no futher objections from the WG to the proposed
> responses to the IESG Review for the CAPWAP Objectives draft, we will
> respond to the IESG with the  text provided by Saravanan and Richard.
> 
> 
> Thanks, Dorothy
> 
> ------------------------------------------------------------------------
>  *From:* ext Richard Gwee [mailto:[email-masked]] *Sent:*
> Tuesday, February 21, 2006 12:08 AM *To:* Saravanan Govindan;
> [email-masked] *Cc:* [email-masked]; Cheng Hong;
> [email-masked] *Subject:* RE: [Capwap] IESG Review
> 
> Hi,
> 
> 
> 
> My two cents’ worth of thought.
> 
> 
> 
> I understand that there may exist a need to change some of the text
> in the CAPWAP objectives. In any cases, I feel that the changes will
> have to be carefully thought through, especially since we have
> evaluated the four proposals based on these objectives. We do not
> certainly want to see some efforts wasted.
> 
> 
> 
> My feedback are inline.
> 
> 
> 
> Thanks and regards
> 
> Richard Gwee
> 
> 
> 
> ------------------------------------------------------------------------
> 
> 
> *From:* Saravanan Govindan
> [mailto:[email-masked]] *Sent:* Monday, February
> 20, 2006 2:41 PM *To:* [email-masked] *Cc:* [email-masked];
> Cheng Hong; [email-masked] *Subject:* [Capwap] IESG
> Review
> 
> 
> 
> Hi All,
> 
> 
> 
> Brian Carpenter’s Review:
> 
> 
> 
> 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."
> 
> 
> 
> Suggestion: From Charles Clancy – “The CAPWAP protocol MUST support 
> <RG> I agree with the suggestion though we may have to see if the
> base CAPWAP protocol does have a specification for this.
> 
> 
> 
> --XX--
> 
> 
> 
> 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.”
> 
> 
> 
> Clarification: From Mani – “the intent 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.”
> 
> 
> 
> <RG> May I boldly suggest that we change the text to be “The design
> of the CAPWAP protocol MUST NOT introduce new security threats that
> can weaken existing security measures of WLAN system.” Feel free to
> discuss more on this one.
> 
> 
> 
> --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.”
> 
> 
> 
> Clarification: From Saravanan – “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.”
> 
> 
> 
> <RG> I will certainly think that this objective may not be necessary
> to a certain extent based on the comments from IESG.
> 
> 
> 
> --XX—
> 
> 
> 
> Comment: “Why aren't the items in this section listed as SHOULD
> instead of MUST?”
> 
> 
> 
> Clarification: From Saravanan – “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
> exchange for this protocol.”
> 
> 
> 
> Description] – “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."
> 
> 
> 
> --XX—
> Comment: In the following text, please describe what security
> services are meant; probable services include integrity and
> confidentiality.
> 
> 
> 
> -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.”
> 
> 
> 
> “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.
> 
> 
> 
> specific need that arise from operators' experiencese [Note: Should
> be "experiences"] in deploying and managing large-scale WLANs.
> 
> 
> 
> a. Operator Requirements”
> 
> --XX—
> 
> ------------------------------------------------------------------------
> 
> 
> Republic Polytechnic, Tanglin Campus, 1 Kay Siang Road, Singapore
> 248922 . _www.rp.sg_ <http://www.rp.sg> . Fax: +65 6415-1310 . / From
> _March 2006_, we will be located in our new home at 9 Woodlands 
> Avenue 9, Singapore 738964./
> 
> /Republic Polytechnic, the first Institute of Higher Learning to
> fully adopt the Problem-Based Learning approach in Singapore,
> continues to strive towards best practices and maintain excellence in
> service standards with the following certifications: Singapore
> Innovation Class (SIC), Singapore Quality Class (SQC), People
> Developer Standards and QEHS (ISO 9001, 14001 and OHSAS 18001)/
> 
> ------------------------------------------------------------------------
> 
> 
> information that is privileged and confidential. If you, the reader
> of this message, are not the intended recipient, you should not 
> disseminate, distribute or copy this communication. If you have
> received this communication in error, please notify us immediately by
> return email and delete the original message. Thank you.
> 
> 
> ------------------------------------------------------------------------
> 
> 
> _________________________________________________________________ To
> unsubscribe or modify your subscription options, please visit: 
> ------------------------------------------------------------------------
> 
> 
> _________________________________________________________________ To
> unsubscribe or modify your subscription options, please visit: