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

[Scott G. Kelly (s.kelly]

Hi Sam,

Thanks for taking time out of your very busy schedule to review this very long 
document. Rather than in-lining responses, I'll try to summarize here.

Before addressing individual items, I think it would be helpful to give you 
some background. This set of specs derives from the LWAPP protocol, which was 
first documented in the IETF early in 2003 (if memory serves). LWAPP used a 
proprietary security protocol which relied on certs for authentication, but did 
not support pre-shared keys.

Not long after LWAPP was selected as the basis for CAPWAP, the working group 
decided to replace this proprietary security protocol with DTLS. However, 
efforts were made to minimize the disruption to LWAPP (inasmuch as that was 
even possible). Hence, numerous artifacts survived (e.g. the MAC address in the 
CN of the certs). At least one vendor has lots of devices commercially deployed 
which already contain such certs, and we want to accommodate this.

More than a year ago, there were questions on the mailing list very similar to 
yours with respect to trust anchors, cert lifecycle mgmt, and other topics.  I 
don't think I was alone in my feeling that the topics are sufficiently complex 
that they would not be addressed in a few paragraphs, and represent a 
significant work item in their own right. I think we had general agreement 
that, while these topics must be addressed in order to guarantee cross-vendor 
interoperability, they are not essential to getting usable protocol specs out.

Like any working group, we've had a limited amount of energy available, and 
fully specifying cert usage will require significant effort. Deferring this 
work while still allowing for (and providing rough guidelines for) cert use is 
meant to be a pragmatic compromise. We can achieve interoperability today using 
pre-shared keys, and perhaps even some limited interoperability with certs 
based on this rough outline. I think we've been assuming we could more fully 
address certificate usage as a potential work item in a re-chartering 
discussion. 

Now, with respect to your individual points:

> 2)  Section 2.4.4.3  should specify the handling of the
>     anyExtendedKeyUsage keyPurposeID.

In keeping with our desire to defer details not essential to the most basic 
interoperability, use of key purpose IDs that are not essential to CAPWAP 
operation seem like good candidates for discussion in a re-chartered group. If 
you think it's strictly necessary, we could say that this kpID MAY be present, 
and SHOULD be ignored, but if we later decide that it SHOULD NOT or MUST NOT be 
present, that will cause problems. It might be better to just remain silent for 
now.

For item 3, yes, certs are expected to have MAC addresses in the CN field, and 
this is an artifact of LWAPP (which was initially an L2 protocol, later adapted 
for L3). As for what MAC the AP "expects", we have not specified this, and I 
expect that is fair game for a re-chartering discussion. However, you raise a 
good point: unless WTPs are preconfigured with this MAC address and use that as 
a basis for comparison, it is meaningless for the AC to have this in its cert 
(aside from its value in  auditing). For the WTP's cert, as Pat pointed out, 
the WTP MAC can be in a pre-configured policy on the AC (or on a AAA server).

On your comment regarding the MAC being specific to 802.11, nice catch! We've 
all been staring at this for so many years that I think that point eluded us. 
If this is to remain, we may want to move this to the 802.11 binding document.

As for the authorization question, we have chosen to punt on that for now. 
Again, to fully specify cert usage will probably require a document of 
significant size, and a significant effort on the part of the working group.

As for caching, rollover, etc., these are things we've chosen to punt to a 
re-chartered group. We could add a few lines suggesting offline provisioning of 
trust anchors and initial credentials, but it's not clear where to draw the 
line on such discussions.

If you believe that fully specifying the details around trust anchors and 
certificate lifecycles is a necessary precursor to publishing the base specs, 
then I think this wg may want to consider entirely removing certificate 
discussions from the first rev of the specs (and only support preshared keys) 
so that we can publish, and move the certificate discussion to a re-charter 
discussion. However, I hope this is not the case.

If you agree with the basic premise (it is possible to publish specs which only 
outline cert usage, and we can follow up later with more detailed specs), does 
that alter your view of what is required?

Thanks again for taking the time to review this,

Scott


-----Original Message-----
>From: Margaret Wasserman <margaret [at] thingmagic.com>
>Sent: Dec 21, 2007 3:03 AM
>To: capwap <capwap [at] frascone.com>
>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