RFC 6869 PROPOSED STANDARD VCARD · DEVICES · CONTACTS

vCard KIND:device

Lets a vCard describe a computing device, such as a router or printer, instead of a person or organization.

On rfc-editor.org ↗
PUBLISHED
February 2013
AUTHORS
G. Salgueiro, J. Clarke, P. Saint-Andre
STREAM
IETF
NEW KIND VALUE
device
EXISTING KIND VALUES
individual, org, group, location, application
REGISTRY
vCard Elements, vCard Property Values
DOI
10.17487/RFC6869

RFC text

Contents
Original text · RFC Editor View on rfc-editor.org ↗
Internet Engineering Task Force (IETF)                      G. Salgueiro
Request for Comments: 6869                                     J. Clarke
Category: Standards Track                                 P. Saint-Andre
ISSN: 2070-1721                                            Cisco Systems
                                                           February 2013


                           vCard KIND:device

Abstract

   This document defines a value of "device" for the vCard KIND property
   so that the vCard format can be used to represent computing devices
   such as appliances, computers, or network elements (e.g., a server,
   router, switch, printer, sensor, or phone).

Status of This Memo

   This is an Internet Standards Track document.

   This document is a product of the Internet Engineering Task Force
   (IETF).  It represents the consensus of the IETF community.  It has
   received public review and has been approved for publication by the
   Internet Engineering Steering Group (IESG).  Further information on
   Internet Standards is available in Section 2 of RFC 5741.

   Information about the current status of this document, any errata,
   and how to provide feedback on it may be obtained at
   http://www.rfc-editor.org/info/rfc6869.

Copyright Notice

   Copyright (c) 2013 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 2
   2.  Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
   3.  Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
   4.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6
   5.  Security Considerations . . . . . . . . . . . . . . . . . . . . 6
   6.  References  . . . . . . . . . . . . . . . . . . . . . . . . . . 7
     6.1.  Normative References  . . . . . . . . . . . . . . . . . . . 7
     6.2.  Informative References  . . . . . . . . . . . . . . . . . . 7

1.  Introduction

   Version 4 of the vCard specification [RFC6350] defines a new "KIND"
   property to specify the type of entity that a vCard represents.
   During its work on the base vCard4 specification, the VCARDDAV
   Working Group defined values of "individual", "org", "group", and
   "location" for the KIND property.

   During working group discussion of the document that became
   [RFC6473], consideration was given to defining a more general value
   of "thing", but it was decided to split "thing" into software
   applications and hardware devices and to define only the
   "application" value at that time.  Since then, use cases for device
   vCards have emerged.  These use cases involve using vCards as a
   primer for inventory and asset tracking data specific to network
   elements.  Therefore, this document complements [RFC6473] by defining
   a value of "device" for the KIND property to represent computing
   devices such as appliances, computers, or network elements.  In this
   context, the concept of a device is constrained to computing devices
   and thus is distinct from purely mechanical devices such as
   elevators, electric generators, etc., that cannot communicate in any
   way over a network.  This does not preclude, however, network-
   attached sensors that are connected to such mechanical devices.

2.  Scope

   When the KIND property has a value of "device", the vCard represents
   a computing device such as an appliance, a computer, or a network
   element (e.g., a server, router, switch, printer, sensor, or phone).
   More formally, a "device" is functionally equivalent to the "device"
   object class used in the Lightweight Directory Access Protocol
   [RFC4519] as derived from the Open Systems Interconnection model
   [X.521] [X.200].  However, whereas [X.521] specifies that devices are
   "physical" elements, a device in this context can also be virtual
   such as a virtual machine running within another physical element.
   As one example of the "device" KIND, vCards can be embedded into
   devices at manufacturing time so that basic information such as
   serial number, support email, and documentation URL can be retrieved
   upon initial deployment.  This vCard can be modified after the device
   is deployed to contain user-specified data about the device's
   characteristics.  The vCard data can therefore be used for both asset
   tracking and operational purposes.

   A device might have a number of embedded vCards for varying purposes.
   The process for discovering and accessing these vCards is
   purposefully left unspecified in this document, as this process could
   rely on any mechanism that makes sense for the device in question.
   For example, a device could have one or more of the following vCard
   instances:

   o  The device itself.  For example, the FN ("full name") property
      might represent the hostname of a computing device; the URL
      property might represent a website that contains details on where
      to find documentation or get further information about the device;
      the KEY property might represent a digital certificate that was
      provisioned into the device at the time of manufacture
      [IEEE.802.1AR], or a public key certificate previously provisioned
      into the device; and the ADR, GEO, and TZ properties might
      represent the physical address, geographical location, and time
      zone where the device is deployed.

   o  An organization or person that produces or manufactures the
      device.

   o  A person or role that maintains or administers the device.

   o  Application-level vCards as described in [RFC6473] for each
      application installed on the device.

   When a device has vCards other than its KIND:device vCard, those
   vCards can be linked together with RELATED (see the definition of the
   RELATED organizational property in Section 6.6.6 of [RFC6350]).  In
   multi-vCard instances, the KIND:device vCard would use the RELATED
   property to express the relationship with the ancillary vCard(s).
   Those supplementary vCards need not use RELATED to point back to the
   KIND:device vCard.  In this manner, the vCard for the device itself
   can be easily distinguished from vCards referring to the vendor
   organization, device administrator, and installed applications.

   The following base properties make sense for vCards that represent
   devices (this list is not exhaustive, and other properties might be
   applicable as well):

      *  ADR
      *  EMAIL
      *  FN
      *  GEO
      *  IMPP
      *  KEY
      *  KIND
      *  LANG
      *  LOGO
      *  NOTE
      *  ORG
      *  PHOTO
      *  RELATED
      *  REV
      *  SOURCE
      *  TEL
      *  TZ
      *  UID
      *  URL

   Although it might be desirable to define a more fine-grained taxonomy
   of devices (e.g., a KIND of "device" with a subtype of "router" or
   "computer"), such a taxonomy is out of scope for this document.

3.  Example

   The following is an example of a router device that contains both
   manufacturing details as well as post-deployment attributes and uses
   the XML representation of vCard (xCard) described in [RFC6351].  This
   vCard points to another, related vCard that contains the details of
   an administrative contact for the device.  This vCard also leverages
   the extensibility of the xCard format to reference additional
   namespaces in order to provide richer details about the given device
   (e.g., the serial number and software version are specified as xCard
   extensions).

   <vcard xmlns="urn:ietf:params:xml:ns:vcard-4.0">
     <kind><text>device</text></kind>
     <fn>
       <parameters>
         <type><text>x-model-name</text></type>
       </parameters>
       <text>RTR1001</text>
     </fn>
     <fn><text>core-rtr-1.example.net</text></fn>
     <url><uri>http://www.example.com/support/index.html</uri></url>
     <email><text>support@example.com</text></email>
     <email>
       <parameters>
         <type><text>x-local-support</text></type>
       </parameters>
       <text>network-support@example.net</text>
     </email>
     <impp><uri>xmpp:core-rtr-1@example.net</uri></impp>
     <related>
       <parameters>
         <type><text>contact</text></type>
       </parameters>
       <uri>urn:uuid:5CEF1870-0326-11E2-A21F-0800200C9A66</uri>
     </related>
     <logo><uri>http://www.example.com/images/logo.png</uri></logo>
     <geo><uri>geo:35.82,-78.64</uri></geo>
     <tz><text>America/New_York</text></tz>
     <rev><timestamp>20120104T213000Z</timestamp></rev>
     <uid><uri>urn:uuid:00CCFB88-155F-40F6-B9D9-B04D134860C0</uri></uid>
     <serial-number xmlns='http://example.org/profiles/serial-number'>
       FTX1234ABCD
     </serial-number>
     <note>
       <parameters>
         <type><text>x-contract-number</text></type>
       </parameters>
       <text>1234567</text>
     </note>
     <mac xmlns='http://example.org/profiles/mac'>
       00-00-5E-00-00-01
     </mac>
     <sw-version xmlns='http://example.org/profiles/sw-version'>
       2.1.5
     </sw-version>
   </vcard>

4.  IANA Considerations

   IANA has added the following entry to the "vCard Property Values"
   table of the "vCard Elements" registry
   (http://www.iana.org/assignments/vcard-elements):

                +----------+--------+---------------------+
                | Property |  Value |      Reference      |
                +----------+--------+---------------------+
                |   KIND   | device | RFC 6869, Section 3 |
                +----------+--------+---------------------+

      Table 1: IANA Registration of KIND:device vCard Property Value

   In conformance with Section 10.2.6 of [RFC6350], the registration
   template is as follows:

   Value:  device

   Purpose:  The entity represented by the vCard is a computing device
      such as an appliance, computer, or network element.

   Conformance:  This value can be used with the "KIND" property.

   Example:  See Section 3 of RFC 6869.

5.  Security Considerations

   Registration of this vCard KIND to represent devices does not in
   itself introduce security considerations beyond those specified for
   vCards in general as described in [RFC6350].  Nevertheless, risks can
   arise for vulnerable Internet-connected devices as a result of the
   publication of the identification details provided by device vCards.
   Well-known publicly accessible device vCard repositories, while not
   defined in this document, can increase the probability of an
   exploitation of an existing vulnerability, especially for devices
   with no good way to update their software or firmware.  It is the
   responsibility of the device administrator to adhere to best current
   security practices and employ proper strategies for software upgrades
   and security patches in order to mitigate vulnerability to attack.
   Specifications defining device-specific vCard extensions or profiles
   that might be included in such vCards also need to consider this
   potential increased risk.

6.  References

6.1.  Normative References

   [RFC6350]       Perreault, S., "vCard Format Specification",
                   RFC 6350, August 2011.

6.2.  Informative References

   [IEEE.802.1AR]  Institute of Electrical and Electronics Engineers,
                   "Secure Device Identity", IEEE 802.1AR, 2009.

   [RFC4519]       Sciberras, A., "Lightweight Directory Access Protocol
                   (LDAP): Schema for User Applications", RFC 4519,
                   June 2006.

   [RFC6351]       Perreault, S., "xCard: vCard XML Representation",
                   RFC 6351, August 2011.

   [RFC6473]       Saint-Andre, P., "vCard KIND:application", RFC 6473,
                   December 2011.

   [X.200]         International Telecommunication Union, "Information
                   Technology - Open Systems Interconnection - Basic
                   Reference Model: The Basic Model", ITU-T
                   Recommendation X.521, ISO Standard 9594-7,
                   February 2001.

   [X.521]         International Telecommunication Union, "Information
                   Technology - Open Systems Interconnection - The
                   Directory: Selected Object Classes", ITU-T
                   Recommendation X.200, ISO Standard 7498-1, July 1994.

Authors' Addresses

   Gonzalo Salgueiro
   Cisco Systems
   7200-12 Kit Creek Road
   Research Triangle Park, NC  27709
   US

   Phone: +1-919-392-3266
   EMail: gsalguei@cisco.com


   Joe Clarke
   Cisco Systems
   7200-12 Kit Creek Road
   Research Triangle Park, NC  27709
   US

   Phone: +1-919-392-2867
   EMail: jclarke@cisco.com


   Peter Saint-Andre
   Cisco Systems
   1899 Wynkoop Street, Suite 600
   Denver, CO  80202
   US

   Phone: +1-303-308-3282
   EMail: psaintan@cisco.com

AI ELI5

On this page
PROBLEMvCard 4 could say whether a card describes an individual, organization, group, location or application, but had no way to mark a card as describing a computing device.
MECHANISMThe document defines the value device for the vCard KIND property and shows how device cards can carry properties like FN, URL and GEO and link to related cards using RELATED.
WHY IT MATTERSDevices can carry or publish their own vCards for asset tracking and operations. The RFC warns that publishing device details can help attackers find vulnerable devices.

§1Why a Device Kind

Version 4 of vCard (RFC 6350) has a KIND property saying what type of entity a card represents. The VCARDDAV Working Group defined the values individual, org, group and location. A more general thing was considered, but it was decided to split it into software applications and hardware devices, and only application was defined at the time (RFC 6473).

Since then, use cases for device vCards have emerged: using vCards as a primer for inventory and asset tracking data specific to network elements. This document therefore adds the value device. It is limited to computing devices, which makes it distinct from purely mechanical devices such as elevators or electric generators that cannot communicate over a network. Network-attached sensors on such machines are not excluded.

Cards already existed for people, companies, groups and places. This adds one more kind for computers and gadgets that connect to a network.

§2What Counts as a Device

When KIND is device, the vCard represents a computing device such as an appliance, computer or network element, for example a server, router, switch, printer, sensor or phone. The RFC says this is functionally equivalent to the device object class in LDAP (RFC 4519), but a device here can also be virtual, such as a virtual machine running inside another physical element.

A vCard can be embedded into a device at manufacturing time so that basic information such as the serial number, support email and documentation URL is available at initial deployment. It can be modified after deployment to hold user-specified data, so the data serves both asset tracking and operational purposes.

A finer-grained taxonomy, such as a subtype of router or computer, is explicitly out of scope.

A device card can describe a real machine or a pretend one living inside another computer. The maker can put the basics on the card, and the owner can add more later.

§3Several Cards per Device

A device might have several embedded vCards for different purposes. How to discover and access them is deliberately left unspecified. Example cards the RFC lists: the device itself, the organization or person that makes it, a person or role that maintains it, and application-level vCards (RFC 6473) for each installed application.

On the device's own card, FN might carry the hostname, URL a documentation website, KEY a certificate provisioned at manufacture, and ADR, GEO and TZ the physical address, location and time zone.

The device card can link to the other cards with the RELATED property, which makes it easy to tell the device's card from those of the vendor, administrator and applications. The other cards need not point back.

One machine can have a small stack of cards: one for itself, one for who built it, one for who looks after it. The machine's card points to the others.

§4Example and IANA Registration

The example is a router described in the XML form of vCard (xCard, RFC 6351). It mixes manufacturing details with post-deployment attributes, points to a related administrative contact with RELATED, and uses xCard extension namespaces for extras such as a serial number, MAC address and software version.

IANA added the value device for the KIND property to the vCard Property Values table in the vCard Elements registry. The registration states that the entity represented is a computing device such as an appliance, computer or network element.

The example is a card for a router listing its name, support contact and location. A central list was updated so everyone recognizes the new kind of card.

§5Security Considerations

Registering the value does not by itself add security considerations beyond those in RFC 6350. However, risks can arise for vulnerable Internet-connected devices when identification details from device vCards are published. Well-known, publicly accessible device vCard repositories can raise the chance that an existing vulnerability is exploited, especially for devices with no good way to update software or firmware.

It is the device administrator's responsibility to follow best current security practices and to apply upgrades and patches. Specifications defining device-specific vCard extensions or profiles also need to consider this increased risk.

If a card tells the whole world exactly what machine you have, a bad person can look for known weak spots. So keep your machines up to date.

§6References