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

From: "Pat Calhoun (pacalhou)" <[email-masked]>
Date: Mon, 9 Oct 2006 14:47:00 -0700

I'm ok with Dorothy's proposed recommendations.

Pat Calhoun
CTO, Wireless Networking Business Unit
Cisco Systems

________________________________

	From: Dorothy Stanley [mailto:[email-masked]] 
	Sent: Tuesday, October 03, 2006 3:28 PM
	To: capwap
	Subject: [Capwap] Proposed Resolution to Issue 143:
Specification for theusage of CERTS for CAPWAP/was CERT issues in
CAPWAP-01

	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
	<http://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]
<mailto:[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