Subject: [Capwap] More IETF Expert Review on rev-03...

From: "Mani, Mahalingam (Mahalingam)" <[email-masked]>
Date: Mon, 2 Aug 2004 20:55:20 -0600

All,

Russ Housley's review comments are inline (embedded marked with a
leading [ on column 1) to the draft.

http://www.cs.ucla.edu/~pzerfos/draft-ietf-capwap-arch-03-comments.txt

(They will also be posted to www.capwap.org <http://www.capwap.org/>
website in due course).

Since -04 has been posted to WG (but not yet sent in as I-D) we can
anticipate another rev-05 to include addressing these.

Nevertheless,  do review -04 (and in the light of these comments as
well).

Regards,

-mani

---

From: "Inderpreet Singh" <[email-masked]>
Date: Sun, 15 Aug 2004 22:05:31 -0400

WG:

I have been asked to review the last comments on rev-03 of the Architecture
Taxonomy draft.  Since these comments came in towards the end of the
completion of rev-04, some of the feedback was already taken care of.
Nevertheless, I have reviewed the comments and here are the proposals for
resolution.  One can read the rev-03 and comments at:

If there are any issues, please raise them on the list.  Draft rev-05 is
almost done and just requires resolution to these comments.

Thanks

Inderpreet

=======

Comment#1 [ Please take a look at draft-housley-cms-fw-wrap-04.txt.  I would
like to know if it is useful in this context.  If not, how can it be
adjusted to be helpful? ]

Proposed Resolution#1 - Section 2.2 - I think the scope of the cms-fw-wrap
draft is more the firmware package cryptographic protection.  In the context
of CAPWAP what is more interesting is the firmware package transport
mechanism.  There was considerable discussion on this list regarding this
topic and I think it is out of scope even for the taxonomy document.
Nevertheless, in the protocol design a discussion must take place as to
whether firmware package transport, loading and of course cryptographic
protection should be in scope or out of scope.  And then, yes, cms-fw-wrap
would be applicable.

Comment#2 [ This needs more meat.  Today, this connection is wires, and
there can be physical control over those wires.  I would think that the
threat described above is not a very significant one.  I am.....<Further
text deleted>...]

Proposed Resolution #2 - Section 3.2 - Security section of the Autonomous
architecture.  The following text was added to -04 in this area.  I think it
is sufficient to meet the more meat requirement.

One of the security issues in this architecture is the need for mutual
authentication between the WTP and the Ethernet infrastructure.  This can be
ensured by existing mechanisms such as 802.1x between the WTP and the
Ethernet switch it plugs into. Another critical security issue with this
architecture is the very fact that the WTP is most likely not under lock and
key, but does contain secret information in order to communicate with the
backend systems, such as AAA, SNMP, etc. Due to the common management method
used by IT personnel of pushing a "template" to all devices, theft of such a
device would potentially compromise the wired network.
<<<

Comment#3 [ Not just rogue.  Accidental misconfiguration needs to be
considered. ]

Proposed Resolution #3 - Section 4.7 - I don't think accidental
misconfiguration applies here.  The point being made is that if the WTP does
not authenticate the AC (thus implementing mutual authentication), then its
possible that the WTP connects to an AC that it is not supposed to, ie.
Rogue AC.  Now, since it is the AC that provides all the configuration to
the WTP, the possibility for misconfiguration exists, but has nothing to do
with the subject of authentication.  Am I missing something?

Comment#4 - [ I worry about the word "push" in the previous sentence.  It
makes an assumption about the initiator of the communication.  I think that
the word "transferred" varries less baggage. ]

Proposed resolution#4 - Section 4.8.1 - Done.  New text reads "the resultant
cryptographic
keys for the session are required to be securely transferred from the AC..."

Comment#5 - [ What about the state?  Who are the parties in the 4-way
handshake?  If the STA and the AC are the parties in the 4-way handshake,
then more than keys need to be transferred.  Further, if the same key is
used my more than one WTP, then there needs to be a lot of other stuff
transferred to make sure that nonces are not reused. ]

Proposed Resolution#5 - Section 4.8.1 - awaiting response from Partha
Narasimhan.

Comment#6 - [ Replay protection is probably important too. ]

Proposed Resolution#6 - Section 4.8.2 - Agreed.  Added text. 
Old Text: “Confidentiality and integrity of control channel frames”
New text is: "Confidentiality, integrity and replay protection of control
channel frames"

Comment#7 - [ State too. ]

Proposed Resolution#7 – Section 4.8.2 - Agreed. 
Old text: “Secure management of WTPs and ACs, including mechanisms for
securely setting and resetting secrets.”
New text is: “Secure management of WTPs and ACs, including mechanisms for
securely setting and resetting secrets and state”.

Comment#8 - [ You need confidentiality, integrity, and replay protection on
the over the air links.  Saying, that the links ought to be encrypted is not
enough. ]

Proposed resolution#8 – Section 5.1 - Already changed in rev -04 on 7/25.
Further changed text to include integrity and replay protection.
Old Text: “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 Text: “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.”

Comment#9 - [ Since the document discussed the use of IP-based protocols in
some situations, I expected to see a recommendation for an IETF WG to
standardize it. ]

Proposed Resolutoin #9 – Section 6 - Do we need this now that consensus has
formed anyway?

Comment#10 - [ Need to add a discussion of replay. ]

Proposed Resolution #10 – Section 7 - Changed text:
Old Text: “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 Text: “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.”

---
Inderpreet Singh
Chantry Networks
[email-masked]
Cell: 416-831-3705

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Mani, Mahalingam (Mahalingam)
Sent: Monday, August 02, 2004 10:55 PM
To: [email-masked]; [email-masked]
Subject: [Capwap] More IETF Expert Review on rev-03...

All,

Russ Housley’s review comments are inline (embedded marked with a leading [
on column 1) to the draft.

(They will also be posted to www.capwap.org website in due course).

Since -04 has been posted to WG (but not yet sent in as I-D) we can
anticipate another rev-05 to include addressing these.
Nevertheless,  do review -04 (and in the light of these comments as well).

Regards,
-mani

_______________________________________________
Capwap mailing list
[email-masked]
http://mail.frascone.com/mailman/listinfo/capwap