Subject: [Capwap] Issue 35: MAC Address in Certificate CN field

From: "Pat Calhoun (pacalhou)" <[email-masked]>
Date: Fri, 21 Dec 2007 08:13:22 -0800

Sam,

There is no expectation that the AC or WTP actually validate the MAC
address in the 802.3 packet. In fact the text states:

<existing text>
2.4.4.3.  Certificate Usage
[...]
   ACs and WTPs MUST authorize (e.g. through access control lists)
   certificates of devices to which they are connecting, e.g., based on
   the issuer, MAC address, or organizational information specified in
   the certificate.  The identities specified in the certificates bind a
   particular DTLS session to a specific pair of mutually-authenticated
   and authorized MAC addresses.  The particulars of authorization
   filter construction are implementation details which are, for the
   most part, not within the scope of this specification.
</existing text>

The intention is the for AC and WTPs to validate the CN through an
access
control list. This could be done via a RADIUS request, a locally stored
MAC address list, etc. As long as the certificate is valid, and
authorized,
it really doesn't matter whether the device in question is actually
using
the MAC address encoded in the CN field, and as you state, this is not
possible to do if a router is present.

The MAC address is not 802.11 specific. Ethernet devices have MAC
addresses,
and the implementations that I am familiar with use the primary Ethernet
port's MAC address in its certificate. However, if the device is WLAN or
even
WiMAX, they would still have a MAC address. Should a box be created that
has
no MAC address (not sure what link layer it would be using, but let's
pretend),
then the manufacturer could still request a MAC address per device.

Note that I have made a small, necessary, change to support both MAC
Address
formats:

<proposed text>
2.4.4.3.  Certificate Usage
[...]
   The certificate common name (CN) for both the WTP and AC MUST be the
   MAC address of that device.  The MAC address MUST be formatted as
   ASCII HEX, e.g. 01:23:45:67:89:ab.  Note that the CN field MAY
contain
   either of the EUI-48 [22] or EUI-64 [23] MAC Address formats.
</proposed text>

So other than the above minor change, I believe that the current text is
sufficient. 

Thoughts?

PatC

> 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?
_________________________________________________________________
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: Fri, 21 Dec 2007 08:15:14 -0800

Re-sending, but including Sam as I do not know whether he is on the
CAPWAP list.

PatC  

-----Original Message-----
From: Pat Calhoun (pacalhou) 
Sent: Friday, December 21, 2007 8:13 AM
To: capwap
Subject: [Capwap] Issue 35: MAC Address in Certificate CN field

Sam,

<existing text>

The intention is the for AC and WTPs to validate the CN through an
access control list. This could be done via a RADIUS request, a locally
stored MAC address list, etc. As long as the certificate is valid, and
authorized, it really doesn't matter whether the device in question is
actually using the MAC address encoded in the CN field, and as you
state, this is not possible to do if a router is present.

The MAC address is not 802.11 specific. Ethernet devices have MAC
addresses, and the implementations that I am familiar with use the
primary Ethernet port's MAC address in its certificate. However, if the
device is WLAN or even WiMAX, they would still have a MAC address.
Should a box be created that has no MAC address (not sure what link
layer it would be using, but let's pretend), then the manufacturer could
still request a MAC address per device.

<proposed text>

Thoughts?

PatC