Capwap Mailing List: Re: Issue 35: MAC Address in Certificate CN field

[Pat Calhoun (pacalhou) (pcalhoun]

The text reads that the protocol MUST provide the means for the MAC
address to be validated against the ACL. However, it is up to the
operator to determine whether he/she wants to leave the ACL to permit
'*' or setup a more restrictive list.

<text>
   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.  However, at
   minimum, all devices MUST verify that the appropriate EKU bit is set
   according to the role of the peer device (AC vs. WTP), and that the
   issuer of the certificate is appropriate for the domain in question.
</text>

I have made the requested change below to the draft.

Thanks Sam,

PatC 

-----Original Message-----
From: Sam Hartman [mailto:hartmans-ietf [at] mit.edu] 
Sent: Thursday, January 03, 2008 5:19 AM
To: Pat Calhoun (pacalhou)
Cc: capwap
Subject: Re: [Capwap] Issue 35: MAC Address in Certificate CN field

>>>>> "Pat" == Pat Calhoun (pacalhou) <pcalhoun [at] cisco.com> writes:

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

Ah.
This was not obvious to me.
If the intent is to validate against an ACL, then I think the following
requirement  does not rise to the level needed for an RFC 2119 MUST:

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


In particular, that's a requirement on operational deployments rather
than a requirement on implementations and if all you are going to do is
to check against an ACL then I don't see a need for that requirement.

Perhaps something more like the following would be an appropriate
requirement to meet interoperability:



>   Capwap implementations MUST support certificates where the  common
name (CN) for both the WTP and AC is the
>   MAC address of that device.  The MAC address MUST be formatted as
>   ASCII HEX, e.g. 01:23:45:67:89:ab.


You should be aware that there is a raging debate in the security
directorate about whether storing MAC addresses in a CN field is
appropriate for a mandatory to implement solution.  I have not read that
debate so I don't know if there is a consensus there one way or another.