Subject: [Capwap] CERT issues in CAPWAP-01

From: "David T. Perkins" <[email-masked]>
Date: Wed, 14 Jun 2006 15:47:04 -0700 (PDT)

HI,

I didn't see the following in the issue tracker. I reported
them to Scott and Charles back around May 8.

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. 

Regards,
/david t. perkins

_________________________________________________________________
To unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/capwap

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

---

From: "Dorothy Stanley" <[email-masked]>
Date: Wed, 14 Jun 2006 16:04:19 -0700

David,

Charles had forwarded the text below. Does this text address your concerns?
This is included as part of Issue 2. I thought I sent it to the
list, but evidently not.

Dorothy

2.4.4.1.  Authenticating with Certificates

   Note that only block ciphers are currently recommended for use with
   DTLS.  To understand the reasoning behind this, see [26].
   However,support for AES counter mode encryption is currently
   progressing in the TLS working group, and once protocol identifiers
   are available, they will be added below.  At present, the following
   algorithms MUST be supported when using certificates for CAPWAP
   authentication:

   o  TLS_RSA_WITH_AES_128_CBC_SHA
   o  TLS_RSA_WITH_3DES_EDE_CBC _SHA

   The following algorithms SHOULD be supported when using certificates:

   o  TLS_DHE_RSA_WITH_AES_128_CBC_SHA
   o  TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA

   The following algorithms MAY be supported when using certificates:

   o  TLS_RSA_WITH_AES_256_CBC_SHA
   o  TLS_DHE_RSA_WITH_AES_256_CBC_SHA

2.4.4.2.  Authenticating with Preshared Keys

   Pre-shared keys present significant challenges from a security
   perspective, and for that reason, their use is strongly
   discouraged.  However, [13] defines several different methods for
   authenticating with preshared keys, and we focus on the following
   two:

   o  PSK key exchange algorithm - simplest method, ciphersuites use
      only symmetric key algorithms

   o  DHE_PSK key exchange algorithm - use a PSK to authenticate a
      Diffie-Hellman exchange.  These ciphersuites give some additional
      protection against dictionary attacks and also provide Perfect
      Forward Secrecy (PFS).

   The first approach (plain PSK) is susceptible to passive dictionary
   attacks; hence, while this alorithm MUST be supported, special care
   should be taken when choosing that method.  In particular, user-
   readable passphrases SHOULD NOT be used, and use of short PSKs
   SHOULD be strongly discouraged.

   The following cryptographic algorithms MUST be supported when using
   preshared keys:

   o  TLS_PSK_WITH_AES_128_CBC_SHA
   o  TLS_PSK_WITH_3DES_EDE_CBC_SHA
   o  TLS_DHE_PSK_WITH_AES_128_CBC_SHA
   o  TLS_DHE_PSK_WITH_3DES_EDE_CBC_SHA

   The following algorithms MAY be supported when using preshared
   keys:

   o  TLS_PSK_WITH_AES_256_CBC_SHA
   o  TLS_DHE_PSK_WITH_AES_256_CBC_SHA

   When using certificates, both authentication and authorization must
   be considered.  Section 13.3 provides recommendations on how to
   authenticate a certificate and bind that to a CAPWAP entity.  This
   section deals with certificate authorization.

   Certificate authorization 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.509 certificates MUST include the
   extended key usage (EKU) certificate extension [11].

   The EKU field indicates one or more purposes for which a certificate
   may be used.  It is an essential part in authorization.  Its syntax
   is as follows:

      ExtKeyUsageSyntax  ::=  SEQUENCE SIZE (1..MAX) OF KeyPurposeId

      KeyPurposeId  ::=  OBJECT IDENTIFIER

   Here we define two KeyPurposeId values, one for the WTP and one for
   the AC.  Inclusion of one of those two values indicates a
   certificate is authorized for use by a WTP or AC, respectively.
   These values are formatted as id-kp fields.

      id-kp  OBJECT IDENTIFIER  ::=
         { iso(1) identified-organization(3) dod(6) internet(1)
           security(5) mechanisms(5) pkix(7) 3 }

      id-kp-capwapWTP  OBJECT IDENTIFIER  ::=  { id-kp XX }

      id-kp-capwapAC   OBJECT IDENTIFIER  ::=  { id-kp YY }

   The integer values XX and YY are yet to be allocated by IANA.

   For an AC, the id-kp-capwapAC EKU MUST be present in the
   certificate.  For a WTP, the id-kp-capwapWTP EKU MUST be present in
   the certificate.

   Part of the CAPWAP certificate validation process includes ensuring
   that the proper EKU is included and only allowing the CAPWAP
   session to be established if the extension properly represents the
   device.

13.3.  Use of Certificates in CAPWAP

   For public-key-based DTLS deployments, each device SHOULD have
   unique credentials, with an extended key usage authorizing them to
   act as either a WTP or AC.  If devices do not have unique
   credentials, it is possible that by compromising one, any other one
   using the same credential may also be considered to be compromised.

   Certificate validation involves checking a large variety of things.
   Since the necessary things to validate are often
   environment-specific, many are beyond the scope of this document.
   In this section, we provide some basic guidance on certificate
   validation.

   Each device is responsible for authenticating and authorizing
   devices with which they communicate.  Authentication entails
   validation of the chain of trust leading to the peer certificate,
   followed by the the peer certificate itself.  At a minimum, devices
   SHOULD use SSH-style certificate caching to guarantee consistency.
   If devices have access to a certificate authority, they SHOULD
   properly validate the trust chain.  Implementations SHOULD also
   provide a secure method for verifying that the credential in
   question has not been revoked.

   Note that if the WTP relies on the AC for network connectivity
   (e.g.  the AC is a layer 2 switch to which the WTP is directly
   connected), there is a chicken and egg problem, in that the WTP may
   not be able to contact an OCSP server or otherwise obtain an up to
   date CRL if a compromised AC doesn't explicitly permit this.  This
   cannot be avoided, except through effective physical security and
   monitoring measures at the AC.

   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.

   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.

---

From: "David T. Perkins" <[email-masked]>
Date: Wed, 14 Jun 2006 16:36:33 -0700 (PDT)

HI,

Looks like Charles has been lots of good work.
Thanks Charles!

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" 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" 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?)

> This is included as part of Issue 2. I thought I sent it to the
   <rest of message cut>

Regards,
/david t. perkins

---

From: Charles Clancy <[email-masked]>
Date: Wed, 14 Jun 2006 20:16:30 -0400

David,

If anything, I think our clock text is too specific.  Enumerating all 
the possible ways a WTP clock could be updated is out of scope, since it 
does not affect the CAPWAP protocol directly, and can be implementation 
specific.  Since it affects overall security, addressed it (but not 
trying to solve it) in the "security recommendations" section is 
appropriate.  I propose replacing the clock paragraph 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.

With regard to your second point, there are several ways to do WTP and 
AC authorization.  The EKU field authorizes a device to act as a WTP or 
an AC, but not in any particular administrative domain.  Without 
including a domain, I could go out and buy any WTP from the same vendor 
and join it to an AC.  To solve this, SSH-style key caching could be 
used on the WTP to save the AC credentials, and ACs would have to 
maintain an ACL with MACs of all authorized WTPs.  If this is easier 
than provisioning properly signed certs, then I'd feel comfortable 
removing the @DOMAIN.NET.  Remember, this section is just specifying 
security *recommendations*, not absolutes.  Maybe we should address both 
approaches, specifying how to use them securely?

-- 
t. charles clancy, ph.d.  |  [email-masked]  |  www.cs.umd.edu/~clancy

---

From: "David T. Perkins" <[email-masked]>
Date: Wed, 14 Jun 2006 22:38:16 -0700 (PDT)

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

Hope this helps. And if I totally misunderstood you, then
I apologize, and ask you to provide some examples.

Regards,
/david t. perkins

---

From: Charles Clancy <[email-masked]>
Date: Thu, 15 Jun 2006 07:52:08 -0400

There are two distinct problems: authentication and authorization. 
Validating a cert through a CA and checking its timestamps all provide 
authentication, which proves the device really is the device it claims 
to be.  The EKU and administrative domain provide authorization, which 
proves that the device can operate on a particular network.  Note that 
authorization could also be accomplished with ACLs.

 > window) then you will have a useless device (a brick).

I understand.  My point is that figuring out how to deal with this 
should be left up to the implementor.  In the security recommendations 
section, we can say "if you don't check the dates, you could be in 
trouble".  The same goes for CRLs.

There are plenty of ways a WTP can fix its clock.  NTP, clock from the 
AC, whatever.  None of them guarantee security, as they are all 
unauthenticated.  How does a WTP know when to accept an expired AC cert, 
and when not to?  To guarantee non-brick-age, it would need to always 
accept an expired cert, and then update its clock with the AC (who could 
be an attacker feeding it a date that matches its cert).

Since there's no clear solution, my advice is to leave it as 
"implementor beware".

 > on the AC). Thus, WTP CERTs MUST NOT be selfsigned.

If the manufacturer is preloading certs on to these devices, why 
wouldn't it also be preloading its own CA root cert?  Well known CAs are 
just that -- well known.  Consequenty they should all be preloaded too. 
  I don't see why any device would ever need new CA certs loaded onto 
it, unless the deployer was generating new certs for every device, using 
a local CA root.  Root certs can expire, so being able to update them 
isn't necessarily a bad thing.

 > This wasn't addressed, but

The domain in the CN is used for authorization.  It prevents me from 
going to the store, buying a WTP with preloaded manufacturer cert, 
plugging it into your network, and having your AC accept my WTP.  It 
also prevents me from going to the store, buying an AC, plugging it into 
your network, and then having all your WTPs "discover" it instead of 
your AC, and hijacking all your WTPs.

Like I said, there are other ways to do authorization.  One could use 
ACLs instead, where each AC and WTP is programmed with a list of other 
ACs and WTPs it's authorized to communicate with.  This list could be 
built somewhat automatically if implementors had a provisioning mode 
where devices would assume every cert it sees is authorized, and could 
use them to build ACLs (similar to SSH-style key caching).

I suspect different vendors will want to do it in different ways.

 > time.

If the WTP is preloaded with all the appropriate well-known and 
manufacturer CA roots, then it should be possible to validate the cert. 
  If not, you need a provisioing period, like the one I mentioned, where 
all certs are automatically accepted and cached.

 > After this first connection,

I argue that there could be many "first" connections.  What happens if 
you add or replace ACs in the network?  You still want your WTPs to talk 
to these new ACs.  But, you don't want your WTP to automatically accept 
any cert it hasn't seen before -- otherwise an attacker could come in 
and fire up their AC.

 >      of the MAC address (or other unique ID,

Seems reasonable.  However, I still think adding an administrative 
domain to the CN should be an option for those that don't want to 
maintain ACLs.

 >      the common name as a message element

Isn't the BSSID already there?  Shouldn't that match the MAC?

 >      believes its CERT or the AC's CERT is outside

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?

 >      to install an updated CERT for the WTP.

Seems reasonable.

 >   5) the CAPWAP protocol must have a new message

Seems reasonable.

Overall, my opinion is that certificate validation is a challenging 
problem.  It would probably take 40+ pages of text to address everything 
in detail, and that's not a quagmire I personally want to get into.  As 
a result, my advice is to put some broad guidance in the security 
considerations section highlighting the major issues, and leave it up to 
the implementors.  Other than the CN specification, it won't affect 
interoperability.  Vendors should figure out something that works for 
them, in their customers' environments.

---

From: Scott G Kelly <[email-masked]>
Date: Thu, 15 Jun 2006 06:02:50 -0700

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:

>      of the MAC address (or other unique ID,

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.

>      the common name as a message element

What is your objective with this requirement?

>      believes its CERT or the AC's CERT is outside

Charles addressed this.

 >   5) the CAPWAP protocol must have a new message

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

---

From: Scott G Kelly <[email-masked]>
Date: Thu, 15 Jun 2006 05:47:06 -0700

Hi David,

I think I agree with everything Charles said in reply to your concerns, 
and I won't repeat all of that, but I have a few other comments, one in 
this email and a few in one of your replies (which I'll handle there):

>          at conferences (such as the IETF).

I agree with your concern from an operational perspective, and I think 
for this reason WTP manufacturers would be well advised to provide an 
alternative management interface. Many currently provide serial ports 
for this purpose, though as you suggest, this is sometimes (actually, 
often) impractical to access. For this reason, it is probably good to 
provide an ssh-style command line capability for just this purpose, 
along with associated auditing.

We can recommend something in capwap (i.e. that it may not be prudent to 
rely on capwap as the sole mgmt interface to a WTP), but beyond than 
that, this begins to feel a bit out of scope.

>    what is the min depth that a WTP should support?)

I agree that an Internet domain is not always a convenient or 
appropriate identifier, but I think you could replace "DOMAIN.NET" with 
"DavidTPerkins" if you wanted to.

As for WTP manufacturer's pre-loading certs, we cannot realistically 
impose such requirements on them. Some already do so this, but without a 
PKI (which includes a trusted 3rd party), secure manufacturing 
processes, etc. the security of the associated credentials should not be 
over-estimated.

Scott

---

From: "Michael Montemurro" <[email-masked]>
Date: Thu, 15 Jun 2006 21:48:26 -0400

All,

I've created issue 143 to deal with this problemm.