Subject: Re: [secdir] Please review draft-ietf-capwap-protocol-specification's use of certificates

From: "Scott G. Kelly" <[email-masked]>
Date: Fri, 21 Dec 2007 16:54:45 -0500 (EST)

Hi Steve,

Thanks for taking a look at this. Regarding placement of the MAC in the CN, I would offer two observations: 

1) this is what is specified in the DOCSIS and PacketCable cert profiles, and it was on this basis that device certs for LWAPP were originally designed in this way. You can see the DOCSIS profile at www.drizzle.com/~aboba/CPW/DOCSIS.ppt

2) I don't see anything in the X.520 language that explicitly precludes this usage, so assuming that the docsis/packetcable designers reviewed that spec, I can see how they could reasonably conclude that this is acceptable. Arguably, the string representation of the MAC address is "a string chosen [by the] organization responsible for the object it describes for devices and application entities". 

Please don't misunderstand: I'm not trying to be difficult, and I have a very healthy respect for the depth of your knowledge in this area. However, there are a *lot* of devices deployed that already use this convention. It might be more pragmatic to interpret X.520 a little less restrictively.

Scott

-----Original Message-----
>From: Stephen Kent <[email-masked]>
>Sent: Dec 21, 2007 3:00 PM
>To: Sam Hartman <[email-masked]>
>Cc: [email-masked], [email-masked], [email-masked]
>Subject: Re: [secdir] Please review draft-ietf-capwap-protocol-specification's use of certificates
>
>At 9:23 PM -0500 12/20/07, Sam Hartman wrote:
>>Hi, folks.  The capwap working group is preparing to last call their
>>protocol specification draft.
>>
>>I'd appreciate review from the pkix community of section 2.4.4.3 and
>>12.6 of this draft.  These sections specify certificate validation and
>>certificate usage for the protocol.  Scott Kelly and Charles Clancy
>>are security advisors for the working group and have been heavily
>>involved.
>>
>>The capwap certificate profile assumes that the CN in the certificate
>>has structure and contains an ethernet MAC address.  The capwap
>>certificate profile also assumes that parts of the subject name such
>>as the organization and organizational unit will be important to
>>certificate matching.
>>
>>I'd appreciate review and comments.
>>
>>--Sam
>
>It would be preferable to get an allocated name space for MAC 
>addresses, under the OtherName or, better yet, under registeredID.
>
>I'd argue that it is inappropriate to put a MAC address into a CN. 
>The text from X.520 makes this clear:
>
>The Common Name attribute type specifies an identifier of an object. 
>A Common Name is not a directory name; it is a (possibly ambiguous) 
>name by which the object is commonly known in some limited scope 
>(such as an organization) and
>conforms to the naming conventions of the country or culture with 
>which it is associated.
>
>An attribute value for common name is a string chosen either by the 
>person or organization it describes or the organization responsible 
>for the object it describes for devices and application entities. For 
>example, a typical name of a
>person in an English-speaking country comprises a personal title 
>(e.g., Mr., Ms., Rd, Professor, Sir, Lord), a first name, middle 
>name(s), last name, generation qualifier (if any, e.g., Jr.) and 
>decorations and awards (if any e.g., QC).
>
>Examples
>CN = "Mr. Robin Lachlan McLeod BSc(Hons) CEng MIEE"
>CN = "Divisional Coordination Committee"
>CN = "High Speed Modem".
>
>If there is a very strong desire to make use of an existing attribute 
>in the X.502 space, the SerialNumber attribute makes more sense. So 
>long as we are talking about long, term, stable MAC addresses 
>assigned to devices by manufacturers, this is consistent with the 
>semantics of that attribute.  Moreover, we have advised folks to use 
>SerialNumber to represent data such as employee/student IDs in the 
>past, so one might expect to see support for this attribute in many 
>CAs and clients.
>
>Steve

---

From: "Ogle Ron" <[email-masked]>
Date: Sat, 22 Dec 2007 23:29:20 -0500

I would agree with Scott.  I have personally created over 20M (that's
million) certificates over 4 complete IEEE OUIs with the MAC address in
the CN of the certificate subject DN.  Besides the US version of DOCSIS,
we use the same setup for the European equivalent.  We actually have 5
different setups, US DOCSIS, EU DOCSIS, US Packet Cable, EU Packet
Cable, and Cable Home operated under Cable Labs and tComLabs.

We are also starting to expand the use to other set top boxes and other
consumer type products that have MAC addresses.  I would suggest that
the CAPWAP program remove the ":" from the MAC address.  I would also
suggest that this profile be moved under PKIX because as you can see
there are several systems using it.  We already have cable modems and
set top boxes used as wireless access points, it would be a shame to
have yet another certificate for the exact same device.

Thanks
Ron Ogle
Product Security
Thomson Inc.

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Scott G. Kelly
> Sent: Friday, December 21, 2007 4:55 PM
> To: Stephen Kent; Sam Hartman
> Cc: [email-masked]; [email-masked]; [email-masked]
> Subject: Re: [secdir] Please review 
> draft-ietf-capwap-protocol-specification's use of certificates
> 
> 
> Hi Steve,
> 
> Thanks for taking a look at this. Regarding placement of the 
> MAC in the CN, I would offer two observations: 
> 
> 1) this is what is specified in the DOCSIS and PacketCable 
> cert profiles, and it was on this basis that device certs for 
> LWAPP were originally designed in this way. You can see the 
> DOCSIS profile at www.drizzle.com/~aboba/CPW/DOCSIS.ppt
> 
> 2) I don't see anything in the X.520 language that explicitly 
> precludes this usage, so assuming that the docsis/packetcable 
> designers reviewed that spec, I can see how they could 
> reasonably conclude that this is acceptable. Arguably, the 
> string representation of the MAC address is "a string chosen 
> [by the] organization responsible for the object it describes 
> for devices and application entities". 
> 
> Please don't misunderstand: I'm not trying to be difficult, 
> and I have a very healthy respect for the depth of your 
> knowledge in this area. However, there are a *lot* of devices 
> deployed that already use this convention. It might be more 
> pragmatic to interpret X.520 a little less restrictively.
> 
> Scott
> 
> >Subject: Re: [secdir] Please review 
> draft-ietf-capwap-protocol-specification's use of certificates
> >

---

From: Stephen Kent <[email-masked]>
Date: Wed, 26 Dec 2007 14:06:26 -0500

>have yet another certificate for the exact same device.

I would suggest that future cert profiles developed for other devices 
not perpetuate this error.

Steve

---

From: Stephen Kent <[email-masked]>
Date: Wed, 26 Dec 2007 14:03:14 -0500

At 4:54 PM -0500 12/21/07, Scott G. Kelly wrote:
>1) this is what is specified in the DOCSIS and PacketCable cert 
>profiles, and it was on this basis that device certs for LWAPP were 
>originally designed in this way. You can see the DOCSIS profile at 
>www.drizzle.com/~aboba/CPW/DOCSIS.ppt

I was not aware that DOCSIS and PacketCable had created cert profiles 
using this convention. That provides a strong rationale for CAPWAP 
specs to be compatible where the two overlap, i.e., in terms to certs 
provisioned in WTPs and ACs. Since this is the rationale for this 
questionable use of the CN field, the document should include cites 
to the relevant DOCSIS and PacketCable specs, and say that this 
convention has been employed here because these specs have caused 
numerous devices to be provisioned with certs of this form.

>designers reviewed that spec, I can see how they could reasonably 
>conclude that this is acceptable. Arguably, the string 
>representation of the MAC address is "a string chosen [by the] 
>organization responsible for the object it describes for devices and 
>application entities".

One ought not expect the writers of X.520 to anticipate every 
questionable use of an attribute and say "no, don't do this" so I 
don't think your observation above is a valid argument in favor of 
using CN here. Also, the text for common name starts by saying "A 
Common Name is not a directory name; it is a (possibly ambiguous) 
name by which the object is commonly known in some limited scope 
(such as an organization) and conforms to the naming conventions of 
the country or culture with which it is associated." This text, which 
precedes the text you cite, makes it clear that a MAC address should 
not be represented as a common name. A vendor assigning a MAC 
generally does so in a globally unique fashion, which contradicts the 
"limited scope" concept cited in the standard. A MAC address is not 
at all congruent with the allusions to "naming conventions of the 
country or culture with which it is associated" part of the 
description of the common name attribute.

The usual argument for putting a value in an attribute where it is 
inappropriate is because preferable choices for where to put the 
value are not commonly supported.  So, for example, if you were 
dealing with version 1/2 certs, rather than version 3, the use of 
otherName or registeredID would not be available.  But, the 
serialNumber attribute has always been available.

I looked at the DOCSIS and PacketCable slides for which you provided 
the URL.  I see that the DOCSIS profile for cable modems calls for 
two CN attributes in the cert. If one argues that here is a need to 
use only widely supported attribute types (hence a rationale for 
using common name over serial number for the MAC address), then one 
ought not take an attribute that would NOT be repeated in a DN, and 
insert two instances of it, as was done here.

>Please don't misunderstand: I'm not trying to be difficult, and I 
>have a very healthy respect for the depth of your knowledge in this 
>area. However, there are a *lot* of devices deployed that already 
>use this convention. It might be more pragmatic to interpret X.520 a 
>little less restrictively.

I'm not trying to be difficult either.Sam asked PKIX to review 
PKI-specific parts of the spec and I did. I expect the IESG to ignore 
my objection,
given the deployed base you and others cite. But let's be honest and 
recognize that this was an error, probably based on bad advice given 
to by the DOCSIS folks.  Also note that PKIX RFCs have taken a strong 
stand against putting inappropriate values into the CN field in the 
past, e.g., stuffing an e-mail address there, despite the fact that 
lots of certs were issued tha way.

Steve

---

From: Stephen Kent <[email-masked]>
Date: Wed, 26 Dec 2007 14:44:31 -0500

At 11:25 AM -0800 12/26/07, Bernard Aboba wrote:
>>  my objection, given the deployed base you and others cite. But 
>>let's be honest and
>If there really is a belief that this is an error, then the right 
>thing to do is for the
>IETF (and PKIX WG) to inform the organizations involved (which now include
>IEEE 802 as well as DOCSIS) of the error, as well as to suggest the correct
>way of doing things.   That way, the error might get fixed.
>
>Merely fixing the CAPWAP protocol spec is only likely to make the
>situation worse, not better, because then we'd have two ways of doing
>the same thing with more on the way.

I agree that making capwap right is problematic, given the extant 
PKIs that have been crated.

However there should be no question that use of the CN to encode a 
MAC address in an X.509 cert is inappropriate. I think the cited text 
is pretty clear on that point, not to mention the inclusion of two 
CNs in the cable model cert spec!

Who, specifically, do you suggest that we contact at each organization?

Steve

---

From: Stephen Kent <[email-masked]>
Date: Wed, 26 Dec 2007 16:02:03 -0500

At 11:59 AM -0800 12/26/07, Bernard Aboba wrote:
>>  PKIs that have been created.
>>
>For IEEE 802.1ar, the contact is the chair of the IEEE 802.1, Tony 
>Jeffree or the Vice-Chair, Paul Congdon ([email-masked]). 
>
>For IEEE 802.16, it would be the Chair, Roger Marks. 
>
>As the IETF liaison to IEEE 802, I can help in email'ing the folks 
>above, assuming that there is a communication to share from PKIX WG.
>
>For the WiMAX Forum it would be Russ Housley, who is currently 
>authoring the device and server certificate documents.

Thanks, I'l work with Tim Polk and Russ to follow through.

Steve

---

From: "Ogle Ron" <[email-masked]>
Date: Thu, 27 Dec 2007 01:15:35 -0500

Steve, there maybe a fleeting opportunity with DOCSIS in the new spec
3.0 to right the wrong.  The BPI (basic privacy) part of DOCSIS deals
with using the X.509 certs.  BPI is being altered for 3.0, and there
most manufacturers haven't fully started making 3.0 compatible modems.

If you are interested, I can help facilitate a meeting with the Cable
Labs security folks who write these specs.  Very soon all consumer
electronics products with a network connection will probably end up with
a certificate.  I know that we are moving that direction now.  I know
that Cable Labs isn't fully using the value of the current cert because
of various problems, but they plan on making better use in the near
future.

I do think though that PKIX should pull the profile out of CAPWAP, and
define a compatible profile.  This way multiple rfcs can reference the
profile.  This way DOCSIS, Cable Home, OpenCable, PacketCable, CAPWAP,
and others could all run from the same profile for device oriented
certificates.

Ron Ogle
Thomson Product Security

> [mailto:[email-masked]] On Behalf Of Stephen Kent
> Sent: Wednesday, December 26, 2007 2:03 PM
> To: Scott G. Kelly
> Cc: Sam Hartman; [email-masked]; 
> [email-masked]; [email-masked]
....

---

From: Stephen Kent <[email-masked]>
Date: Thu, 27 Dec 2007 09:54:11 -0500

>and others could all run from the same profile for device oriented

Ron,

Thanks for the info re the 3.0 update of DOCSIS. Also feel free to 
point the Cable Labs security folks to the latest PKIX spec in this 
area, 3280bis, which has just completed IETF last call.

PKIX usually let's other WGs in the IETF develop profiles of our 
profile of X.509, when necessary for a given context. See the ongoing 
efforts in  the SIDR WG as an example, and similar work in the SIP 
arena too.  So it would be unusual for PKIX to take on the task of 
developing profiles for DOCSIS, PacketCable,Cable Home, and 
OpenCable.  However, if there is not a suitable, extant IETF WG where 
this can be done, we might make an exception (if the PKIX membership 
and our cognizant AD agrees).  In any case, these folks should feel 
free to solicit review of their profiles if they are concerned about 
compatibility with IETF protocols.

Steve