Reference number of working document: ISO/IEC
JTC1/SC25 WG1
N1137
Date: 2005-1-31
Committee identification: ISO/IEC JTC1/SC25 WG1
Secretariat: Germany (DIN)
Project No.: 01.09
Source: ISO/IEC JTC 1/SC 25/WG 1
Doc Type: Committe Draft
Requested Action: Comment
Due Date: 2005-3-31
Home Network Security – Part III: External Security Service
Warning
This document is not an ISO International Standard. It is distributed for review and comment. It is subject to
change without notice and may not be referred to as an International Standard.
Recipients of this draft are invited to submit, with their comments, notification of any relevant patent rights of
which they are aware and to provide supporting documentation.
1
Contents
HOME NETWORK SECURITY – PART III: EXTERNAL SECURITY SERVICE .................. 1
1
SCOPE.......................................................................................................................................... 1
2
REFERENCES ............................................................................................................................ 1
3
DEFINITIONS, ABBREVIATIONS AND COMPLIANCE NOTATIONS ........................... 3
3.1
3.2
3.3
DEFINITIONS ........................................................................................................................... 3
ABBREVIATIONS ..................................................................................................................... 3
COMPLIANCE NOTATION ......................................................................................................... 4
4
SECURITY REQUIREMENTS FOR HOME NETWORKS ................................................. 5
5
COORDINATION OF ACCESS DEVICE AND HOST SECURITY .................................... 7
5.1
5.2
5.3
IPSEC CONFIGURATION .......................................................................................................... 7
SSL/TLS CONFIGURATION ..................................................................................................... 8
AUTHORIZATION ................................................................................................................... 10
6
FIREWALL................................................................................................................................ 10
7
EVENT LOGGING .................................................................................................................... 11
Tables
Table 1: How IPSec, SSL/TLS and Firewall Defend the Home Network against Common
Threats. .......................................................................................................................... 6
1
Home Network Security – Part III: External Security Service
1
Scope
This standard specifies home network security services, especially, aims at the remote access through internet
to residential gateway. The network must be digital, and it must be IP-based; furthermore, it uses web tools,
such as HTTP, for device control. Security services specified in this standard are not based on any protocols
below layer 3 of the ISO Standard Reference Model.
2
References
1. Gutmann, P., “Software generation of Practically Strong Random Numbers,” Seventh USENIX Security
Symposium Proceedings, The USENIX Association, 1998, pp.243-257.
2. Kelsey, J., B. Schneier, and N. Ferguson, “Notes on the Design and Analysis of the Yarrow Cryptographic
Pseudorandom Number Generator,” Sixth Annual Workshop on Selected Areas in Cryptography,
Springer-Verlag, 1999.
3. Karn, P., P. Metzger, and W. Simpson, The ESP Triple DES Transform, RFC 1851, Internet Engineering
Task Force, September 1995.
4. Cheng, P., and R. Glenn, Test Cases for HMAC-MD5 and HMAC-SHA-1, RFC 2202, Internet Engineering
Task Force, September 1997.
5. Kent, S., R. Atkinson, Security Architecture for the Internet Protocol, RFC 2401, Internet Engineering Task
Force, November 1998.
6. Madson, C., and R. Glenn, The Use of HMAC-MD5-96 within ESP and AH, RFC 2403, Internet
Engineering Task Force, November 1998.
7. Madson, C. and R. Glenn, The Use of HMAC-SHA-1-96 within ESP and AH, RFC 2404, Internet
Engineering Task Force, November 1998.
8. Madson, C., and N. Doraswamy, The ESP DES-CBC Cipher Algorithm With Explicit IV, RFC 2405, Internet
Engineering Task Force, November 1998.
9. Kent, S., and R. Atkinson, IP Encapsulating Security Payload (ESP), RFC 2406, Internet Engineering Task
Force, November 1998.
10. Piper, D., The Internet IP Security Domain of Interpretation for ISAKMP, RFC 2407, Internet Engineering
Task Force, November
11. Maughan, D. M. Schertler, M. Schneider, and J. Turner, Internet Security Association and Key
Management Protocol (ISAKMP), RFC 2408, Internet Engineering Task Force, November 1998.
12. Harkins, D. and D. Carrel, The Internet Key Exchange (IKE), RFC 2409, Internet Engineering Task Force,
November 1998.
13. Glenn, R., and S. Kent, The NULL Encryption Algorithm and its Use With IPSec, RFC 2410, Internet
Engineering Task Force, November 1998.
14. Pereira, R., and R. Adams, The ESP CBC-Mode Cipher Algorithms, RFC 2451, Internet Engineering Task
Force, November 1998.
1
15. Kent, S., and R. Atkinson, “IP Authentication Header,” RFC 2402, Internet Engineering Task Force,
November 1998.
16. Thayer, R., N. Doraswamy, and R. Glenn, IP Security Document Roadmap, RFC 2411, Internet
Engineering Task Force, November 1998.
17. H. Orman, “The OAKLEY Key Determination Protocol,”
November 1998.
RFC 2412, Internet Engineering Task Force,
18. Freier, A.O., P. Carlton, and P.C. Kocher, The SSL Protocol Version 3.0.
19. Dierks, T., and C. Allen, The TLS Protocol, RFC 2246, Internet Engineering Task Force, January 1999.
20. Khare, R., and S. Lawrence, Upgrading to TLS within HTTP/1.1, RFC 2817, Internet Engineering Task
Force, May 2000.
21. Rescorla, E., HTTPover TLS, RFC 2818, Internet Engineering Task Force, May 2000.
22. Hodges, J., R. Morgan, and M. Wahl, Lightweight Directory Access Protocol (v3) : Extension for Transport
Layer Security, RFC 2830, Internet Engineering Task Force, May 2000.
23. Rescorla, E., “SSL and TLS,” Addison-Wesley, 2001.
24. Case, J., R. Mundy, D. Partain, and B. Stewart, Introductions to Version 3 of the Internet-standard Network
Management Framework, RFC 2570, Internet Engineering Task Force, April 1999.
25. Wijnen, B., D. Harrington, and R. Resuhn, An Architecture for Describing SNMP Management Frameworks,
RFC 2571, Internet Engineering Task Force, April 1999.
26. Case, J., D. Harrington, R. Presuhn, and B. Wijnen, Message Processing and Dispatching for the Simple
Network Management Protocol (SNMP), RFC 2572, Internet Engineering Task Force, April 1999.
27. Levi, D., P. Meyer, and B. Stewart, SNMP Applications, RFC 2573, Internet Engineering Task Force, April
1999.
28. Blumenthal, U., and B. Wijnen, User-based Security Model (USM) for version 3 of the Simple Network
Management Protocol (SNMPv3), RFC 2574, Internet Engineering Task Force, April 1999.
29. Wijnen, B., R. Presuhn, and K. McCloghrie, View-based Access Control Model (VACM) for the Simple
Network Management Protocol (SNMP), RFC 2575, Internet Engineering Task Force, April 1999.
30. Frye, R., D. Levi, S. Routhier, and B. Wijnen, Coexistence between Version 1, Version 2, and Version 3 of
the Internet-standard Network Management Framework, RFC 2576, Internet Engineering Task Force,
March 2000.
31. Yeong, W., T. Howes, and S. Kille, Lightweight Directory Access Protocol, RFC 1777, Internet Engineering
Task Force, March 1995.
32. Wahl, M., T. Howes, and S. Kille, Lightweight Directory Access Protocol (v3), RFC 2251, Internet
Engineering Task Force, December 1997.
33. IEEE 1363 Standard Specifications for Public Key Cryptography
34. Rivest, R., The MD5 Message-Digest Algorithm, RFC 1321, Internet Engineering Task Force, April 1992
35. Secure Hash Standard, FIPS PUB 180-1, National Institute of Standards and Technology, April 17, 1995.
36. Advanced Encryption Standard, National Institute of Standards and Technology, 2000
37. Rescorla, E., Diffie-Hellman Key Agreement Method, RFC 2631, Internet Engineering Task Force, June
1999.
38. Housley, R., W. Ford, W. Polk, and D. Solo, Internet Public Key Infrastructure : Part 1 : X.509 Certificate
2
and CRL Profile, RFC 2459, Internet Engineering Task Force, January 1999.
39. N. Freed, Behavior of and Requirements for Internet Firewalls, RFC 2979, Internet Engineering Task Force,
Oct 2000.
40. Ferguson, P., Senie, D., Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP
Source Address Spoofing, RFC 2827, Internet Engineering Task Force, May 2000.
41. Lonvick, C., The BSD syslog Protocol, RFC 3164, Internet Engineering Task Force, August 2001.
42. New, D. and Rose, M., Reliable Delivery for syslog, RFC 3195, Internet Engineering Task Force, November
2001.
3
Definitions, Abbreviations and Compliance Notations
3.1
Definitions
End station: An OSI system which contains application processes capable of communicating through all seven
layers of OSI protocols. Equivalent to Internet host.Access device: TBD
Access interface: TBD
Access server (or Network Access Server, NAS): A device that functions as an access control point for remote
users connecting to a company's internal network or to an ISP via analog modems or ISDN. Also called a
"media gateway" or a "remote access server" (RAS), a network access server (NAS) may include its own
authentication services or rely on a separate authentication server. A NAS may be a dedicated server or a
software service within a regular server
Cluster Controller: An intermediary device that is situated between a computer and a group (cluster) of
subsidiary devices, such as terminals on a network, and is used to control the cluster.
Session Key: A session key is an encryption and decryption key that is randomly generated to ensure the
security of a communications session between a user and another computer or between two computers.
3.2
Abbreviations
AES: Advanced Encryption Standard
AH: Authentication Header
CRC: Cyclic redundancy checking
DDoS: Distributed Denial of Dervice attack
DES: Data Encryption Standard
DH: Diffie-Hellman
DMZ: De-Militarized Zone
DNS: Domain Name System
DSS: Digital Signature Standard
DTV: Digital Television
DVCR: Digital VCR
ESP: Encapsulation Security Payload
FTP: File Transfer Protocol
HAN: Home Area Network
HMAC: Hash/MAC
3
HTML: Hyper-Text Markup Language
HTTP: Hyper-Text Transfer Protocol
ICMP: Internet Control Message Protocol
IEEE: Institute for Electrical and Electronics Engineers
IETF: Internet Engineering Task Force
IKE: Internet Key Exchange
IP: Internet Protocol
IPSec: IP Security
ISAKMP: Internet Security Association and Key Management Protocol
LAN: Local Area Network
LDAP: Lightweight Directory Access Protocol
MAC: Message Authentication Code
MIB: Management Information Base
MPEG: Motion Picture Experts Group
MTU: Maximum Transmission Unit
PCT: Private Communication Technology
PGP: Pretty Good Privacy
PKIX: Public Key Infrastructure X.509
PMTU: Path MTU discovery
RFC: Request For Comment
RSA: Rivest, Shamir, Adleman (developers of the RSA algorithm)
S/MIME: Secure Multipurpose Internet Mail Extension
SA: Security Association
SHA: Secure Hash Algorithm
SIP: Session Initiation Protocol
SPD: Security Policy Database
SSL: Secure Sockets Layer
TCP: Transport Control Protocol
TLS: Transport Layer Security
UPnP: Universal Plug and Play
VCR: Video Cassette Recorder
WAN: Wide Area Network
3.3
Compliance Notation
As used in this document, “MUST” denotes the definition is an absolute requirement of the specification.
“MUST NOT” denotes that the definition is an absolute prohibition of the specification. “SHOULD” denotes a
provision that is recommended but not mandatory. SHOULD NOT mean that there may exist valid reasons in
particular circumstances when the particular behavior is acceptable or even useful, but the full implications
should be understood and the case carefully weighed before implementing any behavior described with this
label. “MAY” denotes a feature whose presence does not preclude compliance that may or may not be present
at the option of the implementer. One vendor may choose to include the item because a particular marketplace
requires it or because the vendor feels that it enhances the product while another vendor may omit the same
item.
4
4
Security Requirements for Home Networks
This standard defines security services for the Home Network, especially aims at IP-based network from
internet access to HAN. The threats to a home network are similar to those of an enterprise network.
However, the various threats differ in significance for domestic, rather than commercial, network configurations
and applications. For instance, while repudiation (denying that a transaction took place) is obviously a serious
issue for a bank or brokerage firm, it is of less concern for the home, where the transaction is likely to be
entirely private and non-commercial. Conversely, businesses have little to gain by concealing which hours of
the day their networks are busiest, whereas residential users may very well wish to conceal traffic that indicates
whether or not they are at home.
Given the threats that are common to enterprises networks, we have identified the most likely threats to the
Home Network, and defined a set of security services to defend against those threats. We have recognized
that, as those threats are not peculiar to home networks, there is no need to invent new security mechanisms
for the home network and access device. In fact, the difficulty of designing such mechanisms correctly and
standardizing the results of such designs argues strongly against inventing new security mechanisms.
However, for several reasons, security mechanisms appropriate for a business may not adapt well to home
network security:
1. The first issue is cost. Some security mechanisms, such as industrial-strength firewalls, requires high
cost. Businesses write this off as an expense and recover cost by raising prices. Homeowners have
no such option and probably do not perceive the threat to the home network as sufficiently important to
merit that level of expense. Thus, a security mechanism must be inexpensive, or be able to be made
inexpensive, if it is to be used in the home.
2. The second is complexity. Many security mechanisms are difficult to configure and require an expert
to install and maintain. The typical homeowner is unlikely either to acquire the expertise or hire an
outside consultant to do this job. Faced with such a choice, he/she may elect simply to do without
security. Thus, simplicity of operation is essential to home network security.
3. The third is convenience. Employees of a business may be willing to endure a certain amount of
inconvenience if management decides that is the way the business operates. While passwords and
smartcards are accepted as necessary to protect the company’s resources, it is not clear how much
inconvenience a homeowner may be willing to accept to protect the home’s resources. For example,
most people will probably understand the necessity of having a password to access a networked digital
VCR from a remote location, such as an airport. However, they might find it inconvenient to use a smart
card and may object to a sophisticated set of password complexity and aging rules1.
4. The fourth is the different security priorities for a home and a business. Enterprises are likely to be
concerned with coordinated and targeted attacks by outsiders, with sabotage by insiders, discovery
and litigation, and protection of intellectual property. Residential users are, perhaps, more rightfully
concerned about privacy of their personal data, physical security and safety of their home, accuracy of
credit and billing records, public knowledge of their private life (such as knowledge of their
whereabouts and interests), and protection from widespread data gathering, snooping, and junk mail.
The task for home network security, then, is to choose among the security services that have been developed
for enterprise networks, within the constraints imposed by cost, complexity, convenience, and relative priorities.
We require SSL/TLS and IPSec for primary protection against threats external to the home network.
Furthermore, we require firewall protection at the access device, and define the functional requirements for the
firewall. Future versions of this standard will address protection against internal threats to the home network
(e.g., rogue software that may be introduced via a floppy disk), as well as refinements to the current
specifications.
The first goal of security is to defend the home network against the threats described in Annex A—masquerade,
replay, eavesdropping, modification, denial of service, resource exhaustion, unauthorized software (e.g.,
viruses), and repudiation—given the constraints with low cost, low complexity, and only moderate levels of
inconvenience to the homeowner. The second goal is to avoid developing new security services, by using
widely available systems that address security at the network layer (IPSec) and the session layer (SSL/TLS).
A combination of these two, correctly configured, combined with firewall technology will meet the criteria of low
cost, low complexity, and moderate inconvenience, while doing a good job of defending the home against most
of the threats listed above.
Proper security configuration is a complex process. Security is unlike other engineering disciplines in that one
cannot “tune till it works.” By design security mechanisms place limits on what is permissible. End user
configuration options SHOULD NOT allow protection mechanisms to be inadvertently circumvented or disabled
1
Indeed, one of the persistent problems for managers of enterprise security systems is the tendency of employees to use
simplistic passwords; favorites are the user’s own name, the user’s street name, or a common dictionary word.
5
by a user attempting to install a new device or run a new application.
Table 1 summarizes how these systems implement security defenses.
Note that, in addition to the specific measures specified by this standard, adequate protection requires network
computers to be protected by anti-virus software. As this is the same service that is now commonly available to
both enterprises and consumers, we assume that strategies for protecting the home network (and the access
device) will be applied in the same manner.
Note: Although the requirements in this section refer to current versions of services and mechanisms, this
standard will be revisited periodically, and updates will be made as needed; however, pending formal changes,
the user SHOULD employ the latest available version of each technology.
Table 1: How IPSec, SSL/TLS and Firewall Defend the Home Network against Common Threats.
Threat
Masquerade
Replay
Eavesdropping
Modification
Denial of Service
Resource Exhaustion
Software
Modification
Configuration
Modification
Repudiation
IPSec Defense
SSL/TLS Defense
Firewall
Authenticated Key
Exchange
Sequence Number per
Packet
Authenticated Key
Exchange
TCP sequence Number
No Defense
Encryption
Encryption
No Defense
Message Authentication Message Authentication
Code
Code
No Defense
No Defense
Avoid TCP SYN Floods
by Requiring Integrity
Checks
Partial Defense
Partial Defense
(Authentication and Data (Authentication and Data
Integrity)
Integrity)
Partial Defense
Partial Defense
(Authentication and Data (Authentication and Data
Integrity)
Integrity)
No Defense;
No Defense;
Cookies, MACs of
Ciphertext
Access control by IP
address or URL
No Defense
Limit access to
authorized devices
Ingress filtering to
discard spoofed
packets
Flow control
Partial Defense device
access control
Partial Defense device
access control
No definese
IPSec, SSL/TLS, and Firewall access control provide an effective defense against likely attacks against the
home, with the exception of denial of service, software modification, and repudiation. As we mentioned above,
there is no real-time defense against all denial of service attacks 2. IPSec and SSL/TLS do not explicitly
provide protection to software; however, the authentication and integrity services at least ensure that the
source of the infection is a legitimate user, thus protecting against most purely malicious attacks. If a
non-repudiation service is needed, PKI can support the non-repudiation of a digital signature.These services
cannot provide complete security. Not all traffic to the home will be on IP (e.g., streaming MPEG-2 video), and
there is no defense against downloading a contaminated file from a presumably secure source or inadvertently
revealing a password, so there is still need for packet filters and other security tools. However, they provide a
good start towards securing the home network and a basis for future work towards specifying and
implementing a home network security policy.
If an access gateway is used to protect the home network against external attacks, then all external access to
the residential network MUST be configured to go through the gateway.
2
The currently accepted method of dealing with large-scale denial of service attacks is to add a traceback mechanism to IP,
either by creating reverse-channel packets or inserting bits in the IP header that can enable the reverse path to be
computed. Because the most common of these attacks works by corrupting and co-opting a large number of
unsuspecting processors, as a responsible citizen, one should secure the home network and its computers so that they
cannot be used as part of a distributed denial of service attack against others.
6
5
Coordination of Access Device and Host Security
Both IPSec and SSL/TLS require that client software be installed in either the end station (the host) or in a
router or access interface. IPSec explicitly provides for both configurations. SSL/TLS, on the other hand,
lies between TCP and the application layer, so it is usually implemented by an application, such as a web
server or web browser. Even though SSL/TLS would “naturally” be implemented in end stations, such as
networked devices that implement web servers to enable remote device control, in fact SSL/TLS can also be
implemented in a proxy device, as part of the proxy device’s security functions.
Devices that implement cryptographic functions MUST be protected against software or software modification
that causes long-term secret keys to be revealed outside the device, that replaces or modifies the public keys
used to verify signatures on certificates, or that exposes session keys used to protect traffic. Devices that
implement cryptographic functions MUST be equipped with a means to generate cryptographically strong
pseudo-random numbers [1,2].
We examine each of these configurations, for IPSec [3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17] and for
SSL/TLS [18, 19, 20, 21, 22, 23], in the following sections.
5.1
IPSec Configuration
IPSec provides authentication or encryption for any IP packets that meet the SA selector criteria in the SPD.
When security is applied between end stations, IPSec MAY operate in transport mode; when security is applied
between gateways, it MUST operate in tunnel mode. If iterated tunnelling is used IPSec can run between a
host at one end (e.g., in the home) and a router at the other end (e.g., at a service provider).
Because all IP traffic is assumed to flow through a single access point to the home, i.e., the access device, it is
easy and efficient to apply IPSec at the access device. This relieves end stations on the home network of the
need to provide encryption and decryption services and centralizes security in the access device. This is
particularly advantageous for relatively simple end devices with modest processor capability. While providing
IPSec centrally in the access device MAY require some extra processor power and memory, it is still likely to be
more efficient than requiring almost as much functionality in each end device.
There are other advantages to centralizing IPSec in the access device:
1. When IPSec runs in tunnel mode, the original IP header is encrypted, and replaced with a new IP header.
The IP address of the actual end station on the home network is hidden from the outside world and
replaced in the header address fields by the IP address of the access device. This provides another layer
of security, because the IP addresses of the devices on the home network are kept secret.
2. Centralizing IP security services makes it easier to administer security. The homeowner doesn’t have to
install and configure security policy and security parameters on each device that might communicate
(using IP) with the outside world. Upgrades are easier, and can be applied to multiple devices at once.
Centralizing security services particularly in the access device MAY make it easier for a third-party service
provider to provision, upgrade, and maintain the security service for the home network. For example, the
homeowner might choose to contract with an outside supplier to provide security services to her home; among
other things, the supplier will maintain the Security Policy Database that determines which IP packets will be
associated with SAs. If the SPD is housed in the access device, maintenance MAY be somewhat easier (for a
network-based service) than if it is housed on an interior node of the home network.
If external access to the residential network is not protected by SSL or TLS, it MUST be configurable to use
IPSec in tunnel mode between the external device and an access interface. It MAY also be configured to use
IPSec in tunnel mode or transport mode or to use SNMPv3 [24, 25, 26, 27, 28, 29, 30] directly with the
internal device or its proxy.
An access interface MUST be configured to allow the user to specify what external protocols are allowed to
access this interface or devices inside the residence, what authentication is required, and what IPSec services
are required. The access interface MUST be capable of rejecting all other accesses.
An access interface MUST support IKE manual key distribution and aggressive mode for a Phase 1 exchange
with external access points and IKE quick mode for Phase 2 exchanges. It MAY support IKE main mode and
7
new group mode.
An access interface implementation of IPSec MUST support the PMTU discovery mechanisms in RFC2401 [5].
An access interface implementing IKE MAY support only the SIT_IDENTITY_ONLY situation, but it MUST
support PKIX and SHOULD support LDAPv2 [31] for certificate management. It MAY support LDAPv3 [32].
Public key technology MUST comply with IEEE1363 [33].
Applications MUST use at least 1024-bit modular exponentiation,163-bit elliptic curve groups, or 448-bit (251)
NTRU.
An access interface MUST support ESP.
It SHOULD use ESP to protect traffic, and it SHOULD NOT use AH.
All ESP SAs SHOULD use the integrity and replay detection services, unless these services are provided in a
strong cryptographic manner by a higher layer protocol (for example, CRCs are NOT sufficient for integrity).
HMAC with MD5 [34] or SHA-1 [35] MUST be supported.
Applications MUST use AES [36] as the symmetric encryption algorithm.
Except as modified by these requirements, IPSec implementations MUST conform to IETF IPSec standards
track RFCs at the currently highest level of standardization.
5.2
SSL/TLS Configuration
The Secure Sockets Layer (SSL) and Transport Layer Security (TLS) protocols provide cryptographic
authentication, data stream integrity, and data stream confidentiality for TCP connections. They are
particularly well suited for protecting http traffic between web browsers and servers. The contents of this
section are aimed to help secure web-based access to the home network.
SSL and TLS are usually implemented at a server and at a browser. However, it MAY be advantageous to
have SSL/TLS sessions established by the access server when access is requested through the Internet,
rather than by the web servers in the controlled devices. This has several advantages over having separate
sessions established for each connection to a server (i.e., to each controlled device) on the home network. This
approach allows the access server to act as a proxy hiding the identity and IP address from the remote user.
If a user wishes to access her home network to interact remotely with some networked device, such as an air
conditioner, this will probably entail interactions with several web servers:
A.
First, the user establishes a connection to a server in the access device, using the access device’s (i.e.,
the home’s) public IP address. This server determines that the user wishes to connect to devices on the
home network, and it acts as a proxy server for the user by sending an HTTP get message to the home
network’s network manager, accessing the home network’s home page.
B.
The access device forwards the home network’s home page to the user. This page has icons for
controlled devices on the network, for cluster controllers, for the access device, and for various databases,
such as the home network’s MIB or DNS server. The home network home page MAY also implement an
authentication server that requires the user to provide proper identification and authentication before
being allowed to proceed further.
C.
The user will access either a networked device, or a cluster controller. If she accesses a networked
device (such as a digital VCR), she will be presented with icons that represent control messages that can
be invoked to operate that device (e.g., “record” for the DVCR). If she accesses a cluster controller, she
will be presented a choice of devices to be controlled (such as the air conditioner); she will then choose a
device, and be presented with another web page displaying the control icons for that device.
Note that the user is accessing multiple web servers, each with its own IP address, and is establishing new
TCP connections with each server. If SSL/TLS is to be used to protect all external access, either (1) an
SSL/TLS session MUST be associated with each or (2) the access device MUST act as a proxy for the others.
In practice, some combination of these two methods MAY be used. In the first case, multiple SSL/TLS sessions
are established - one for each server. In the second case, the Handshake Protocol is run once, when the user
8
first accesses the home network’s home page. This SSL/TLS session will act as a secure proxy for the
devices within the home network that do not implement SSL/TLS.
The secure home page server MUST be located such that all Internet traffic is routed directly to it and is not
able to bypass the home page server. This spatial segmentation is commonly called a Demilitarized Zone
(DMZ). This forces all remote traffic to flow through the home page server, minimizing the risk that an attacker
will gain direct access to one or more network devices.
The access server that provides external access to an internal HTTP server and internal secure HTTP servers
MUST support SSLv3 with RSA [18]. It MAY also support SSLv3 with DSS and DH [37] or TLS 1.0 or later.
Other protocols (e.g., SSLv2, PCT, and S HTTP) are outside the scope of these requirements.
Other devices on the home network MAY support SSLv3 with RSA, SSLv3 with DSS and DH, or TLS 1.0.
For most e-commerce applications, the burden of authentication is placed on the commercial website’s server,
because the customer’s browser will supply the required payment credentials like credit card data when
needed. However, for applications such as home network access, initial authentication of both parties is
critical. The most secure configuration would be to provide both parties with certificates signed by the network
operator, install the network operator’s public key as the root key in the browsers and servers, and remove all
other trusted keys from the server and the browser. That is, both parties (when using RSA, for example)
respond to the CertificateRequest message with a Certificate message and a CertificateVerify message. An
alternative method of client authentication is to use a hardware-based one-time password system over the
secured connection. Simple passwords sent over the secure connection are vulnerable to a number of
practical attacks, so these should be used only with carefully constructed constraints (aging, complexity,
logging, etc.). For example, the dangers of storing the password in the browser and performing logon from an
untrusted computer MUST be explained clearly.
Clients (browsers) SHOULD use certificates [38] to authenticate to the access device. They MAY, however,
use a token-based authentication system or passwords sent over the protected channel.
Certificates SHOULD be generated with a lifetime of no more than three years.
Entire certificate chains SHOULD be checked for correct names, expiration, and revocation.
Where authentication MAY occur offline, such as with UPnP, the entire certificate chain MUST be available
locally.
For RSA or DH-DSS, key lengths MUST be at least bits1024bits, ECC key length MUST be at lest 163-bits, and
NTRU key length MUST be at least 448-bits (251) This applies to all certifiactes in the chain. Applications
requiring confidentiality MUST use128-bit AES [36], when implemented; otherwise, applications requiring
confidentiality MUST use triple DES. Browsers supporting only 40-bit keys single MUST be rejected by the
server.
Browsers and servers MUST provide long-term protection for the privacy of their authentication data and the
integrity of root public keys they rely upon to verify certificates. Hardware tamper-resistance like a smart card
or cryptographic module SHOULD be used, but if disk storage is used, these items MUST be encrypted and
password protected, and the system MUST log all attempted accesses securely.
Both parties MUST protect pre-master secrets, master secrets, and session keys for the duration of their use.
Use of software that allows memory access, memory dumps, examination of paging devices, and so forth
MUST be restricted accordingly. Where practical, processes SHOULD be locked in main memory and not
paged.
For SSLv3 [18], the protocol version is major=3, minor=0, and port and protocol selection and use MUST follow
RFC 2818. The server MUST NOT use the cipher suites designed for U.S. export restrictions that are no
longer in force, and the ephemeral RSA, anonymous, and Server Gated Cryptography options MUST NOT be
used. Both the server and the browser SHOULD support the inclusion of the length bytes in the
ClientKeyExchange message. Session resumption with a timeout MAY be used; the recommended timeout
interval is ten minutes. The server MUST use the close_notify alert; the browser SHOULD also use
close_notify to complete a two-way closure handshake. Both parties SHOULD support protected
Rehandshake exchanges.
If TLS 1.0 [19] is supported (protocol version is major=3, minor=1), the requirements for connection closure,
9
use of port numbers, checking of the server’s identity, and checking the client’s identity in [20] MUST be
followed, the name matching rules specified in [38] MUST be followed, and servers SHOULD, and browsers
MAY, support the use of port numbers described in [20].
Securing the Browser
The browser SHOULD be configured with its security settings to support the requirements for SSL and TLS
listed above, and to alert the user of potential security violations. Unused features, such as plug-ins, Java,
JavaScript, or ActiveX controls, SHOULD be disabled, unneeded root keys SHOULD be removed from the
browser, and extraneous network services SHOULD be disabled. System logging and intrusion detection
tools SHOULD be used to monitor the configuration as appropriate. The browser SHOULD wait for the
server’s handshake Finish message before sending application data; if session resumption is enabled, the user
MUST be instructed to exit the browser or lock the terminal before leaving the workstation.
5.3
Authorization
This security architecture, with IPSec and SSL/TLS implemented in the access device, doesn’t preclude a
networked device or a cluster controller from implementing its own authorization procedures. For example,
once the secure SSL/TLS connection to the home network home page is established, it MAY display an
authentication window to confirm the identity of the user. This server will ask the user to enter an ID and
password or other information, which will then be transmitted securely to the home page and verified. If the
authentication fails, the user will not be allowed view the home page.
Once the user is authenticated, she MAY then invoke an icon, and establish a TCP connection to the next
server in line. This server, in turn, MAY also invoke a password client to confirm the identity of the user. For
example, if the user wishes to access the security cluster controller or to gain entry to the home network’s MIB,
it is likely that she will be asked to identify herself again to confirm that she is authorized to access that device,
perhaps by using another password.
Running the Handshake Protocol in the access device MAY also be a convenient and effective way to ensure
that outside connections are secured, while inside access to web servers (which is assumed to be “friendly”) is
not encumbered by unnecessary security burdens. For example, while one would certainly want to secure
access to a DTV by an outside user, we don’t want to “log in” to our television set when using it from across the
room. When the home network’s home page is invoked from a node inside the home network, rather than
from the access device, the Handshake Protocol is not run, and devices in the home are accessed without the
use of SSL/TLS.
6
Firewall
The home network MUST be protected by at least one firewall located between the local network and the
Internet. Additional firewalls MAY be used to segment the local network into multiple security domains or to
protect individual devices. Firewall implementation MUST follow the guidelines described in the latest version
of RFC 2979 (“Behavior of and requirements for Internet firewalls”)[39].
Note: Firewalls are difficult to configure, and the correct and conventional setting of critical parameters is
usually learned from experience in specific environments. Therefore, this standard specifies only firewall
functions; the implementation is left to the homeowner. Future issues of this standard MAY add more detailed
implementation specifications.
A firewall located between the home network and the Internet MUST provide the following functions:

Pass or block incoming (from WAN) connection requests

Pass or block outgoing (from HAN) connection requests

Selectively pass or block incoming packets based on internal IP interface, address, protocol and
port number

Selectively pass or block access to remote hosts based on remote IP interface, address, protocol
and port number or fully-qualified domain name
10

Prevent internal broadcast traffic from leaving the home to the Internet, through the access device

Be transparent to common applications (ICMP, FTP, IPSec, SIP etc)

Implement network ingress filtering to counter DDoS, per RFC 2827 [40]

Implement selective logging of blocked traffic
To simplify configuration for the home user the factory default SHOULD be to allow all outbound traffic and
block all incoming traffic.
The firewall SHOULD include provisions to monitor for intrusion attempts. This includes scanning for ports
commonly used by Trojans and combinatorial events that are benign by themselves but taken together
constitute a potential threat.
7
Event Logging
A key tool for network and security failures is adequate logging. The logger captures relevant home network
events in sufficient quantity and depth to provide information about the failure. The event log MUST consist of
one or more circular buffers that automatically purge the oldest data. Data capture options are set through
menu options. Deletion of logger data is under control of the logger. Logger design MUST make it difficult
for the end user or attacker to delete or corrupt log contents. The log format MUST be TBD with a minimum
size of TBD. All log entries are time stamped. Deletion of old entries MUST be independent of the time stamp.
The logger MUST be implemented per RFC 3164 The BDS syslog Protocol [41] and SHOULD meet
requirements of RFC 3195 Reliable Delivery for syslog [42] to transmit syslog information to other systems.
The logger MUST capture at least the following information:

New device attach and discovery

Device reconfiguration

Login, logoff, user account, remote site info, and destinations of all secure SSL/TLS and IPSec
sessions

Account creation/modification

Failed login attempts

Intrusion detection events

Power loss/restoration

WAN connection, disconnection, reconfiguration
11