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

From: "Pat Calhoun (pacalhou)" <[email-masked]>
Date: Mon, 10 Mar 2008 15:04:16 -0700

Great, I will update Issue tracker accordingly.

PatC 

-----Original Message-----
From: Sam Hartman [mailto:[email-masked]] 
Sent: Monday, March 10, 2008 5:29 AM
To: Pat Calhoun (pacalhou)
Cc: capwap
Subject: Re: [Capwap] Issue 35: MAC Address in Certificate CN field

>>>>> "Pat" == Pat Calhoun (pacalhou) <[email-masked]> writes:

    Pat> Sam,
    Pat> May I simply adopt your proposed text below and close this
issue?
Sure.
_________________________________________________________________
To unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/capwap

Archives: http://lists.frascone.com/pipermail/capwap

---

From: Sam Hartman <[email-masked]>
Date: Mon, 10 Mar 2008 08:28:46 -0400

>>>>> "Pat" == Pat Calhoun (pacalhou) <[email-masked]> writes:

    Pat> Sam,
    Pat> May I simply adopt your proposed text below and close this issue?
Sure.

---

From: <[email-masked]>
Date: Wed, 12 Mar 2008 14:44:38 -0500

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 

>From: ext Pat Calhoun (pacalhou) [mailto:[email-masked]] 
>Sent: 15 February, 2008 09:14
>To: Pat Calhoun (pacalhou); Sam Hartman
>Cc: capwap
>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 
>
>From: Pat Calhoun (pacalhou)
>Sent: Tuesday, February 12, 2008 9:16 PM
>To: Sam Hartman
>Cc: capwap
>Sam,
>May I simply adopt your proposed text below and close this issue?
>
>PatC 
>
>Sent: Thursday, January 03, 2008 5:19 AM
>    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.

---

From: "Pat Calhoun (pacalhou)" <[email-masked]>
Date: Wed, 12 Mar 2008 13:53:18 -0700

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: [email-masked] [mailto:[email-masked]]

Sent: Wednesday, March 12, 2008 12:45 PM
To: Pat Calhoun (pacalhou); [email-masked]
Cc: [email-masked]
Subject: RE: [Capwap] Issue 35: MAC Address in Certificate CN field

Best Regards,
Michael 

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