Subject: [Capwap] Proposed Resolution to Issue 143: Specification for the usage of CERTS for CAPWAP/was CERT issues in CAPWAP-01

From: "Dorothy Stanley" <[email-masked]>
Date: Tue, 3 Oct 2006 15:28:13 -0700

All,

Proposed resolutions for the several components of Issue 143 are included
below.
Issue 143 is also copied below.

Comments please.

Thanks,

Dorothy
----------------------------------------------------------------------------------------------------------
1) It should be OK for the clock on a WTP to be "wacky",
  due to having no battery backed up clock, the battery
  going bad, the clock never set properly. On the other
  hand, an AC's clock should be set pretty accurately.
  I't not sure that the recommendations support this
  scenario. In general, want to support:
    0) WTPs with no management interface (other than CAPWAP)
    1) first time use of WTP after being manufactured
    2) continued use of WTP after long time operation
    3) continued use in short term deployments (such
        as WiFi network used by a Circus that moves from
        town to town (setting up and tearing down for
        for each move), or for the WiFi network used
        at conferences (such as the IETF).

Proposed resolution: Adopt Charles' Clancy's recommendation to
Replace the following text:

 Proper validation of certificates typically requires checking to
   ensure the certificate has not yet expired.  If devices have a real-
   time clock, they SHOULD verify the certificate validity dates.  If no
   real-time clock is available, the device SHOULD attempt to determine
   the current time using NTP prior to certificate validation.  If
   neither is available, devices SHOULD verify that the start validity
   date of its peer's certificate is less than its own certificate's
   expiration date, and its peer's expiration date is greater than its
   own start date.  Note that failure to check a certificate's temporal
   validity can make a device vulnerable to man-in-the-middle attacks
   launched using compromised, expired certificates, and therefore
   devices should make every effort to perform this validation.

with

Proper validation of certificates typically requires checking to
   ensure the certificate has not yet expired.  If devices have a
   real-time clock, they SHOULD verify the certificate validity dates.
    If no real-time clock is available, the device SHOULD make a
   best-effort attempt to validate the certificate validity dates
   through other means.  Failure to check a certificate's temporal
    validity can make a device vulnerable to man-in-the-middle attacks
   launched using compromised, expired certificates, and therefore
   devices should make every effort to perform this validation.
----------------------------------------------------------------------------------------------

2) The new text suggests the common name in the format
  "01:23:45:67:89:[email-masked]" for WTPs. And implies
  that "DOMAIN.NET <http://domain.net/>" is the "administrative domain".
  To me, "administrative domain" implies the user
  of the WTP. But, I believe that the WTP manufacturer
  must be required to generate a CERT (and the WTP
  should come "preloaded" with the CERT), and the user
  of the WTP should not have to create the WTP CERT.
  (By the way, not sure how long the CERT should be
  valid.) Thus, I see no need or desire for
   "@DOMAIN.NET <http://domain.net/>" added to the common name, and suggest
  that it be removed. (Also, I think that we have
  now a new requirement to be able via CAPWAP to
  replace the WTP's CERT with another, and may be
  to add CA CERTs for the AC's CERT chain. Also,
  what is the min depth that a WTP should support?)

Proposed Resolution:
Adopt David's suggestion to drop the @DOMAIN.NET and
add a sentence describing the storage requirements on the WTP and AC:

Change from:

  Another important part of certificate authentication is binding a
   certificate to a particular device.  There are many ways to
   accomplish this.  CAPWAP RECOMMENDS specifying the certificate common
   name (CN) as the WTP or AC MAC address formatted as ASCII HEX,
   followed by an @ symbol, and then an administrative domain.  For
   example, 01:23:45:67:89:[email-masked].  During authentication,
   devices SHOULD ensure that the MAC matches the MAC specified in the
   CAPWAP header, and that the domain in both the AC and WTP
   certificates match.

to
  Another important part of certificate authentication is binding a
   certificate to a particular device.  There are many ways to
   accomplish this.  CAPWAP RECOMMENDS specifying the certificate common
   name (CN) as the WTP or AC MAC address formatted as ASCII HEX,
   for example, 01:23:45:67:89:ab.  During authentication,
   devices SHOULD ensure that the MAC address matches the MAC
   address  specified in the CAPWAP header. If this mechanism is used, the
ACs SHOULD
   maintain list of all authorized WTP MAC addresses and the WTP SHOULD
   save the AC credential or credential identifier.

---------------------------------------------------------------------------------------------------------
3) specify that WTP CERTs cannot be selfsigned,
    and MUST have a common name of the ASCII
    of the MAC address (or other unique ID,
    such as serial number)

Proposed resolution:
No change to the text regarding use of self-signed certs. While the use
of self-signed certs may not
be widespread,  there isn't a compelling need to preclude their
use in a CAPWAP application.

Change the text to require that WTP certs MUST have a
common mane of the ASCII of the MAC address:

from:
CAPWAP RECOMMENDS specifying the certificate common
   name (CN) as the WTP or AC MAC address formatted as ASCII HEX,
   for example, 01:23:45:67:89:ab.

to

Specificaiton of the certificate common
   name (CN) as the WTP or AC MAC address formatted as ASCII HEX,
   for example, 01:23:45:67:89:ab is REQUIRED for use with the CAPWAP
protocol.

---------------------------------------------------------------------------------------------------------
  4)  The Join Request must be updated to include
    the common name as a message element

Proposed resolution: No change to the text. The join request
currenly includes the BSSID. Also, since the JOIN occurs inside the DTLS
tunnel, it is
 implicitly bound to the MAC (assuming certs were used for authentication,
and
this is N/A for preshared key authentication).

----------------------------------------------------------------------------------------------------------
  5) specify that WTPs must continue even when it
    believes its CERT or the AC's CERT is outside
    the time window

Proposed resolution: No change to the document.
That seems equivalent to mandating WTPs never validate timestamps on any
AC certs.  What if the WTP has a real-time clock and actually CAN
distinguish between good and bad certs?
-----------------------------------------------------------------------------------------------------------
.
 6) Tthe CAPWAP protocol must have a new message
      to install an updated CERT for the WTP.

Proposed resolution: Defer for consideration in the next version of CAPWAP;
the mechanisms for certificate distribution and management are
quite complex re: certifcate formats, content, generation etc.
----------------------------------------------------------------------------------------------------------------

 7) the CAPWAP protocol must have a new message
      to install a CA CERT.

Proposed resolution: Defer for consideration in the next version of CAPWAP;
the mechanisms for certificate distribution and management are
quite complex re: certifcate formats, content, management.

------------------------------------------------------------------------------
Issue 143:

1) Cipher Suites for CERTS
CAPWAP-01 has the following cipher suites specified:
TLS_DH_RSA_WITH_AES_128_CBC_SHA,
TLS_DH_RSA_WITH_3DES_EDE_CBC_SHA, and
TLS_DH_RSA_WITH_AES_256_CBC_SHA

The above is a mistake, and the following should be used:

TLS_DHE_RSA_WITH_AES_128_CBC_SHA,
TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA, and
TLS_DHE_RSA_WITH_AES_256_CBC_SHA

2) CERT usage type:
CAPWAP-01 has the folllwing about CERTS:
  2.4.4.3
.  Certificate Usage

  Validation of the certificates by the AC and WTP is required so that
  only an AC may perform the functions of an AC and that only a WTP may
  perform the functions of a WTP.  This restriction of functions to the

  AC or WTP requires that the certificates used by the AC MUST be
  distinguishable from the certificate used by the WTP.  To accomplish
  this differentiation, the x.509v3 certificates MUST include the
  Extensions field [11] and MUST include the NetscapeComment [15]

  extension.

  For an AC, the value of the NetscapeComment extension MUST be the
  string "CAPWAP AC Device Certificate".  For a WTP, the value of the
  NetscapeComment extension MUST be the string "CAPWAP WTP Device

  Certificate".

  Part of the CAPWAP certificate validation process includes ensuring
  that the proper string is included in the NetscapeComment extension,
  and only allowing the CAPWAP session to be established if the

  extension does not represent the same role as the device validating
  the certificate.  For instance, a WTP MUST NOT accept a certificate
  whose NetscapeComment field is set to "CAPWAP WTP Device
  Certificate".

Using the "NetscapeComment extension" is not appropriate.

3) Selfsigned CERTs, CA CERTs, and validity checking
I didn't see anything about whether or not the CERTs
were selfsigned. And if not selfsigned, who would sign them.

Also, how would a limited resource WTP verify an AC's cert?
What if the WTP had no realtime clock (or a realtime clock
with an unknown certainty)?

4) Common Name in a WTP's CERT
I believe that the common name on the WTP's CERT

must be the WTP's ID (which would be either the serial
number or "base MAC address"), and should be provided
as a parameter on the join.

Two small, but important issues are:
1) It should be OK for the clock on a WTP to be "wacky",
  due to having no battery backed up clock, the battery
  going bad, the clock never set properly. On the other
  hand, an AC's clock should be set pretty accurately.
  I't not sure that the recommendations support this
  scenario. In general, want to support:
    0) WTPs with no management interface (other than CAPWAP)
    1) first time use of WTP after being manufactured
    2) continued use of WTP after long time operation
    3) continued use in short term deployments (such
        as WiFi network used by a Circus that moves from
        town to town (setting up and tearing down for
        for each move), or for the WiFi network used
        at conferences (such as the IETF).
2) The new text suggests the common name in the format
  "01:23:45:67:89:[email-masked]" for WTPs. And implies
  that "DOMAIN.NET <http://domain.net/>" is the "administrative domain".
  To me, "administrative domain" implies the user
  of the WTP. But, I believe that the WTP manufacturer
  must be required to generate a CERT (and the WTP
  should come "preloaded" with the CERT), and the user
  of the WTP should not have to create the WTP CERT.
  (By the way, not sure how long the CERT should be
  valid.) Thus, I see no need or desire for
   "@DOMAIN.NET <http://domain.net/>" added to the common name, and suggest
  that it be removed. (Also, I think that we have
  now a new requirement to be able via CAPWAP to
  replace the WTP's CERT with another, and may be
  to add CA CERTs for the AC's CERT chain. Also,
  what is the min depth that a WTP should support?)

So, it appears to me that the following changes
are required to CAPWAP-01:
 1) specify that WTP CERTs cannot be selfsigned,
    and MUST have a common name of the ASCII
    of the MAC address (or other unique ID,
    such as serial number)
 2) The Join Request must be updated to include
    the common name as a message element
 3) specify that WTPs must continue even when it
    believes its CERT or the AC's CERT is outside
    the time window
 4) the CAPWAP protocol must have a new message
    to install an updated CERT for the WTP.
 5) the CAPWAP protocol must have a new message
    to install a CA CERT.

On 6/15/06, Michael Montemurro <[email-masked]> wrote:
>
> All,
>
> I've created issue 143 to deal with this problemm.
>
>
> On 6/15/06, Scott G Kelly <[email-masked] > wrote:
> >
> > Hi David,
> >
> > Like I said previously, I agree with pretty much everything Charles
> > said, so I won't re-iterate his points, and will instead simply add a
> > few comments below:
> >
> > David T. Perkins wrote:
> > > HI,
> > >
> > > Thank you for responding to my issues. It seems to me that
> > > we are not yet looking at the same problem. So let me try
> > > again.
> > >
> > > What I was trying to point out is that there are a few
> > > VERY common scenarios (use cases) where the clock on
> > > a WTP can be totally wrong. If a WTP is coded so that
> > > it will not continue and communicate with an AC when
> > > it thinks the AC's CERTs are outside the time window,
> > > (or it thinks that it's on CERTs are outside the time
> > > window) then you will have a useless device (a brick).
> > > In many (maybe most) deployments, it costs more to
> > > physically touch a WTP than the equipment cost of the WTP.
> > > At the Dallas IETF, there were APs that were "somewhere"
> > > in the ceiling not doing any useful work, but sending
> > > out beacons with their config'ed SSID because it was
> > > too expensive to find them, and take them down. It
> > > was more cost effective to just new new APs.
> > >
> > > For an AC, it's clock must be accurate,
> > > and it would be OK for it to not proceed if it believes
> > > its CERTs are outside their time window. But, the
> > > CAPWAP protocol should allow an AC to establish
> > > a session with a WTP that has a WACKY clock (and
> > > even a CERT that has expired). NOTE: the AC clock
> > > must be pretty accurate for management (such as
> > > logs) to be useful (or work). The CAPWAP protocol has
> > > support to set the WTP's clock. But it doesn't have support
> > > to update a CERT in a WTP. It seems like this is
> > > needed.
> > >
> > > Assume the clocks are OK, now lets talk about WTP
> > > CERT validation by the AC. This wasn't addressed, but
> > > I believe that WTP CERTs MUST be signed by the
> > > WTP manufacturer, or one of the WELL KNOWN certification
> > > authorities. Adding the CA CERTs in an AC is done through
> > > means outside of CAPWAP (such as via the CLI
> > > on the AC). Thus, WTP CERTs MUST NOT be selfsigned.
> > > And, I believe that the WTPs CERTs should have
> > > for the common name the ASCII of MAC address,
> > > or other unique ID of the WTP (and this must be provided
> > > in the Join Request message). I didn't understand
> > > in the previous text, nor in your message below
> > > why the common name would have a suffix of
> > > "@DOMAIN.NET".
> > >
> > > Now lets talk about AC CERT validation by the WTP.
> > > The CERT for the AC can be created by the AC
> > > manufacturer, the user, or 3rd party. It could
> > > be selfsigned, or have a chain from the manufacturer
> > > or a WELL KNOWN CA. Given this, it will be difficult
> > > for a WTP to verify a AC CERT, at least the first
> > > time. This is just a "leap of faith" if the CERT
> > > cannot be verified. After this first connection,
> > > the AC through the CAPWAP protocol could configure
> > > the WTP with the needed CA CERT(s). However, there
> > > may be some WTPs that have no additional persistent
> > > storage for these CERTs.
> > >
> > > So, it appears to me that the following changes
> > > are required to CAPWAP-01:
> > >   1) specify that WTP CERTs cannot be selfsigned,
> > >      and MUST have a common name of the ASCII
> > >      of the MAC address (or other unique ID,
> > >      such as serial number)
> >
> > While we may not think self-signing is a good idea for our typical
> > deployment models, I'm not sure we have to say you MUST NOT do this, but
> > I'll give this some more thought.
> >
> > >   2) The Join Request must be updated to include
> > >      the common name as a message element
> >
> > What is your objective with this requirement?
> >
> > >   3) specify that WTPs must continue even when it
> > >      believes its CERT or the AC's CERT is outside
> > >      the time window
> >
> > Charles addressed this.
> >
> > >   4) the CAPWAP protocol must have a new message
> > >      to install an updated CERT for the WTP.
> > >   5) the CAPWAP protocol must have a new message
> > >      to install a CA CERT.
> >
> > I agree that we should discuss this, but I'm a little leary of taking on
> >
> > the task of fully specifying every nuance of cert use and mgmt.
> > Remember, the ipsec group spun out a whole new wg to handle this
> > particular problem. It's complicated.
> >
> > What we're trying to do in the base protocol is come up with minimal and
> >
> > sufficient guidelines to get people going. I think cert mgmt and usage
> > could be revisited in detail later, perhaps under a new charter, but
> > that we might want to consciously avoid getting too bogged down in this
> > for rev 1.
> >
> > Scott
> >
> > _________________________________________________________________
> > 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
>
>
_________________________________________________________________
To unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/capwap

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