One document matched: draft-behringer-homenet-trust-bootstrap-01.txt
Differences from draft-behringer-homenet-trust-bootstrap-00.txt
Network Working Group M. Behringer
Internet-Draft M. Pritikin
Intended status: Informational S. Bjarnason
Expires: April 21, 2014 Cisco
October 18, 2013
Bootstrapping Trust on a Homenet
draft-behringer-homenet-trust-bootstrap-01.txt
Abstract
A homenet must be aware of its borders, and the realms within those.
This document proposes an approach to bootstrap trust in such an
environment. The idea is to select one device as the trust anchor
and to enrol other devices into the domain. The result is the
creation of a domain of trust in the homenet, with a common trust
anchor. This trust model can subsequently be used to determine
boundaries, and to autonomically bootstrap network services.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 21, 2014.
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
Behringer, et al. Expires April 21, 2014 [Page 1]
Internet-Draft Bootstrapping Trust on a Homenet October 2013
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. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 2
2. Approach . . . . . . . . . . . . . . . . . . . . . . . . . . 2
2.1. Summary of the approach . . . . . . . . . . . . . . . . . 3
2.2. Autonomic devices . . . . . . . . . . . . . . . . . . . . 3
2.3. User interface . . . . . . . . . . . . . . . . . . . . . 3
2.4. The Registrar . . . . . . . . . . . . . . . . . . . . . . 3
2.5. Validating a device identity . . . . . . . . . . . . . . 4
2.6. Claiming a device . . . . . . . . . . . . . . . . . . . . 5
2.7. Services . . . . . . . . . . . . . . . . . . . . . . . . 6
2.8. Network boundaries . . . . . . . . . . . . . . . . . . . 6
3. Security Considerations . . . . . . . . . . . . . . . . . . . 6
4. Informative References . . . . . . . . . . . . . . . . . . . 7
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7
1. Problem Statement
[I-D.ietf-homenet-arch] states that "A homenet will most likely also
have internal borders between internal realms, e.g. a guest realm or
a corporate network extension realm. It should be possible to
automatically discover these borders." Simple approaches, such as
terminating a homenet on a particular interface type do not easily
allow for devices from different administrative realms to be locally
connected. [I-D.ietf-homenet-arch] states further that "It is
important that self-configuration with 'unintended' devices is
avoided. There should be a way for a user to administratively assert
in a simple way whether or not a device belongs to a homenet."
An approach is needed that allows to establish trust inside a homenet
according to a policy set by the user of the homenet.
2. Approach
This approach is based on making homenet devices behave in autonomic
mode where devices discover each others and autonomically establish
trust boundaries. See [I-D.behringer-autonomic-network-framework]
for more information.
Behringer, et al. Expires April 21, 2014 [Page 2]
Internet-Draft Bootstrapping Trust on a Homenet October 2013
2.1. Summary of the approach
In short, the approach is:
o The user pairs a smart phone (or similar device) with one of the
devices in the homenet, for example the CPE. The smart phone acts
as a user interface only.
o The selected device becomes the trust anchor of the homenet.
Technically, it acts as a certification authority (CA).
o Devices in the homenet use a protocol to exchange identities.
o A new device is added to the homenet by the user accepting it on
the smart phone, and the CA issuing a domain certificate to the
new device.
o The boundary of the network is determined by checking the
certificates of devices.
2.2. Autonomic devices
An autonomic device can be a router, switch, PC, smartphone, or any
other device, independent of its role in the network, which has the
autonomic functionality mentioned below. A homenet consists of
autonomic devices and non-autonomic devices. This approach requires
at least one autonomic networking device, such as a router or switch.
2.3. User interface
The user interface can be provided by the devices themselves or
through a smart phone interface. It is also possible to access the
devices indirectly through the manufactures web site. Options are:
o The user connects a PC to a physical port on network device and
gets access to devices's user interface.
o The user scans a QR code on the device using his smartphone. This
will trigger the download of the manufactures autonomic app which
will allow the user to connect to the device using wireless
access.
2.4. The Registrar
Behringer, et al. Expires April 21, 2014 [Page 3]
Internet-Draft Bootstrapping Trust on a Homenet October 2013
One autonomic device in the homenet takes on a registrar function.
This could be enabled using the smartphone autonomic app; in the
absence of a registrar function, a device can also auto-select itself
to take on this function, using some detection mechanism to resolve
potential conflicts.
The registrar creates a trust anchor for the homenet domain, and
subsequently acts as a certification authority, granting domain
certificates to other devices.
The user can configure a device as the registrar using one of the
following options:
o By using a smartphone app which is automatically downloaded when
scanning a QR code on the device. This will then allow the user
to connect to the device on an SSID which is dynamically created
based on the device serial number. The device will only allow
connections from smartphones using the manufactures app.
o By connecting a PC to a physical port on the network device and
gaining access to devices's user interface.
2.5. Validating a device identity
Every autonomic device discovers neighbouring autonomic nodes through
an autonomic secure neighbour discovery protocol. This could be
implemented for example through IPv6 secure neighbour discovery,
using a to-be-assigned well-known multicast address indicating "all
autonomic nodes on this subnet".
An autonomic device signs its neighbour discovery packets. If it has
a domain certificate from the domain registrar, it uses that. If
not, it uses either a vendor certificate (e.g., an IEEE 802.1AR
[IDevID] credential) or a self-signed certificate.
If two autonomic homenet devices use the same trust anchor they can
verify each other's certificate thus establishing that the peer is a
member of the same local domain.
If one autonomic homenet device is member of the homenet domain, and
its neighbour is not, it invites the neighbour to join the domain.
The device without domain credentials requests to join the first
domain it is presented with. The device MUST only join a homenet
domain when it is in the factory default configuration (e.g. it is
not currently a member of a homenet). The domain device proxies the
request to the registrar, including the device credentials of the
device without domain credentials.
Behringer, et al. Expires April 21, 2014 [Page 4]
Internet-Draft Bootstrapping Trust on a Homenet October 2013
The registrar accepts or declines a request to join the domain, based
on the credentials presented and other policy defined criteria such
as proxy identity. This may be validated by the user. Any
authorised device currently within the domain MAY provide
supplemental criteria for help making this decision. A smartphone
autonomic application would be an ideal domain member to provide user
interface functionality for the obtaining of supplemental criteria
from users.
The registrar can also decide to accept the device based on alternate
criteria:
o Allow any device to join within a specific time period.
o Allow only devices with specific serial numbers to join. These
can either be entered manually into the registrar or by scanning a
QR code using the manufactures autonomic app on a smartphone.
o If the device has a vendor certificate (e.g., an IEEE 802.1AR
[IDevID] credential), the device can be validated using a Cloud
service from the vendor.
If a device is accepted into the domain, it is then invited to
request a domain certificate through a certificate enrolment process.
A device MAY require an invitation to be signed by the manufacturer,
stating that it has been claimed by the user before it decides to
join the domain.
The result is a common trust anchor and device certificates for all
autonomic devices in a domain. These certificates can subsequently
be used to determine the boundaries of the homenet, to authenticate
other domain nodes, and to autonomically enable services on the
homenet.
2.6. Claiming a device
A device can be claimed using one of the following options:
o Presenting a manufacturer signed "claim" over the network
interface.
o Connecting to a physical port on the network device and inserting
the domain identity (public key).
Any registrar can contact the manufacturer or other trusted-by-the-
device cloud resource to obtain a claim on a device. This does not
require the device to be online. The claim is issued by the cloud
Behringer, et al. Expires April 21, 2014 [Page 5]
Internet-Draft Bootstrapping Trust on a Homenet October 2013
resource in a non-discrimatory fashion to the unauthenticated
registrar. Claims can include a nonce generated by the device. The
registrar may drop the nonce. The cloud service may drop the nonce.
If the nonce is included in the resulting claim the device must
verify this value against the current device state.
The cloud resource should offer open and non-discrimatory audit
functionalities associating the privacy protected registrar public
key information with the device identity and any nonce information
included.
2.7. Services
As the devices have a common trust anchor, device identity can be
securely established, making it possible to automatically deploy
services across the domain in a secure manner.
Examples of services:
o Device management.
o Routing authentication.
o Service discovery.
2.8. Network boundaries
When a device has joined the domain, it can validate the domain
membership of other devices. This makes it possible to create trust
boundaries where domain members have higher level of trusted than
external devices. Using the autonomic User Interface, specific
devices can be grouped into to sub domains and specific trust levels
can be implemented between those.
3. Security Considerations
The approach as outlined in this document is open to a number of
attacks at bootstrap time. For example, a malicious device could
pretend to be an expected device and assume its role.
There are counter-measures against these attacks, with various
security levels, and corresponding various ease of use. The options
are (in order of increased security):
o Only allow new devices to join in a specific time period.
o Only allow specific devices to join by matching their serial
numbers.
Behringer, et al. Expires April 21, 2014 [Page 6]
Internet-Draft Bootstrapping Trust on a Homenet October 2013
o Validating the vendor certificate on new devices using the vendors
Cloud portal.
In order to support a variety of use cases, devices can be claimed by
a registrar without proving possession of the device in question.
This would result in a nonceless, and thus always valid, claim.
Future registrars are recommended to take the audit history of a
device into account when deciding to join the device into their
network.
4. Informative References
[I-D.ietf-homenet-arch]
Chown, T., Arkko, J., Brandt, A., Troan, O., and J. Weil,
"Home Networking Architecture for IPv6", draft-ietf-
homenet-arch-10 (work in progress), August 2013.
[IDevID] IEEE Standard, ., "IEEE 802.1AR Secure Device Identifier",
December 2009, <http://standards.ieee.org/findstds/
standard/802.1AR-2009.html>.
Authors' Addresses
Michael H. Behringer
Cisco
Email: mbehring@cisco.com
Max Pritikin
Cisco
Email: pritikin@cisco.com
Steinthor Bjarnason
Cisco
Email: sbjarnas@cisco.com
Behringer, et al. Expires April 21, 2014 [Page 7]
| PAFTECH AB 2003-2026 | 2026-04-21 18:17:33 |