| Re: Fwd: Comments on draft-ietf-capwap-protocol-specification | <– Date –> <– Thread –> |
|
From: Pat Calhoun (pacalhou) (pcalhoun |
|
| Date: Fri, 21 Dec 2007 07:41:22 -0800 (PST) | |
I have created a series of tracker entries 1) Issue 33 2) Issue 34 3) Issue 35 4) Issue 36 5) Issue 37 PatC -----Original Message----- From: Margaret Wasserman [mailto:margaret [at] thingmagic.com] Sent: Friday, December 21, 2007 3:04 AM To: capwap Cc: hartmans-ietf [at] mit.edu Subject: [Capwap] Fwd: Comments on draft-ietf-capwap-protocol-specification Forwarded for Sam Hartman, who is not on the CAPWAP WG mailing list. Margaret Begin forwarded message: > From: Sam Hartman <hartmans-ietf [at] mit.edu> > Date: December 20, 2007 9:44:56 PM EST > To: capwap [at] frascone.com > Cc: capwap-chairs [at] tools.ietf.org > Subject: Comments on draft-ietf-capwap-protocol-specification > > > Hi. I was looking at the certificate validation in version 08 of the > protocol spec and wanted to report these comments to the WG for > consideration. > > > 1) The document really should have a table of contents. Table of > contents are an important part of making reviewers lives easier > looking at what a document covers. Please please fix this before > ietf last call. > > 2) Section 2.4.4.3 should specify the handling of the > anyExtendedKeyUsage keyPurposeID. > > 3) The naming rules in section 2.4.4.3 seem to be somewhat I'm > 3) confused by the certificate naming in 2.4.4.3. It seems that > 3) certificates are expected to have a MAC address in the CN field of > 3) the certificate. > > * How does a WTP know which MAC address it expects the AC to have? > This seems reasonably obvious if they are on-link, but what about > when there is a router in between? Is the client actually going to > know that it is connecting to a specific MAC? How is this name > bound to something the WTP actually knows it is trying to access? > > * ISn't the MAC address rather specific to the 802.11 application? Is > it really an appropriate name to use for other uses of capwap? > Again, how will you know that the authorization is used the right > way? > > * This is a minor point, but how do you handle an AC (or non-802.11 > WTP) that does not have a MAC address? > > > > > 4) I expected to find some discussion of trust anchors in the document > and was surprised not to see any. Also, I expected to find some > reference to the certificate validation algorithm in RFC 3280. The > second point is minor; there is certificate validation text and it > may well be good enough. The point about discussing trust anchors > is bigger. > > I do realize that trust anchors are a difficult topic. If I get a WTP > that has never been configured and arrives in a box from some > manufacturer, how exactly is it supposed to know who to trust at my > cite. You should say something though or have an explanation of why > you couldn't say anything. > > 5) The ssh-style leap of faith caching is great for initial > configuration. However it tends to be problematic for supporting > key rollover. > Has any thought been given to how long to cache leap of faith entries > in capwap or how to support key and certificate rollover in this > situation? > > Thanks for your consideration, > > --Sam _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap
-
Fwd: Comments on draft-ietf-capwap-protocol-specification Margaret Wasserman, December 21 2007
- Re: Fwd: Comments on draft-ietf-capwap-protocol-specification Pat Calhoun (pacalhou), December 21 2007
- Re: Fwd: Comments on draft-ietf-capwap-protocol-specification Scott G. Kelly, December 21 2007
Results generated by Tiger Technologies using MHonArc.