Capwap Mailing List: Fwd: Comments on draft-ietf-capwap-protocol-specification

[Margaret Wasserman (margaret]

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