Why MAC addresses do not belong in certificates

A few weeks ago I was on a thread in the EMU working group within the IETF where the topic of MAC addresses in certificates came up.

I understand the desire, on the surface one sees MAC addresses as unique device identifiers; it sounds natural after all they have namespace assignment rules that say that you must create only unique values but despite this they really don't belong.

When exploring the idea of a MAC address being included in a certificate the following problems come to mind:

  • No framework today exists today to validate a device is entitled to a given MAC address, specifically a MAC address is normally constructed from a  IANA assigned number identifying the vendor, the vendor generates and assigns a device specific value and the MAC address is constructed from these two values because of this model this property is missing.
  • A relying party has no way to verify that the manufacturer of the device is in-fact the registered owner of the vendor id (OUI), nor do they have a way to verify that the device in question in-fact has the device id associated with it.
  • There are current and future networking scenarios where MAC addresses are cloned, it’s not uncommon for MAC addresses to be virtualized; the schema for a MAC address even allows for “locally administered” values where the OUI is not enforced (see: http://en.wikipedia.org/wiki/MAC_address)

The above items alone (IMHO) should be enough for someone to come to the conclusion that they don’t belong in certificates but there are several others that make the use of such certificates in EAP especially questionable:

  • MAC addresses are 802.11 media specific, EAP is not tied to 802.11 (consider WiMAX as an example) any sort of device identifier that is to be used in EAP should not presume 802.11.
  • MAC addresses are disclosed pre-EAP, if a attacker can assume that the MAC addressed used in 802.11 will also be present in a certificate that is accepted by NAS then no amount of privacy at the EAP layer will be helpful.

OK, so if MAC addresses don't belong in certificates what identifier do we use to represent a device? Well I would argue the goal of including a MAC address in a certificate is to bind a key to a given piece of hardware so that the device can be later authenticated as that specific device.

In that case the creation of another unique identifier for that express purpose would make sense, there are efforts in the IEEE to do just that (see http://www.ieee802.org/1/pages/802.1ar.html) although from my quick review of the associated documents I am not convinced it’s going the right way.

For example it appears that they don't specify a common name-form for a device, nor do they specify where the name would go; both are necessary for a interoperable solution.

My current thinking is that the PKIX Permanent Identifiers RFC (http://www.ietf.org/rfc/rfc4043.txt) would be the right thing to base something for devices on, maybe even define a bis of this document that would accommodate these scenarios it’s not too far off.

I am not suggesting that having a name form and place to put the identifier is sufficient by itself for a device but it’s certainly a piece missing in the puzzle.

I for one am convinced that device identity will become a big problem as we get more and more embedded devices, and this is something we as a industry should work hard to address.

 

Print | posted on Monday, March 19, 2007 4:20 PM

Feedback


# re: Why MAC addresses do not belong in certificates 8/20/2007 10:12 AM Vlad Kolesnikov

Hi

I don't fully understand the first couple of reasons you mentioned.

I imagine that MAC address is usually not intended to be a fully qualifying name of a network player, which by itself entitles the player to privileges (e.g. cellular network access). Instead, it is the certificate (i.e. a signature of some trusted authority), and the possession of a corresponding private key together that validates privileges. In other words, it is usually not the case that "the guy with MAC address M1" gets access, but rather, "the guy on the other end of authenticated channel" gets access. Thus, e.g., the AAA will rely not on the MAC, but on the certificate itself to determine access rights. Its trust is not in MAC assignment, but in the CA signature.

In this sense, adversary cloning the MAC address does not do harm. Two devices with the same MAC addresses possessing different certificates may confuse some systems, I suppose.

MAC seems to be a convenient way to avoid most name collisions in local contexts.

I agree that using MACs as your userID, gives up on some degree of anonymity, namely, your user ID.

Does this make sense?

thanks
vlad

P.S. Your blog does not accept the tilda symbol in the URL.


Gravatar

# re: Why MAC addresses do not belong in certificates 8/20/2007 3:49 PM Ryan

Vlad - Thanks for the response, and on the bug in SubText I will file a bug with its author.

My point from this post was that without a established trust hierarchy that has policies and procedures in place to make the associated gaurontees the placement of a MAC address in a certificate is just an attempt to get a principal name or permanant identifier of sorts that ACLs can be logically evaluated against.

The core issue is that if you use the MAC address as the principal name or permantent identifier implementors and deployers will get mixed messages tha value used as the PI/principal may be derived from the MAC but it doesnt have all the properties of the MAC and as such should not be used as such.

It would be better to define a SAN:OtherName specifically for this case, then additional device details (chipset, firmware, pi, mac, etc.) could be bound to the device.

Title  
Name  
Email
Url
Comments   
Please add 7 and 8 and type the answer here: