Subject: [Capwap] Comments on Cert Management

From: "David T. Perkins" <[email-masked]>
Date: Mon, 6 Nov 2006 16:01:10 -0800 (PST)

HI,

To be complete, the CAPWAP proto spec or a companion
document MUST support and describe management of
X.509 certs. It must be specified how to replace or
augment the original cert placed in a WTP during
the manufacturing process. How to recover if WTP
cert or the CA cert used by the WTP has expired.
How to add additional CA certs on the WTP (and
remove old ones).

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: "Pat Calhoun (pacalhou)" <[email-masked]>
Date: Sat, 18 Nov 2006 13:51:59 -0800

My view is support for certificates is mandatory, but I do agree with
the management of the certificates can wait. Pre-shared keys can be
supported, but not as the only mechanism.

Pat Calhoun
CTO, Wireless Networking Business Unit
Cisco Systems

> -----Original Message-----
> From: David T. Perkins [mailto:[email-masked]] 
> Sent: Tuesday, November 07, 2006 11:59 PM
> To: Scott G. Kelly
> Cc: [email-masked]
> Subject: Re: [Capwap] Comments on Cert Management
> 
> HI,
> 
> I'm going to cut at bit of your response and get to the\ key 
> piece, which an response to the question
> > >What is the smallest
> > >set of operations do you see that we can get by with?
> > 
> In your response, you have many cert issues, but only a 
> couple of issues that are "cert management operations"
> that I believe are needed to be added to the CAPWAP protocol.
> 
> > I think the problem is that this opens a can of worms. 
> > Like I said, I agree whole-heartedly that this must eventually be 
> > addressed, but I think to do so now would take us far beyond the 
> > bounds of our current charter.
> > 
> > To begin, you can say that it must be possible to download certs to 
> > APs. Sounds simple, right? But it's not. Here are just a few of the 
> > questions that need to be answered:
> > 
> > - what is the format of the certs? Are they der-encoded,
> >    pem-encoded, etc?
> This is pretty easy - choose one as mandatory and make the 
> other optional, or even easier - make both mandatory!
> 
> > - what about private keys? Does the AC generate the
> >    private key and pkcs-12 encode the AP's new cert/key,
> >    and if so, what's the passphrase?
> Good question, but I believe that it is already solved in 
> existing vendor products. One that I'm familure with sends 
> the cert (and private key) in PKCS-12 and sends the 
> passphrase to unwrap it. Note it also supports a command to 
> have the WTP generate a self-signed cert, and supports a 
> command to have the WTP generate a cert request in PKCS-10 
> format and then loading of a signed cert in PKCS-7 format. 
> Finally, it allows a CA cert to be loaded on the WTP for 
> verification of an AC's cert.  That is, the above are 
> existing operations that just need CAPWAP message operations 
> and syntax defined! 
> 
> > - how many certs/keys should an AP be allowed to have,
> >   and how does it choose which one to use for a given AC?
> I don't believe this has anything to do with cert management 
> operations. This is an existing issue.
> 
> > - if the AP wants to generate its own private key
> >   (not an uncommon expectation), how do we implement enrollment?
> Note, I believe that "enrollment" is not a term with 
> universally agreed meaning. But if you mean have the WTP 
> generate a key and a cert request in PKCS-10 format, then I 
> believe that is is already done. If you mean something else, 
> please explain.
> 
> > - how deep a CA hierarchy MUST be supported?
> This is an existing issue. Also, what must be the base set of 
> CA certs supported by a WTP.
> 
> > - what EKU fields are mandatory to support, which are optional?
> This is an existing issue.
> 
> > - what goes in the DN? 
> I thought this was finally resolved in the -03 spec.
> 
> > - What goes in the subjectAltName? What about the other fields?
> This is an existing issue. By the way, I'd say the DNS name, 
> and other fields can be present, but are ignored.
> 
> > - which cert fields do ACs/WTPs use for 
> identification/policy look-up?
> This is an existing issue, but again, I believe this was 
> adressed in the -03 spec.
> > 
> > - what about CRL's and/or OCSP?
> This is an existing issue.
> 
> > - what happens if the AP/AC doesn't recognize something in the cert?
> This is an existing issue.
> 
> > - is there a minimum key size? Is there a maximum?
> This is an existing issue.
> 
> > Again, these are *some* of the questions we must answer to get to 
> > interoperability with certificates. I think we're already headed 
> > toward a minimal interoperable spec in the current drafts, 
> by simply 
> > specifying basic DN and EKU requirements.
> We need both a way via CAPWAP to "put" a cert for the WTP and 
> CA certs to verify AC certs in the WTP, and requirements for 
> the contents of the WTP and AC certs.
> 
> > Your original post said these issues need to be addressed 
> in the base 
> > spec, and this is what I disagree with. I agree they need to be 
> > addressed, but I think this is new work, should be done after and 
> > independently of the base spec (and 802.11 binding) and I think it 
> > would likely require a charter update.
> We differ. I want a spec that is complete enough so I can 
> have interoperable products. To me, it looks like you want 
> only enough in the base spec to "demonstrate" the technology. 
> Again, I want shipable and maintainable interoperable 
> products. I don't want to use a vendor specific method to put 
> certs on WTPs. Likewise, I don't want to use vendor specific 
> methods to put system images on WTPs.
> 
> > Again, please look at the history of
> > the ipsec and pki4ipsec history. Take a look at
> > 
> > 
> http://www.ietf.org/internet-drafts/draft-ietf-pki4ipsec-mgmt-profile-
> > rqts-06.txt
> This was a quite easy to read and understand spec. Using the 
> terminology from that spec, I believe that CAPWAP needs to 
> include the operations that implement the "protocol"
> between the "Admin" and "IP sec peer 1" as described in section 3.3.1.
> In summary, this spec describes all of the work and process 
> that must be done (and is outside of the scope of CAPWAP) to 
> deploy and operate a secure system. And this spec calls for a 
> single protocol between the "Admin" and "IP sec peer", and 
> CAPWAP should do this. NOTE: for you literalists - in the 
> CAPWAP world the "Admin" is the AC and the "IP sec peer" is the WTP.
> 
> > and
> > 
> > 
> http://www.ietf.org/internet-drafts/draft-ietf-pki4ipsec-ikecert-profi
> > le-11.txt
> > 
> > to get a feel for the magnitude of this problem.
> > 
> > Scott
> 
> In summary, I believe CAPWAP needs maybe 5 or 6 new 
> operations to put certs in WTPs, and I believe that this is an "easy"
> addition that must be in the first release so CAPWAP 1.0 will 
> allow the creation of product level interoperable WTPs and 
> ACs. Can't we just make it happen.
> 
> Regards,
> /david t. perkins
>