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

From: "Yang, Lily L" <[email-masked]>
Date: Wed, 25 Aug 2004 15:53:14 -0700

To address comment #5 below, the authors propose to replace the first paragraph in 4.8.1 with the following three paragraphs:
--------------

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 STA and AC are the parties in the 4-way handshake, and the encryption/decryption happens at the WTP, then the PTK has to be transferred from the AC to the WTP. If the PMK 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. 
 
---------------

If there are no further comments on the draft, I would submit the new revision v05 with these resolutions very soon.

Thanks,
Lily

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Inderpreet Singh
> Sent: Sunday, August 15, 2004 7:06 PM
> To: [email-masked]
> Subject: RE: [Capwap] More IETF Expert Review on rev-03...
> 
> 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:
> 
> http://www.cs.ucla.edu/~pzerfos/draft-ietf-capwap-arch-03-comments.txt
> 
> 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.
> 
> http://www.cs.ucla.edu/~pzerfos/draft-ietf-capwap-arch-03-comments.txt
> 
> (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
> 
_______________________________________________
Capwap mailing list
[email-masked]
http://mail.frascone.com/mailman/listinfo/capwap

---

From: Petros Zerfos <[email-masked]>
Date: Wed, 25 Aug 2004 16:23:21 -0700 (PDT)

The three paragraphs are fine, and provide a better organization than the
single paragraph of 4.8.1 (-04 version), since they highlight the two
cases.

Just two comments:
a) the acronyms PTK and PMK (of the 802.11i?) are not defined anywhere
b) neither the 4-way handshake is described elsewhere in the text.

Should we mention (reference...) the 802.11i for the above, in order to
make it more clear? Or even provide definitions to make the document more
self-contained?

Petros

On Wed, 25 Aug 2004, Yang, Lily L wrote:

> If the STA and AC are the parties in the 4-way handshake, and the
> encryption/decryption happens at the WTP, then the PTK has to be
> transferred from the AC to the WTP. If the PMK 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.
> If there are no further comments on the draft, I would submit the new
> revision v05 with these resolutions very soon.
>
> Thanks,
> Lily
>

--
Petros Th. Zerfos
UCLA - Computer Science Department
email : [email-masked]
_______________________________________________
Capwap mailing list
[email-masked]
http://mail.frascone.com/mailman/listinfo/capwap