Subject: RE: [Capwap] Comments on draft-ietf-capwap-arch-03.txt

From: "Pat R. Calhoun" <[email-masked]>
Date: Mon, 19 Jul 2004 05:54:20 -0700

I'm beginning to understand why most choose not to reply to your posts.  My statement is self-evident.  We're not getting anywhere discussing it further when it comes to manageability and I'd certainly like to keep your mother out of this discussion.
<PRC> Then may I introduce you to my aunt ;-)
 
Your security statement I refuted (which you also conveniently cut out) was a misconception I heard elsewhere too and wanted to correct it...The idea that handling encryption at the AP can prevent flooding the wired network.  Because the authentication portion of 802.11i is based on 802.1x, and the keys for 802.1x (TLS portion) reside on the authentication server, the AP cannot prevent EAP flooding.  So flooding must be prevented in other ways which I've already mentioned below...
<PRC> hmmmm.... you really have me confused here. Certainly the client's credentials are on the AS, but the PMK and the PTK aren't. Therefore the questions really is whether it is possible to decrypt the packets in the AP or not. I would state that pushing the PTK into the AP (not in permanent storage) makes plenty of sense as it allows the AP to at least discard invalid packets. As far as authenticating 802.1x packets (because they are not authenticated), there are other methods,such as rate limiting, etc.
 
Again you chose to cut out what I said.  I mentioned both WEP and AES-CCM where flooding can occur to point out that it is irrelevant what encryption is used.
<PRC> I apologize for removing the text, but it really didn't address the point. In any case, you seem to imply that encryption cannot be done in the AP, or that a system must be designed for WEP (not sure which one). I think that one should not assume that either one of these points is true.
 
On a slightly more humorous note...searching on google for "wep security airespace", the first hit yields:
 
"Specifically, the Airespace security framework supports the following layers of security protocols and ... action * Layer 2 - WEP, WPA, 802.1x"
 
<PRC> Indeed, that is rather humurous - but keep in mind that this is a marketing brochure and IT buyers have a check list that very often includes items that will not (or should not) be used. How many times have I seen that famous RFP come in with some April Fool's RFC on it. That said, what I was *trying* to say is that we should not be designing the system for WEP, but for TKIP and AES-CCM.
 
<PRC> So we can keep this thread alive or agree to disagree. In either case, there is no clear evidence that the original statement was valid. You have an opinion, I have my own.
 
PatC

---

From: "Randy Chou" <[email-masked]>
Date: Mon, 19 Jul 2004 10:46:04 -0700

> As far as authenticating 802.1x packets (because they are not
authenticated), there are other methods,such as rate limiting, etc.

That's when we start moving functionality into the AP that doesn't
necessarily belong in this document, something we should prevent as you also
alluded to.  Rate limiting as we've seen in other security products isn't
that simple of a problem.  A plain rate limiting approach is simply shifting
the problem elsewhere.  Note that this was just one of the problems I had
listed out.  The AP can never fully guarantee that a packet that isn't
destined to the wired side can be dropped, so the AP cannot claim to prevent
flooding (based on its current definition).  So flood prevention shouldn't
come into discussion when analyzing ease of manageability.

> That said, what I was *trying* to say is that we should not be designing
the system for WEP, but for TKIP and AES-CCM.

As much as I hate WEP, ease of manageability should take into account all
likely modes of operation.  Besides EAP flood in TKIP and AES-CCM
environments, there are plenty of enterprises running different types of
encryption (or no encryption) for guests, phones, VPN over WEP, where a
plain replay attack will flood the wire.  That is why I wanted to separate
manageability and security in the first place.

From email from James Kempf:
> Can we keep it civil?

My apologies.  Email's not always the best medium for arguments and it's
easy to get carried away.

> There's obviously a difference of opinion here about where to locate state
and how that impacts ease of managability. Barring some real hard data about
managability for different products (which I would highly encourage both
sides to seek through some neutral third party), there's probably no way to
objectively assess the two sides of this argument.
Therefore, as an attempt at concensus, I'd suggest modifying the statement
to say...

Besides giving Pat a hard time, I truly do believe the statement I had made
was self-evident, "fewer state between devices makes it easier to manage",
and would like to hear other's opinion before changing the wording.  Was
there any other compelling reason against the current wording besides Pat's
flood prevention claim?

Regards,

--
Randy
  -----Original Message-----
  From: Pat R. Calhoun [mailto:[email-masked]]
  Sent: Monday, July 19, 2004 5:54 AM
  To: Randy Chou; [email-masked]
  Cc: [email-masked]
  Subject: RE: [Capwap] Comments on draft-ietf-capwap-arch-03.txt

  I'm beginning to understand why most choose not to reply to your posts.
My statement is self-evident.  We're not getting anywhere discussing it
further when it comes to manageability and I'd certainly like to keep your
mother out of this discussion.
  <PRC> Then may I introduce you to my aunt ;-)

  Your security statement I refuted (which you also conveniently cut out)
was a misconception I heard elsewhere too and wanted to correct it...The
idea that handling encryption at the AP can prevent flooding the wired
network.  Because the authentication portion of 802.11i is based on 802.1x,
and the keys for 802.1x (TLS portion) reside on the authentication server,
the AP cannot prevent EAP flooding.  So flooding must be prevented in other
ways which I've already mentioned below...
  <PRC> hmmmm.... you really have me confused here. Certainly the client's
credentials are on the AS, but the PMK and the PTK aren't. Therefore the
questions really is whether it is possible to decrypt the packets in the AP
or not. I would state that pushing the PTK into the AP (not in permanent
storage) makes plenty of sense as it allows the AP to at least discard
invalid packets. As far as authenticating 802.1x packets (because they are
not authenticated), there are other methods,such as rate limiting, etc.

  Again you chose to cut out what I said.  I mentioned both WEP and AES-CCM
where flooding can occur to point out that it is irrelevant what encryption
is used.
  <PRC> I apologize for removing the text, but it really didn't address the
point. In any case, you seem to imply that encryption cannot be done in the
AP, or that a system must be designed for WEP (not sure which one). I think
that one should not assume that either one of these points is true.

  On a slightly more humorous note...searching on google for "wep security
airespace", the first hit yields:

  "Specifically, the Airespace security framework supports the following
layers of security protocols and ... action • Layer 2 – WEP, WPA, 802.1x"

  <PRC> Indeed, that is rather humurous - but keep in mind that this is a
marketing brochure and IT buyers have a check list that very often includes
items that will not (or should not) be used. How many times have I seen that
famous RFP come in with some April Fool's RFC on it. That said, what I was
*trying* to say is that we should not be designing the system for WEP, but
for TKIP and AES-CCM.

  <PRC> So we can keep this thread alive or agree to disagree. In either
case, there is no clear evidence that the original statement was valid. You
have an opinion, I have my own.

  PatC