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

[Pat Calhoun (pacalhou) (pcalhoun]

Correct. It states that the MAC Address MUST be supported, not that it
MUST be used.

This has been the identifier used since the original spec, and honestly
do not see a reason to change it. If folks want to use another format,
they can.

PatC 

-----Original Message-----
From: Michael.G.Williams [at] nokia.com [mailto:Michael.G.Williams [at] 
nokia.com]

Sent: Wednesday, March 12, 2008 12:45 PM
To: Pat Calhoun (pacalhou); hartmans-ietf [at] mit.edu
Cc: capwap [at] frascone.com
Subject: RE: [Capwap] Issue 35: MAC Address in Certificate CN field

Just to be clear, this doesn't mandate the CN field to be MAC, it just
says that if the CN in a MAC it has to be EUI 48 or 64, correct?

For the record, I think it's a bad idea to be using the MAC address for
the identity here. Also, as was pointed out, even if the CN is a MAC
address it's not reasonable to assume the MAC address presented is being
used by the peer, is unique, is 'valid', etc etc. It's meant as an
address for local link usage. Rather than overloading it there should be
things used for the right purpose instead.

Best Regards,
Michael 

>-----Original Message-----
>From: ext Pat Calhoun (pacalhou) [mailto:pcalhoun [at] cisco.com]
>Sent: 15 February, 2008 09:14
>To: Pat Calhoun (pacalhou); Sam Hartman
>Cc: capwap
>Subject: Re: [Capwap] Issue 35: MAC Address in Certificate CN field
>
>All,
>
>The new text reads:
>
>   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.  Note that the CN field MAY contain either of the
>   EUI-48 [22] or EUI-64 [23] MAC Address formats.
>
>PatC
>
>-----Original Message-----
>From: Pat Calhoun (pacalhou)
>Sent: Tuesday, February 12, 2008 9:16 PM
>To: Sam Hartman
>Cc: capwap
>Subject: Re: [Capwap] Issue 35: MAC Address in Certificate CN field
>
>Sam,
>
>May I simply adopt your proposed text below and close this issue?
>
>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.
>_________________________________________________________________
>To unsubscribe or modify your subscription options, please visit:
>http://lists.frascone.com/mailman/listinfo/capwap
>
>Archives: http://lists.frascone.com/pipermail/capwap
>_________________________________________________________________
>To unsubscribe or modify your subscription options, please visit:
>http://lists.frascone.com/mailman/listinfo/capwap
>
>Archives: http://lists.frascone.com/pipermail/capwap
>