Subject: Re: [Capwap] Comments on Cert Management

From: "Scott G. Kelly" <[email-masked]>
Date: Tue, 7 Nov 2006 11:34:14 -0800 (GMT-08:00)

Hi David,

-----Original Message-----
>From: "David T. Perkins" <[email-masked]>
>Sent: Nov 6, 2006 5:10 PM
>To: "Scott G. Kelly" <[email-masked]>
>Cc: [email-masked]
>Subject: Re: [Capwap] Comments on Cert Management
>
>HI,
>
>While, techincally you can get DTLS to work with preshared
>keys, I don't believe that this would be a deployment
>scenario.

I agree that it does not represent a secure *scalable* deployment scenario,  but I would stop there. And again, I do believe we must address certificate-related issues eventually, but I think we should defer this for the time being.

>I believe that you are making the issue of cert
>management way much harder than what is needed.
>
>The big issue is that CAPWAP needs a limited bit
>of cert management. It doesn't need a complete
>cert management protocol. What is the smallest
>set of operations do you see that we can get
>by with?

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?

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

- how many certs/keys should an AP be allowed to have, and how does it choose which one to use for a given AC?

- if the AP wants to generate its own private key (not an uncommon expectation), how do we implement enrollment?

- how deep a CA hierarchy MUST be supported?

- what EKU fields are mandatory to support, which are optional?

- what goes in the DN? What goes in the subjectAltName? What about the other fields?

- which cert fields do ACs/WTPs use for identification/policy look-up?

- what about CRL's and/or OCSP?

- what happens if the AP/AC doesn't recognize something in the cert?

- is there a minimum key size? Is there a maximum?
 ------------------------------------------------------------

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. 

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

and

http://www.ietf.org/internet-drafts/draft-ietf-pki4ipsec-ikecert-profile-11.txt

to get a feel for the magnitude of this problem.

Scott

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

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

---

From: "David T. Perkins" <[email-masked]>
Date: Tue, 7 Nov 2006 23:59:20 -0800 (PST)

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

> to get a feel for the magnitude of this problem.

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