ISO / IEC JTC1/ SC25 WG1
N993
WG1 (Boston, Ungar)2
Date: January 2, 2002
ISO/IEC JTC1 SC25 WG1
Interconnection of Information Technology Equipment
Home Electronic Systems
Title:
Security Enhancement for ISO/IEC CD-20587
Source:
USA
Project:
25.01.09
Requested Action:
Consideration by WG1 at meeting to be
held January 21-25, 2002
Distribution:
P-, L-, O- Members of SC25 WG1
Note:
Project Editor: Dr. Steven Ungar
Telcordia Technologies, Inc.
973-829-4201, sungar@telcordia.com
i
Contents
FOREWORD ................................................................................................................... 5
1 INTRODUCTION ...................................................................................................... 6
2 GENERAL ................................................................................................................ 7
2.1
Scope ................................................................................................................ 7
2.2
Normative references........................................................................................ 7
2.2.1
Normative reference list ............................................................................. 8
2.2.2
Normative reference acquisition .............................................................. 10
2.3
Informative References ................................................................................... 10
2.3.1
Informative document list ......................................................................... 10
2.3.2
Informative document acquisition ............................................................ 11
2.4 Symbols and abbreviations ................................................................................. 11
2.5 Compliance Notation ........................................................................................... 13
3
Security Services for the Versatile Home Network (VHN) ................................ 13
3.1 Coordination of Access Device and Host Security .............................................. 15
3.1.1 IPSec Configurations .................................................................................... 15
3.1.2 SSL/TLS Configurations................................................................................ 17
3.1.2.1 Securing the Browser ............................................................................. 20
3.1.3 Authorization ................................................................................................. 20
3.2 Firewall ................................................................................................................ 20
3.3 Event Logging ...................................................................................................... 21
ANNEX A: Security Services ...................................................................................... 23
A1
Introduction....................................................................................................... 23
A2
Home Network Threats .................................................................................... 23
Software and Configuration Security: Trojan Horses, Worms, Viruses ......... 25
Repudiation .......................................................................................................... 25
A3
Home Network Defenses ................................................................................. 26
A3.1
Encryption .................................................................................................... 27
A.1.1.1 Conventional Encryption ...................................................................... 27
A3.1.1
Public-Key Encryption .............................................................................. 28
A3.1.2
Digital Signatures and Key Exchange ...................................................... 28
A3.1.2.1 Diffie-Hellman Key Exchange .............................................................. 29
A3.2
Authentication and Authorization ................................................................. 29
A3.2.1
Firewalls ................................................................................................... 30
ii
A3.3
Integrity and Confidentiality ......................................................................... 31
A3.3.1
Message Authentication Code (MAC)...................................................... 31
A3.3.2
Hash Functions and Digital Signatures .................................................... 32
A4
Home Network Security Solutions .................................................................. 33
A4.1
IPSec ........................................................................................................... 33
A4.1.1
Security Associations and the Security Policy Database ......................... 33
A4.1.2
Transport Mode and Tunnel Mode: ......................................................... 34
A4.1.3
Authentication Header (AH): .................................................................... 35
A4.1.4
Encapsulating Security Payload (ESP) Header: ...................................... 36
A4.1.5
Combining Security Associations............................................................. 38
A4.1.6
Key Management: .................................................................................... 39
A4.2
A5
SSL/TLS ...................................................................................................... 40
A4.2.1
SSL/TLS Record Protocol and SSL/TLS Handshake Protocol: ............... 40
A4.2.2
The SSL Session and the SSL Connection: ............................................ 40
A4.2.3
SSL Session States: ................................................................................ 41
A4.2.4
SSL Connection States:........................................................................... 41
A4.2.5
SSL Message Exchange: ........................................................................ 41
A4.2.6
SSL Session Establishment: .................................................................... 42
A Note on Link-Level Security in the Home Network .................................... 43
Table of Figures
Figure 1: IPSec Transport Mode—One or more security associations apply between
end stations (adapted from [43]). ........................................................................... 34
Figure 2: IPSec Tunnel Mode—A security association is applied at network boundaries
(adapted from [43]). ............................................................................................... 35
Figure 3: The IPSec Authentication Header (AH) (adapted from [43]). ......................... 35
Figure 4: AH in Transport Mode and in Tunnel Mode (adapted from [43]). In this
example, the IP payload is a TCP segment. .......................................................... 36
Figure 5: The IPSec ESP Header (adapted from [43]). ................................................. 37
Figure 6: ESP in Transport Mode and in Tunnel Mode (adapted from [43]). In this
example, the IP payload is a TCP segment. .......................................................... 38
Figure 7: Iterated Tunneling in IPSec (adapted from [43]). ........................................... 39
iii
Figure 8. The SSL Protocol Stack (adapted from [43]). ................................................ 40
Figure 9. Operation of the SSL Record Protocol (adapted from [43]). .......................... 42
Table of Tables
Table 1: How IPSec, SSL/TLS and Firewall Defend the Home Network against
Common Threats. .................................................................................................. 14
iv
FOREWORD
This standard was developed under the auspices of the R-7.4 Joint CEA/VESA
Subcommittee.
The Video Electronics Standards Association (VESA) established the VESA Home
Network (VHN) Committee in 1995 to develop architecture for a digital, broadband
home network. The VHN standard was initially developed by the VESA Home Network
Committee. However, it was never ratified as a VESA standard.
In June 1999, the Consumer Electronics Association (CEA) established the R7
Committee to help harmonize the several efforts being undertaken to develop home
networking standards. In January 2000, the Board of Directors of VESA and the Board
of Directors of the Consumer Electronics Association agreed to merge the VESA Home
Network and the CEA R7 Committee, by establishing the CEA R7.4 Committee.
After publication of EIA/CEA-851, the “VHN Home Network Specification,” in October,
2000, R7.4 immediately began work on expanding and augmenting Version 1 of the
standard. In order to avoid delays in making new material available, as new sections
are developed, they will be issued as separate standards in the 851 series. This
standard, EIA/CEA-851.2, specifies the implementation of security services for the VHN
Home Network. Another standard in this series, EIA/CEA-851.1 “IP-Based Digital
Telephony for the Versatile Home Network,” was issued earlier. Other standards,
dealing with network management and other topics, will be issued in the near future.
5
1 INTRODUCTION
This standard defines security services for the Versatile Home Network. 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 noncommercial. 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 Versatile 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, cost on the order of $10,000. 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. Once again, an enterprise may
have an IT department that is responsible for network security. The typical
homeowner is unlikely either to acquire the expertise or hire an outside
consultant to do this job. Faced with such a choice, 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’s the way the
business operates.
While passwords and smartcards are accepted as
necessary to protect the company’s resources, it’s 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,
6
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 rules 1.
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. As the VHN is a home intranet—and
IP-based network using web tools for device access and control—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 requirements for VHN security are presented in Section 3. Annex A presents a
discussion of security issues, and a discussion of the factors that were considered in
formulating the requirements in Section 3.
2 GENERAL
2.1
Scope
This standard specifies security services for the Versatile Home Network (VHN), as
defined in EIA/CEA-851, “VHN Home Network Specification.” It assumes an
implementation of a VHN that conforms to EIA/CEA-851 in the following sense: The
network must be digital, and it must be IP-based; furthermore, it uses web tools, such
as HTTP, for device control. (Note that, while the EIA/CEA-851 also defines a network
architecture and requires a backbone topology based on IEEE 1394b, the security
services specified in this standard are not based on any protocols below layer 3 of the
ISO Standard Reference Model; thus, these requirements could be used for networks
other than a VHN, so long as they are digital, IP-based, and use web tools for device
control.)
2.2
Normative references
The following standards contain provisions that, through reference in this text, constitute
normative provisions of this standard. At the time of publication, the editions indicated
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.
7
were valid. All standards are subject to revision, and parties to agreements based on
this standard are encouraged to investigate the possibility of applying the most recent
editions of the standards listed in Sec. 2.2.1. If the referenced standard is dated, the
reader is advised to use the version specified.
2.2.1 Normative reference list
1. Rivest, R., The MD5 Message-Digest Algorithm, RFC 1321, Internet Engineering
Task Force, April 1992
2. Kohl, J. and C. Neuman, The Kerberos Network Authentication Service (V5), RFC
1510, Internet Engineering Task Force, September 1993.
3. Yeong, W., T. Howes, and S. Kille, Lightweight Directory Access Protocol, RFC
1777, Internet Engineering Task Force, March 1995.
4. Secure Hash Standard, FIPS PUB 180-1, National Institute of Standards and
Technology, April 17, 1995.
5. Karn, P., P. Metzger, and W. Simpson, The ESP Triple DES Transform, RFC 1851,
Internet Engineering Task Force, September 1995.
6. Freier, A.O., P. Carlton, and P.C. Kocher, The SSL Protocol Version 3.0.
7. Oehler, M., and R. Glenn, HMAC-MD5 IP Authentication with Replay Prevention,
RFC 2085, Internet Engineering Task Force, February 1997.
8. Krawczyk, H., M. Bellare, and R. Canetti, HMAC: Keyed-Hashing for Message
Authentication, RFC 2104, Internet Engineering Task Force, February 1997.
9. Cheng, P., and R. Glenn, Test Cases for HMAC-MD5 and HMAC-SHA-1, RFC
2202, Internet Engineering Task Force, September 1997.
10. Dierks, T., and C. Allen, The TLS Protocol, RFC 2246, Internet Engineering Task
Force, January 1999.
11. Wahl, M., T. Howes, and S. Kille, Lightweight Directory Access Protocol (v3), RFC
2251, Internet Engineering Task Force, December 1997.
12. Dusse, S., P. Hoffman, B. Ramsdell, and J. Weinstein, S/MIME Version 2 Message
Specification, RFC 2311, Internet Engineering Task Force, March 1998.
13. Dusse, S., P. Hoffman, B. Ramsdell, and J. Weinstein, S/MIME Version 2 Certificate
Handling, RFC 2312, Internet Engineering Task Force, March 1998.
14. Kent, S., R. Atkinson, Security Architecture for the Internet Protocol, RFC 2401,
Internet Engineering Task Force, November 1998.
15. Madson, C., and R. Glenn, The Use of HMAC-MD5-96 within ESP and AH, RFC
2403, Internet Engineering Task Force, November 1998.
16. 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
17. Madson, C., and N. Doraswamy, The ESP DES-CBC Cipher Algorithm With Explicit
IV, RFC 2405, Internet Engineering Task Force, November 1998.
18. Kent, S., and R. Atkinson, IP Encapsulating Security Payload (ESP), RFC 2406,
Internet Engineering Task Force, November 1998.
19. Piper, D., The Internet IP Security Domain of Interpretation for ISAKMP, RFC 2407,
Internet Engineering Task Force, November
20. 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.
21. Harkins, D. and D. Carrel, The Internet Key Exchange (IKE), RFC 2409, Internet
Engineering Task Force, November 1998.
22. Glenn, R., and S. Kent, The NULL Encryption Algorithm and its Use With IPsec,
RFC 2410, Internet Engineering Task Force, November 1998.
23. Kaliski, B, and J. Staddon, PKCS #1 : RSA Cryptography Specifications Version 2.0,
RFC 2437, Internet Engineering Task Force, October 1998.
24. Pereira, R., and R. Adams, The ESP CBC-Mode Cipher Algorithms, RFC 2451,
Internet Engineering Task Force, November 1998.
25. Housley, R., W. Ford, W. Polk, and D. Solo, Internet Public Key Infrastructure : Part
1 : X.509 Certificate and CRL Profile, RFC 2459, Internet Engineering Task Force,
January 1999.
26. 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.
27. Wijnen, B., D. Harrington, and R. Resuhn, An Architecture for Describing SNMP
Management Frameworks, RFC 2571, Internet Engineering Task Force, April 1999.
28. 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.
29. Levi, D., P. Meyer, and B. Stewart, SNMP Applications, RFC 2573, Internet
Engineering Task Force, April 1999.
30. 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.
31. 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.
32. 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.
9
33. Rescorla, E., Diffie-Hellman Key Agreement Method, RFC 2631, Internet
Engineering Task Force, June 1999.
34. Ramsdell, B., Ed., S/MIME Version 3 Certificate Handling, RFC 2632, Internet
Engineering Task Force, June 1999.
35. Ramsdell, B., Ed., S/MIME Version 3 Message Specification, RFC 2633, Internet
Engineering Task Force, June 1999.
36. Hoffman, P., Ed., Enhanced Security Services for S/MIME, RFC 2634, Internet
Engineering Task Force, June 1999.
37. Medvinsky, A., and M. Hur, Addition of Kerberos Cipher Suites to Transport Layer
Security (TLS), RFC 2712, Internet Engineering Task Force, October 1999.
38. Khare, R., and S. Lawrence, Upgrading to TLS within HTTP/1.1, RFC 2817, Internet
Engineering Task Force, May 2000.
39. Rescorla, E., http over TLS, RFC 2818, Internet Engineering Task Force, May 2000.
40. Hodges, J., R. Morgan, and M. Wahl, Lightweight Directory Access Protocol (v3) :
Extension for Transport Layer Security, RFC 2830, May 2000.
41. Advanced Encryption Standard, National Institute of Standards and Technology,
2000.
2.2.2 Normative reference acquisition
 IETF
www.ietf.org

Freier, A.O., P. Carlton, and P.C. Kocher, The SSL Protocol Version 3.0.
Available at home.netscape.com/eng/ssl3/drft302.txt, November 1996.

NIST
www.nist.gov
2.3
Informative References
The following documents contain information that is useful in understanding this
standard. Some of these documents are drafts of standards that may become
normative references in a future release of this standard.
2.3.1 Informative document list
42. Stallings, William, “Cryptography and Network Security: Principles and Practice,”
Second Edition, Prentice Hall, 1999.
43. Kent, S., and R. Atkinson, “IP Authentication Header,” RFC 2402, Internet
Engineering Task Force, November 1998.
44. Bluetooth, www.bluetooth.com
10
45. Rescorla, E., “SSL and TLS,” Addison-Wesley, 2001.
46. Gutmann, P., “Software generation of Practically Strong Random Numbers,”
Seventh USENIX Security Symposium Proceedings, The USENIX Association,
1998, pp.243-257.
47. 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.
48. Thayer, R., N. Doraswamy, and R. Glenn, IP Security Document Roadmap, RFC
2411, Internet Engineering Task Force, November 1998.
49. RFC 2412, “The OAKLEY Key Determination Protocol,” Internet Engineering Task
Force, November 1998.
2.3.2 Informative document acquisition
 Bluetooth
www.bluetooth.com

HAVi
www.havi.org

IETF
www.ietf.org

UPnP
www.upnp.org
2.4 Symbols and abbreviations
AES
Advanced Encryption Standard
AH
Authentication Header
CAST
Carlisle Adams & Stafford Tavares (developer of the algorithm)
DDoS
Distributed denial of service attack
DES
Data Encryption Standard
DH
Diffie-Hellman
DMZ
Demilitarized Zone
DNS
Domain Name System
DSS
Digital Signature Standard
DTV
Digital Television
DVCR
Digital VCR
EIA
Electronics Industry Alliance
11
ESP
Encapsulation Security Payload
FTP
File Transfer Protocol
HMAC
Hash/MAC
HTML
Hypertext Markup Language
HTTP
Hypertext Transfer Protocol
ICMP
Internet Control Message Protocol
IDEA
International Data Encryption Algorithm
IEEE
Institute for Electrical and Electronics Engineers
IETF
Internet Engineering Taskforce
IKE
Internet Key Exchange
IP
Internet Protocol
IPv4
IP Version 4 (the current IP)
IPv6
IP Version 6 (the upcoming IP)
IPSec
IP Security
ISAKMP
Internet Security Association and Key Management Protocol
IT
Information Technology
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
12
SPD
Security Policy Database
SPI
Security Parameters Index
SSL
Secure Sockets Layer
TCP
Transport Control Protocol
TLS
Transport Layer Security
UDP
User Data Protocol
VCR
Video cassette recorder
VESA
Video Electronics Standards Association
VHN
VHN Home Network
VPN
Virtual Private Network
WAN
Wide Area Network
2.5 Compliance Notation
As used in this document “shall” and “must” denote a mandatory provisions of the
standard. “Should” denotes a provision that is recommended but not mandatory. “May”
denotes a feature whose presence does not preclude compliance that may or may not
be present at the option of the implementer.
3 Security Services for the Versatile Home Network (VHN)
The first goal of VHN 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 listed in Section 1: 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.
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
described in Section A2. 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.
13
Threat
IPSec Defense
SSL/TLS Defense
Firewall
Masquerade
Authenticated Key
Exchange
Authenticated Key
Exchange
Access control by
IP address or URL
Replay
Sequence Number
per Packet
TCP Sequence
Number
None
Eavesdropping
Encryption
Encryption
None
Message
Authentication
Code
Message
Authentication
Code
None
Modification
Limit access to
authorized
devices
Ingress filtering to
discard spoofed
packets
Denial of Service
None
None
Cookies, MACs of
Ciphertext
Avoid TCP SYN
Floods by
Requiring Integrity
Checks
Flow control
Resource
Exhaustion
Software Security
Partial Defense
(Authentication
and Data Integrity)
Partial Defense
(Authentication
and Data Integrity)
Partial Defense
device access
control
Configuration
Security
Partial Defense
(Authentication
and Data Integrity)
Partial Defense
(Authentication
and Data Integrity)
Partial Defense
device access
control
Repudiation
No Defense; Use
S/MIME or PGP
No Defense; Use
S/MIME or PGP
None
Table 1: How IPSec, SSL/TLS and Firewall Defend the Home Network against Common
Threats.
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 attacks2. IPSec and SSL/TLS do not explicitly provide protection to
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
14
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, messages need to be
encapsulated in a secure e-mail protocol, either S/MIME or PGP.
Services requiring non-repudiation shall support the S/MIME version 3 protocol (RFCs
2632–2634) [34, 35, 36] and should be backward compatible with the S/MIME version
2 protocol (RFCs 2311, 2312, and 2437) [12, 13, 23].
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 interface is used to protect the home network against external attacks,
then all external access to the residential network shall be configured to go through
such an interface.
3.1 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 (Figure 8), 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 shall 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 shall be equipped with a means to generate
cryptographically strong pseudo-random numbers [46, 47].
We examine each of these configurations, for IPSec and for SSL/TLS, in the following
sections.
3.1.1 IPSec Configurations
IPSec [5, 9, 14, 15, 16, 17, 18, 19, 20, 21, 22, 24, 43, 48,49] provides authentication or
encryption for any IP packets that meet the SA selector criteria in the SPD (see Section
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.
15
A1.3.1). 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 (see Figure 4 and Figure 6). If iterated tunneling is used (p. 38 and Figure 7)
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 systems 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 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 shall 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 [26, 27, 28, 29, 30, 31, 32] directly with the internal device or its proxy.
An access interface shall 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
shall be capable of rejecting all other accesses.
An access interface shall 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 new group mode.
16
An access interface shall provide a logging and auditing tool to record all accepted and
rejected external accesses. Minimally, a circular buffer of 10M bytes of storage shall
be allocated to record such data.
An access interface implementation of IPSec shall support the PMTU discovery
mechanisms in RFC2401 [14].
An access interface implementing IKE may support only the SIT_IDENTITY_ONLY
situation, but it shall support PKIX and should support LDAPv2 [3] for certificate
management. It may support LDAPv3 [11].
Public key technology shall comply with IEEE1363.
Applications shall use at least 1024-bit modular exponentiation,163-bit elliptic curve
groups, or 448-bit (251) NTRU.
An access interface shall 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 [1] or SHA-1 [4] shall
be supported.
Applications shall use AES [41] as the symmetric encryption algorithm.
Except as modified by these requirements, IPSec implementations shall conform to
IETF IPSec standards track RFCs at the currently highest level of standardization.
3.1.2 SSL/TLS Configurations
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 webbased access to the VHN 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
17
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 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 shall 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 shall support SSLv3 with RSA [6]. It may also support
SSLv3 with DSS and DH [33] or TLS 1.0 or later [10, 37, 38, 39, 40]. 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
18
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 [25] 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.
For RSA or DH-DSS, key lengths shall be at least bits1024bits, ECC key length shall
be at lest 163-bits, and NTRU key length shall be at least 448-bits (251) This applies
to all certifiactes in the chain. Applications requiring confidentiality shall use128-bit
AES [41], when implemented; otherwise, applications requiring confidentiality shall use
triple DES. Browsers supporting only 40-bit keys single shall be rejected by the server.
Browsers and servers shall 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 shall be encrypted and
password protected, and the system shall log all attempted accesses securely.
Both parties shall 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 shall be restricted accordingly. Where
practical, processes should be locked in main memory and not paged.
For SSLv3 [6], the protocol version is major=3, minor=0, and port and protocol selection
and use shall follow RFC 2818. The server shall 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 shall 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 shall 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 [10] is supported (protocol version is major=3, minor=1), the requirements for
connection closure, use of port numbers, checking of the server’s identity, and checking
the client’s identity in [39] shall be followed, the name matching rules specified in [25]
shall be followed, and servers should, and browsers may, support the use of port
numbers described in [38].
19
3.1.2.1 Securing the Browser
In general, new browsers (released in 2000 or later) are preferred over older ones,
because older protocols like SSLv2 have security defects, and cryptographic strength
has increased since the easing of U.S. export restrictions in January 2000.
The browser should be a version released after January 1, 2002. 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 shall be instructed to exit the browser or lock the terminal before
leaving the workplace.
3.1.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.
3.2 Firewall
The home network shall 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
20
implementation shall follow the guidelines described in the latest version of RFC 2979
(“Behavior of and requirements for Internet firewalls”).
Note: Firewalls are difficult to configure, and the correct and conventional setting of
critical parameters is usually learned from experience in specific environments. At this
time, there are very few home networks that have the scope of a VHN, and that could
be used to guide the specification of these parameters. 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 shall provide the
following functions:

Pass or block incoming (from WAN) connection requests

Pass or block outgoing (from LAN) 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

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

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.
3.3 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 shall 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 shall
make it difficult for the end user or attacker to delete or corrupt log contents. The log
format shall be TBD with a minimum size of TBD. All log entries are time stamped.
Deletion of old entries shall be independent of the time stamp.
The logger shall capture at least the following information:

New device attach and discovery
21

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
22
ANNEX A: Security Services
(Informative)
A1 Introduction
This section considers the likely external threats to the VHN Home Network, and
recommends defense mechanisms and security services.
A2 Home Network Threats
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 noncommercial. 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.
We have identified the following threats to the VHN Home Network:
Masquerade and Replay
Perhaps the most obvious threat to the home is unauthorized access to devices or
databases on the home network. A masquerade takes place when an imposter
pretends to be a legitimate user, such as the homeowner. The imposter could also
pretend to be a service provider that has contracted with the homeowner.
Defeating the authentication mechanism, e.g., guessing a password or stealing a token
may affect a masquerade. Another way an imposter may trick the home network into
thinking it is an authorized user is for the imposter to capture a legitimate message, and
resend it at a later time. For example, if the imposter can intercept a message to the
home’s burglar alarm system, telling it to turn off, she could replay that same message
at a later time to achieve a desired result.
Masquerade and replay attacks can be thwarted by use of authentication, authorization,
and integrity mechanisms, which are discussed in Sections A3.2 and A3.3.
Interception: Eavesdropping, Modification, and Traffic Analysis
An interception occurs when an unauthorized party gains access to a message passing
between the home network and an external user. The intruder may be an automated
system that is programmed to search for vulnerable messages, or it may be a person
who has wiretapped or otherwise violated the integrity of the communications channel.
The interception may be passive or active; a passive interception amounts to
eavesdropping—in effect, reading someone else’s traffic. An active interception may
involve changing the contents of the message, deleting or rearranging part of the
23
communication, or changing its protocol control information, particularly the header
(including the destination or source address).
The key defense for an interception attack is to implement integrity and confidentiality
services, which are discussed in Section A3.3. Authentication (Section A3.2) may also
be used to thwart modification attacks.
Even if all communication employs integrity and confidentiality services an
eavesdropper may learn a great deal about the home network by monitoring source and
destination information and the time of each message. This is called traffic analysis.
Internal home network communications can be protected from traffic analysis by
creating dummy traffic to hide useful messages. Communication outside the home
network can be hidden by anonymizer services. Note that protecting the internal
network is possible by use of strong authentication messages, while protecting against
external messages is more difficult.
Denial of Service and Resource Exhaustion
A denial of service attack is effected by flooding the access network with useless traffic,
thus preventing legitimate messages from reaching the home network. The incoming
messages could also force the home network to try to respond, tying up resources in
the access device, thus impairing outgoing traffic. The home network may be a victim
of a DoS attack, or an unwitting participant: If a computer on the home network is
compromised the attacker may able to use it to contribute to the packet flood without
the knowledge of the homeowner. This is called a Distributed Denial of Service (DDoS)
attack. Denial of service attacks are almost impossible to defend against in real time.
In fact, security mechanisms alone cannot be effective against denial of service attacks,
as it is trivially easy to overwhelm any defense by sending additional bogus messages.
Careful design and implementation of the protocol and access device can mitigate
resource exhaustion, whereby the flooding ties up parts of the home network or access
device. For example, if the access device recognizes that it is being asked to open
5,000 simultaneous TCP connections, it could go to an alarm condition, in which it
ignores additional incoming requests that are not properly cryptographically
authenticated, and it gives priority on its output queues to messages originating in the
home.
To insure the home network does not become an unwitting participate in a DDoS attack
measures must be taken to ensure illicit software is not installed; this is covered in the
next section. Access control devices should implement ingress filtering, as specified in
RFC 2267; this prevents the use of spoofed IP addresses. It has no effect if the
attacker uses valid network addresses. Ingress filtering makes tracking down the
source of the attack much easier because the packet source address is the source of
the traffic. An additional benefit is the victim’s response is returned to the attacking
system, thus preventing additional damage. To perform Ingress filtering the access
devices blocks any packets with sources addresses that do not originate within the
home network.
24
Software and Configuration Security: Trojan Horses, Worms, Viruses
These are threats to the integrity of the software and configuration information on the
access device and home network devices. A Trojan Horse is an unauthorized program
that enters the home or the access device hidden in a legitimate message. Once in the
home, the Trojan Horse can reside in a processor in any networked device. For
example, a Trojan Horse can be inserted into an intercepted MPEG transport stream as
private data, and take up residence in the processor of the digital television. It could
then use the resources of the television’s processor, and the digital home network, to
compromise the security of the internal network.
Worms and viruses have received considerable publicity in both the technical and
popular press. A worm is a program that can replicate itself and send copies from
computer to computer across network connections [42]. Upon arrival, the worm may be
activated to replicate and propagate again. In addition, the worm usually performs
some unwanted function. A worm that invades the home network could thus spread
across the network to multiple devices; if the worm performs harmful activity, such as
wiping out the non-volatile memory of the device, the homeowner could find that
multiple appliances, from DTVs to toasters, no longer work properly.
A virus is code embedded within a program that causes a copy of itself to be inserted in
one or more other programs, as well as performing some unauthorized function on the
host machine [42]. Unlike a worm, a virus will not actively try to spread itself to other
processors on the home network, so its damage will be confined to a single appliance.
However, an appliance essential to the operation of the home network may function in
unpredictable and undesired ways.
Trojan Horses, worms, and viruses are defended against using software security
services. As these are the same services that are now commonly available to both
enterprises and consumers, we will assume that strategies for protecting the home
network (and the access device) will also be the same.
Certain attacks may attempt to compromise the home network configuration by altering
security information. Three examples of this type of security information are addresses
of external servers, trusted public keys or passwords used in the authentication
process, and rules for filtering unwanted traffic at an access interface.
Repudiation
The last home network threat is repudiation, the denial of receipt or transmission of a
message. Repudiation is an obvious and important threat to a business that relies on
electronic traffic. For example, a stockbroker who executes a trade in response to an
electronic sell order may be vulnerable to a repudiation attack if the customer claims
(probably because the price of the stock suddenly changed) that the order, in fact, was
never sent. For the home network, a repudiation attack probably isn’t as threatening as
the others we have listed; it is, nevertheless, important that the homeowner be able (for
instance) to defend against claims for payment for undelivered service to the home
network or access device.
25
A3 Home Network Defenses
The threats in Section 3 are not peculiar to home networks. They exist as threats to
enterprise networks as well and, with the exception of the denial of service attack
(which has no adequate real-time defense), security mechanisms and services have
been developed to counter these threats. Thus, 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, cost on the order of $10,000. 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. Once again, an enterprise may
have an IT department that is responsible for network security. The typical
homeowner is unlikely either to acquire the expertise or hire an outside
consultant to do this job. Faced with such a choice, 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’s the way the
business operates. While passwords and smartcards are accepted as
necessary to protect the company’s resources, it’s 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 rules 3.
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.
3
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.
26
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. These tools encompass two general
categories: a) authentication and authorization, and b) integrity and confidentiality. All
of these techniques rely on encryption, so we begin with a discussion of encryption
technologies.
A3.1 Encryption
Encryption is by far the most important security mechanism, as it is the core of most
security services, and even of most other security mechanisms.
Encryption has a long and famous history; modern encryption relies on the special
properties of mathematical and logical operations that may be applied to the binary
representation of data. The two major classes of encryption algorithms are private-key
and public-key systems4. Each has particular strengths that make them suitable for
different security tasks.
A3.1.1 Conventional Encryption
In conventional ciphers, a message is converted from plaintext to an unreadable
cyphertext, using an algorithm and a secret key. In almost all cases, the algorithm is
known to both the receiver and sender, as well as to the attacker, but the key is a secret
shared only between the receiver and sender. The sender uses the key with the
algorithm and the plaintext to produce an apparently random cyphertext; any other key
produces a different cyphertext. The receiver uses the same key, with the same
algorithm (sometimes run in reverse) to convert the cyphertext to the original plaintext.
An attacker that wants to read the plaintext message must either guess the key, or must
use the statistical properties of the cyphertext to deduce the plaintext, a process known
as cryptology. The defense against a cryptologic attack is to construct the algorithm in
such a way as to hide the statistical properties of the plaintext, using elements of
“diffusion” and “confusion.” Given the computation power available in modern systems,
conventional encryption schemes must be of formidable complexity to withstand
cryptologic attacks.
If the attacker despairs of unraveling the cyphertext using cryptology, she might attempt
a brute force attack on the secret key by systematically trying every possible
permutation of ones and zeros. Thus, if a secret key were 56-bits long (i.e., a possible
256 different sequences of 1s and 0s), an attacker would have a 50% chance of
guessing the key in the first 255 attempts. The only defense against a brute force attack
is to increase the length of the key. The minimum key length used for any serious
encryption system today is 56-bits; 112-bit, 128-bit, and 168-bit systems are also in use.
One system (Blowfish) allows keys as long as 448-bits.
4 To
avoid confusing “private-key encryption” with the “private key” used as part of public key systems, in
this standard we will refer to private-key encryption systems as “conventional” encryption systems.
27
A3.1.2 Public-Key Encryption
A major problem with conventional encryption is that the sender and receiver, and only
the sender and receiver, must share the secret key. Thus, key distribution is an
important element of any security service that uses a conventional encryption system;
elaborate mechanisms have been developed for generating and delivering keys.
Public-key encryption eliminates the need for the sender and receiver to share a single,
secret key. In public-key encryption, one key is used to encrypt a message, and a
second key is used to decrypt it. One of the keys is “public”; i.e., it is published and
available to anyone; the second key is “private” known to only one of the parties. Either
key may be used for encryption, but only the companion key can be used for
decryption; given one of the keys and the algorithm, it is computationally infeasible to
infer the other key.
Public-key encryption works like this:
1. Each end system generates a pair of related keys.
2. One key is chosen by the user to be the “public” key, and is published in a public
register or file; the second key is kept private.
3. If A wishes to send a message to B, A encrypts the message using B’s public
key.
4. When B receives the message, B decrypts it using B’s private key (which only B
knows).
5. No one else can decrypt the message, because no one else has B’s private key.
Furthermore, as no secret keys were exchanged, there is no danger of an
attacker intercepting a secret key, as there is in conventional systems.
A3.1.3 Digital Signatures and Key Exchange
Public-key algorithms are much simpler than conventional algorithms, but running them
takes a lot of computer time, so public-key systems are not generally used to encrypt
documents or long messages; instead, they are used to generate digital signatures,
which are used to guarantee the authenticity of the sender, and for exchanging secret
keys to be used in conventional cryptography.
When public-key encryption is used for digital signatures, the sender produces an
abstract of the document, and then encrypts it using his private key, producing a
signature. The recipient decrypts the signature using the sender’s public key; as only
the unique public key—private key pair will successfully encrypt and decrypt the
abstract, the recipient is ensured that only the sender could have encrypted the
abstract.
The abstract that is used for the signature is often generated from the document using
a hash function, which produces a fixed-length data block derived from the message,
and called a hash code. The hash function is usually an algorithm based on
conventional encryption. The sender generates the hash code using a secret key and
the conventional encryption algorithm; the hash code is then encrypted using the
sender’s private key. The recipient decodes the signature using the sender’s public
28
key, and the hash code is revealed. The recipient then regenerates the hash code from
the message, using the same secret key that the sender used; if the two hash codes
match, the document is authentic.
The secret key used to generate the hash function, and to encrypt the document itself,
may be sent to the recipient using a key exchange mechanism in which the secret key
is encrypted using the recipients public key, as described above. As the secret key is
relatively short5, the public-key encryption algorithm takes relatively little computer time
to encrypt it and decrypt it; the conventional algorithm is then used to provide
encryption for the message itself, and to generate the hash function.
A3.1.3.1
Diffie-Hellman Key Exchange
Another public-key mechanism for distributing secret keys is the algorithm that
appeared in the first public paper to describe public-key encryption. Diffie-Hellman Key
Exchange allows two users to securely exchange a secret key, which is also generated
by the algorithm itself. Diffie-Hellman (DH) is based on calculating exponents using
modulus arithmetic with a prime number base. While this is a relatively simple
calculation, the inverse process of finding the logarithm modulo a prime number (called
a discrete logarithm) is extremely difficult.
There are two publicly known numbers used in a Diffie-Hellman key exchange: A prime
number q and an integer  that is a primitive root of q6. If A and B wish to exchange a
key, A selects a random integer XA < q and computes YA = XA mod q. B
independently selects a random integer XB < q and computes YB = XB mod q. The Y
values are exchanged, and the X values are kept private. A may then compute a value
K= (YB)XA mod q, and B may compute a value K = (YA)XB mod q. It can be shown that
the two calculations will produce the same K; thus, A and B have generated a number K
that can be used as the secret key. The system is secure against attack because an
opponent who had access to only YA or YB could discover the corresponding X value
only by taking a discrete logarithm, e.g., XA = ind,q(YB), where ind,q is the discrete
logarithm. Finding the discrete logarithm is so difficult as to be computationally
infeasible.
A3.2 Authentication and Authorization
An authentication service is used to ensure that the identity claimed by a party to a
communication is correctly verified, whereas an authorization service ensures that the
identified and authenticated party is entitled to access a particular device or application
on the home network.
5
168 bits is only 21 octets, corresponding to 21 letters, as in the phrase: “This is a secret key!”
If a is a primitive root of a prime number p, then the numbers a mod p, a2 mod p, …, ap-1 mod p, are
distinct and consist of the integers from 1 through p-1 in some permutation. [42] contains a useful
introduction to modulo arithmetic.
6
29
In general, authentication is the most confusing and complicated of security functions.
Ultimately, it requires direct prior contact between the parties or one or more trusted
third parties to vouch for the identity of a potential user, but the network of trusted
parties that may evolve from this simple requirement can be staggeringly complex.
Authentication can be as simple as supplying a password, but more than that will be
needed to counter threats to the home network: First, the authentication process
should not allow someone who observes and records it, even multiple times, from later
carrying out a successful masquerade attack. Thus, if passwords are used, they cannot
simply be transmitted from one party to another, but they must be hidden by some
cryptographic protocol. Second, the authentication process should be two way; that is,
both parties should be authenticated to each other; otherwise, it is not possible to
protect against man-in-the-middle attacks, in which the attacker gets “between” the two
legitimate parties, say Alice and Bob, and pretends to be Bob to Alice and Alice to Bob.
Third, the authentication process should simultaneously establish a fresh, shared secret
that Alice and Bob can use to protect the confidentiality and integrity of their entire
communications session. There exist additional technical requirements as well: for
example, the protocol should be safe against large-scale guessing attacks, and it
should remain secure even when many instances of the protocol are run
simultaneously. Examples of such comprehensive authentication protocols are
Kerberos [2], IPSec [14], and SSL/TLS [6], [10].
A3.2.1 Firewalls
Firewalls are designed to prevent unauthorized traffic between devices or networks. A
Firewall may protect a single computer, portions of the local home network from each
other or the entire home network from the Internet. A firewall implements a set of rules
that determine if a pair of computers is allowed to communicate. Firewalls provide an
effective defense by excluding undesirable traffic at the edge of the network as
possible. This reduces the attacker options to those messages allowed to traverse the
firewall.
There are several firewall techniques:

Packet filter: Examines each packet entering or leaving the network and
accepts or rejects it based on policy rules. Packet filtering is fairly effective and
transparent to users, but it is difficult to configure.

Application Level gateway: Applies security mechanisms to specific
applications, such as FTP and Telnet servers. This is very effective but requires
the firewall to be aware of each application.

Circuit-level gateway: Applies security mechanisms when a TCP or UDP
connection is established. Once the connection has been made, packets can
flow between the hosts without further checking.

Proxy server: Intercepts all messages entering and leaving the network.
Internal devices must be configured to use the proxy server in order to
communicate with external hosts. To the external host traffic appears to
30
originate and terminate at the proxy, effectively hiding internal network topology
and device identities.
A3.3 Integrity and Confidentiality
Integrity ensures that only authorized parties are able to create acceptable messages,
and that no one else can modify the contents of messages. Integrity essentially
embodies the authorization to write a message. Conversely, confidentiality ensures that
the message is readable only by authorized parties.
Authentication, as described above, is used to set up the cryptographic keys that are
used to protect both the integrity and confidentiality of the contents of a session.
Integrity is then achieved by adding a sequence number and MAC (see below) to the
message. Confidentiality is accomplished by encrypting the message with an encryption
algorithm and key that are sufficiently strong to foil attempts at decryption by an
eavesdropper, while at the same time being easy to encrypt and to decrypt by the
authorized users. It should be emphasized that such an encryption operation does not
guarantee the integrity of the message.
Because public key encryption is processor intensive and comparatively slow, it is not
generally used for encrypting “user” messages; instead, conventional (symmetric)
ciphers are used to provide message confidentiality. However, conventional ciphers
require that a secret key be shared between the sender and receiver, and because
conventional secret keys are only a few octets long, public key ciphers are often used
as components of the authentication and key distribution protocols described above.
A3.3.1 Message Authentication Code (MAC)
A Message Authentication Code, or MAC, is used as the integrity function for IPSec
and for SSL/TLS7. A Message Authentication Code is a small, fixed-size block of data,
generated from the message using a secret key, and then appended to the message.
Let us assume that Alice and Bob possess a secret key K, and that Alice wishes to
send a message to Bob. Alice generates the MAC using the MAC function and K and
appends the MAC to the message. When Bob receives the message, he also
generates the MAC, using the same MAC function and the same K. He then compares
the generated MAC with the MAC appended to the message. If they are identical, Bob
knows that Alice sent the message, because only Alice and he have K.
Bob also knows that the message is legitimate, i.e. that it has not been altered,
because if it had been, Bob would have generated a different MAC from the one
received with the message. Note that the MAC does not provide message
confidentiality. Also note that there is no need for Bob to perform any decryption, as he
merely needs to recalculate the MAC. In many cases, message integrity can be
7
IPSec specifies the HMAC algorithm [8], using either MD5 [1] or SHA-1 [4] as the underlying Hash
function; see Section A.1.2.3.2. SSL/TLS uses an early version of the HMAC algorithm [7]; see Section
A4.2.
31
implemented more efficiently than confidentiality. Note that K must be secret, and kept
secret, until the message is checked.
A3.3.2 Hash Functions and Digital Signatures
A hash function produces a fixed length message digest that is generated by applying
the function to an entire message. The hash function itself does not use an encryption
mechanism to generate the message digest and thus does not use a secret key. Its
strength is in its one-way nature. Although it is easy to generate a message digest from
a plaintext message, it is extremely difficult to alter a message in such a way that
applying the hash function will result in the same message digest as for the original
message. In fact, a hash function is considered broken if any two messages with the
same message digest can be found.
MACs are often implemented applying a hash function to the message and the key in
certain secure ways. The hash function thus provides a tool that can easily be used for
ensuring message integrity.
A digital signature is usually produced with public key encryption by encrypting a
message digest with the Alice’s (the signer’s) private key. Bob (the verifier) is assured
that the message came from Alice, because only she possesses her private key; he is
also assured that the message is legitimate, because altering the message would alter
the message digest.
The essential difference between a MAC and a digital signature is as follows. When
Bob verifies a MAC on Alice’s message, he knows that only he and Alice had the key,
and he didn’t create the MAC, so she must have. But if he shows the message, MAC,
and key to a judge and says, “Look what Alice said,” the judge should reply, “I’m not
convinced; you could have made that up yourself.” With a digital signature, the situation
is different. Only Alice has the signing key, so Bob has a good basis for his claim. This
is what is meant by saying that digital signature provides support for non-repudiation.
Alice’s ability to repudiate the message with her signature is severely constrained. The
protocols like IPSec and SSL described below use MACs, not digital signatures, to
protect the messages, so if non-repudiation is needed (say, to commit to a purchase),
protocols like S/MIME [34] should be used in addition.
Note that the authentication protocols in IPSec and SSL used to set up the
confidentiality (encryption) and integrity (MAC) keys commonly use digital signatures,
even though the protected traffic itself is not signed.
Note also that because hash functions are of fixed length, and may be much shorter
than the associated message, the use of public key cryptography does not impose an
undue burden.
Note, finally, that a hash function, digital signature, or MAC does not, by itself, provide
message confidentiality; confidentiality requires further encryption functions, as
described in Section A3.3.
32
A4 Home Network Security Solutions
The previous sections described some security tools and mechanisms. This section
covers how they can be combined into a system that implements multiple security
services partially satisfying a home network security policy. Existing security systems
deployed in products today will be the starting point for home network security. This
section describes additional security systems for home networks.
The VHN Home Network assumes that IP will be used to access controlled devices and
that web-based tools (i.e., web servers and web browsers, using HTTP and HTML) will
provide the user interface to the control mechanisms. In this model, the most important
security systems for the home network are likely to be IP Security (IPSec) [14] and
Secure Sockets Layer (SSL) [6], or its IETF version, Transport Layer Security (TLS)
[10]. IPSec provides authentication, key management, integrity, replay detection, and
confidentiality services for IP-based communications. SSL/TLS does the same for webbased (HTTP) communication. These services are described below.
A4.1 IPSec
IPSec provides security services at the IP layer that allow the user to apply
combinations of integrity, replay detection, and encryption to IP packets. It also
provides a mechanism for users to authenticate each other and generate and exchange
session keys, secret keys that are used for a limited time (a session), and then
discarded. IPSec also allows users to choose where, in the transmission path, to apply
the security services: at either or both end devices, or at a intermediate nodes, such as
routers or access devices. IPSec is the principal service used by enterprises to
establish Virtual Private Networks (VPNs). IPv6 will incorporate IPSec as a required
part of IP; however, IPSec may also be used with IPv4. In this section, we describe
only the IPv4 implementation of IPSec.
A4.1.1 Security Associations and the Security Policy Database
At the heart of IPSec are the security association (SA), a one-way relationship between
sender and receiver that defines the security mechanisms to be used, and the Security
Policy Database (SPD), which allows the sender to apply security associations
selectively to outgoing IP packets.
A security association (SA) specifies a security mechanism (AH, Authentication Header
[3], or ESP, Encapsulating Security Payload [18]) and a set of parameters including the
security services (integrity, encryption, or integrity plus encryption), cryptographic
algorithms, and other important data, such as keys and expiration time. The SA is
named by the IP destination address and a 32-bit value called the Security Parameters
Index (SPI). Each of these services are implemented by applying the specified
cryptographic algorithm to an IP packet and then inserting a security header on it. This
header corresponds to the mechanism: one format is used for AH, another for ESP.
The Security Policy Database (SPD) consists of a list of SA selectors that determine the
processing of outgoing IP packets. Packets may be sent unprotected, dropped, or
mapped to an SA bundle. Selectors examine parameters such as destination IP
33
address, user ID, transport layer protocol (e.g., TCP or UDP), or source or destination
ports.
A4.1.2 Transport Mode and Tunnel Mode:
The security services of IPSec may be applied in transport mode or in tunnel mode.
In transport mode (see Figure 1), security must be applied at the originating node and
removed at the terminating node. AH authenticates the IP payload and part of the IP
header, while ESP encrypts or authenticates the IP payload, but not the IP header. In
transport mode, the IP header specifies AH or ESP as the next protocol; in the case of
AH, the AH header explicitly names the next protocol, e.g., TCP, whereas with ESP, the
next protocol is encoded near the end of the (potentially) encrypted payload.
One or more Security Associations
Host
(IPSec)
Router
Network
Host
(IPSec)
Router
Network
Network
Figure 1: IPSec Transport Mode—One or more security associations apply between
end stations (adapted from [42]).
In tunnel mode (see Figure 2), security may be applied either at an end device or at a
router. The AH or ESP header is attached, as in transport mode, but the next protocol
is IP again. The original packet is treated as the payload of a new IP packet with new
IP header; the security mechanisms are applied to the entire new payload (original IP
packet plus security header), thus protecting both the original IP packet and the original
IP header.
The new IP header may have completely different IP source and destination addresses
from those in the original IP header; in fact, this new header is usually used to route the
packet between routers or gateways, which serve as the source and destination for the
secured payload. Thus, the encrypted packet travels through a tunnel from the
originating router or gateway to the receiving router or gateway, where the protection is
removed. The original IP header is then revealed and used to complete the routing of
the packet.
34
In tunnel mode, AH authenticates the entire inner IP packet (including the original
header), and part of the outer (new) IP header. ESP applies encryption, the integrity
service, or both to the inner IP packet and its header.
Tunnel Security Association
Host
Router
(IPSec)
Network
Host
Router
(IPSec)
Network
Network
Figure 2: IPSec Tunnel Mode—A security association is applied at network boundaries
(adapted from [42]).
A4.1.3 Authentication Header (AH):
AH (Figure 3) provides data integrity service by prepending a MAC (see Section
A.1.2.3.1 above) and a sequence number. The MAC is calculated over the portions of
the IP header that do not change in transit (“immutable” fields, such as the IP source
address), or that are predictable at the receiver (e.g., the IP destination address), the
AH header itself (other than the MAC value), and the IP payload.
0
8
Next Header
31
16
Payload
Length
Reserved
Security Parameters Index (SPI)
Sequence Number
Authentication Data
Figure 3: The IPSec Authentication Header (AH) (adapted from [42]).
35
The IPSec specification requires the use of HMAC [8], using either the MD5 [1] or SHA1 [4] hash function. Users must share a secret key; which is affected by the key
management function of IPSec, described below. A 12-octet field in the AH header
contains the first 96 bits of the HMAC hash value.
The AH header also contains a 4-octet sequence number that is incremented each time
a packet is sent, to defend against replay attacks. Because IP is an unreliable
datagram service, packets may arrive out of sequence, so the receiver must implement
a sliding window that allows received packets to be tagged according to sequence
number.
In transport mode (Figure 4), the AH header is placed between the IP header and the
payload. The integrity service covers the entire packet, excluding mutable fields in the
IP header. In tunnel mode, the AH header is placed between the original IP header and
the new, outer IP header. The MAC is computed over the entire original IP packet
(including the entire IP header), and outer IP header, excluding mutable fields.
Authenticated except for mutable fields
Original
IP Header
AH
TCP
Header
Data
AH in Transport Mode
Authenticated except for mutable fields in the new IP header
New
IP Header
AH
Original
IP Header
TCP
Header
Data
AH in Tunnel Mode
Figure 4: AH in Transport Mode and in Tunnel Mode (adapted from [42]). In this
example, the IP payload is a TCP segment.
A4.1.4 Encapsulating Security Payload (ESP) Header:
The ESP service can provide message confidentiality, limited traffic flow confidentiality,
message integrity, and replay detection. AH cannot provide the former two services.
ESP can use any of several conventional (i.e., symmetric) ciphers for the confidentiality
service. It is mandatory that DES be implemented, but there are alternatives with
greater cryptographic strength that may be implemented as options, including three-key
36
triple DES, RC5, IDEA, three-key triple IDEA, CAST, and Blowfish8. AES will be added
soon. The optional authentication service uses the same HMAC algorithms as specified
for AH.
0
8
31
16
Security Parameters Index (SPI)
Sequence Number
Payload Data (variable)
Padding (0-255 Bytes)
Pad Length
Next Header
Authentication Data (Optional)
Figure 5: The IPSec ESP Header (adapted from [42]).
In transport mode (Figure 6), ESP can provide confidentiality for any application,
making it unnecessary to implement confidentiality in each application. At the
originating host, the ESP header is inserted between the IP header and the IP payload,
and an ESP trailer is appended to the IP packet. Then, the payload and trailer are
encrypted; if authentication is also provided, an ESP authentication data field,
containing the MAC code, is placed after the ESP trailer. The encrypted payload, ESP
header, and ESP trailer are authenticated. The packet is authenticated and decrypted
in reverse order at the receiving host.
8
A brief introduction to these ciphers may be found in [42], which also contains an introduction to
cryptography.
37
Authenticated
Encrypted
Original
IP Header
TCP
Header
Data
ESP
Tlr
ESP in Transport Mode
Authenticated
Encrypted
New
IP Header
Original
IP Header
TCP
Header
Data
ESP
Tlr
ESP in Tunnel Mode
Figure 6: ESP in Transport Mode and in Tunnel Mode (adapted from [42]). In this
example, the IP payload is a TCP segment.
In tunnel mode, the entire IP packet, including the header, may be encrypted at an
access interface or external router to provide limited protection against traffic analysis,
because it is impossible to determine the original source IP address or the ultimate
destination. Authentication and decryption are performed at the receiving access
interface or router, which relieves the burden on individual hosts of providing encryption
and authentication services and simplifies both administration and key management
(see below). Tunnel mode ESP is the service commonly used to implement VPNs for
enterprise networks.
A4.1.5 Combining Security Associations
Security associations for a transport stream may be combined into a security
association bundle: In a transport adjacency bundle, both AH and ESP are applied to a
packet, which allows the IP source and destination addresses to be authenticated9.
A more common way to combine SAs is called iterated tunneling (Figure 7), in which
different SAs are applied at various points in the transport stream. For example, AH
may be applied in transport mode, and ESP in tunnel mode, providing authentication of
the original packet and original IP header, and encryption for the entire packet, and
header, as well as defense against traffic analysis.
9
Note that using ESP in transport mode with the authentication option does not authenticate any fields in
the IP header; see Figure 6.
38
One or more Security Associations
Tunnel SA
Host
(IPSec)
Router
(IPSec)
Network
Host
(IPSec)
Router
(IPSec)
Network
Network
Figure 7: Iterated Tunneling in IPSec (adapted from [42]).
A4.1.6 Key Management:
Because both AH and ESP need shared secret keys, an automated key distribution
mechanism is needed to provide the transmitter and receiver with these keys. IPSec
defines the Internet Key Exchange (IKE) [21] protocols, which uses the OAKLEY Key
Determination Protocol [49] to generate keys, and the Internet Security Association and
Key Management Protocol (ISAKMP) [20] to manage the key distribution; ISAKMP is
also used to set up and delete security associations.
Oakley is an enhancement of the Diffie-Hellman Key Exchange protocol. Diffie-Hellman
requires users to agree publicly on two global parameters: a large primary number p,
and , a primitive root of p. Once these parameters are set, the parties can each
calculate a secret key merely by passing, in the clear, numbers derived from these
values. Thus, secret keys are created only when needed, and no infrastructure is
needed to generate or pass the keys, beyond establishing p and . However, DiffieHellman as described here (Section A.1.2.1.3.1) performs key agreement without
authentication. In Oakley, the parties go through the key agreement stage and then
exchange signatures on their transcripts of the entire exchange to authenticate the
other party and ensure that all messages were delivered intact without any active
attacks on the protocol. The difficult part of the process is setting up an infrastructure
with which to verify these signatures.
ISAKMP sets up and modifies security associations; in fact, an IPSec SA begins with
the exchange of ISAKMP packets. An ISAKMP message, carried in a UDP segment,
consists of an ISAKMP header followed by an ISAKMP payload. The header contains
a pseudorandom number called a cookie, which is used to authenticate the sending
party and counter a clogging attack, which is similar to a resource exhaustion attack; it
also identifies the type of payload that follows. The payload itself contains the
information needed to establish an SA, pass values of p and , and generate the secret
session keys needed for encryption and integrity checks.
39
A4.2 SSL/TLS
Netscape developed SSL [45], the Secure Sockets Layer protocol, to implement
security on HTTP-based communications. SSL Version 2 contained design
implementation defects, and both Microsoft (PCT) and Netscape (SSLv3 [6]) proposed
improvements. The IETF formed the TLS Working Group to develop a common
standard. Version 1 of TLS, the Transport Layer Security protocol [10], was issued in
January, 1999. As TLS is functionally almost identical to SSL, and as SSL is already
widely deployed, it is not obvious that TLS will displace SSLv3 any time in the near
future. Therefore, this section concentrates on the features and specifications of
SSLv3 but generally refers to the “generic” SSL/TLS protocol.
A4.2.1 SSL/TLS Record Protocol and SSL/TLS Handshake Protocol:
SSL/TLS is a collection of protocols that lie above the transport layer and use the
services of TCP to send secured messages between parties. As stated in the SSL
specification [6]: “The SSL Record Protocol is used for encapsulation of various higher
level protocols. One such encapsulated protocol, the SSL Handshake Protocol, allows
the server and client to authenticate each other and to negotiate an encryption
algorithm and cryptographic keys before the application protocol transmits or receives
its first byte of data. One advantage of SSL is that it is application protocol
independent.
A higher level protocol can layer on top of the SSL Protocol
transparently.” This “higher level protocol” is usually HTTP.
SSL
SSL Change
Handshake Cipher Spec
Protocol
Protocol
SSL
Alert
Protocol
HTTP
SSL Record Protocol
TCP
IP
Figure 8. The SSL Protocol Stack (adapted from [42]).
A4.2.2 The SSL Session and the SSL Connection:
Two important concepts for SSL are the SSL Session and the SSL Connection. An
SSL Session is an association between a client and server, set up by the SSL
Handshake Protocol that defines a set of cryptographic security parameters. An SSL
Connection is a virtual channel between two communicating entities. While a
connection may be short-lived, a session may persist for a long time. Each connection
is associated with a single session, but a session may be associated with multiple
40
connections. Thus, once a session is established, parties may open and close many
connections by using the security mechanisms and parameters of the session.
A4.2.3 SSL Session States:
A session is characterized by its states, which are defined by the ciphers chosen for
encryption and data integrity, an optional compression method, and a master secret
that is used to generate various secret keys. Each session is identified by an arbitrary
byte sequence called a session identifier. While the SSL Handshake Protocol is setting
up or changing a session, the parameters being fixed by the SSL Handshake Protocol
constitute the pending state of the session. When the SSL Handshake Protocol has
successfully completed, the SSL Change Cipher Spec protocol is invoked, and the
pending state becomes the current state of the session.
A4.2.4 SSL Connection States:
A connection is also characterized by its states, which are defined by the secret keys
chosen for encryption and data integrity, random numbers chosen by the client and
server to identify the connection, and sequence numbers incremented by the client and
server each time a message is sent, to thwart replay attacks.
A4.2.5 SSL Message Exchange:
A. SSL messages are sent using the services of the SSL Record Protocol, which
provides confidentiality and message integrity. SSL prepares the message for
transmission in five steps (Figure 9):
B. The message is fragmented into blocks of manageable size, with maximum
block size of 214 bytes.
C. Compression is optionally applied. The compression must be lossless, and may
not increase the size of the message by more than 1024 bytes. Neither SSL nor
TLS specifies a compression algorithm.
D. A MAC is calculated over the compressed data, using a shared secret key. The
MAC calculation is based on an early version of HMAC [7] and is similar to that
defined for HMAC [8].
E. The compressed message plus the MAC are encrypted using another shared
secret key. Allowed block ciphers include IDEA, RC2-40, DES-40, DES, Triple
DES, Fortezza; allowed stream ciphers are RC4-40 and RC4-128.
F. A header is prepended to the encrypted message to identify the nature (e.g.,
handshake, or application data) and compressed length of the message.
41
Application Data
Step 1
Fragment
Step 2
Compress
Step 3
MAC
Step 4
Encrypt
Step 5
Append
SSL Record
Header
Figure 9. Operation of the SSL Record Protocol (adapted from [42]).
A4.2.6 SSL Session Establishment:
Before any application data can be protected using the SSL Record Protocol, an SSL
session must be set up with the SSL Handshake Protocol. This is a complicated
procedure that involves the authentication of the server to the client (and possibly the
client to the server), negotiation of the encryption and MAC algorithms to be used, and
the generation of secret keys and other security parameters.
In the first stage of session setup, the client sends the server a client_hello message. It
includes a session identifier; a nonce10 (the ClientHello.random) used to prevent replay
attacks and as input to the key generation algorithm; a list of key-generation algorithms
supported by the client; and the client’s preferred list of MAC and encryption algorithms.
Key generation may be based on Diffie-Hellman, but it can also use RSA (to transmit a
secret key generated by the client) or Fortezza. As part of the key generation process,
the client may request a public key certificate from the server. The server responds to
the client_hello message with a server_hello message, in which the server selects from
10
In cryptography, a nonce is an unpredictable number or identifier that is used only once.
42
the cryptographic options presented by the client, thus establishing the algorithms to be
used in the session, and sends the client its own nonce (the ServerHello.random).
In the second stage, the server authenticates itself by sending the client its public key
certificate (if requested). Optionally, it also sends the public Diffie-Hellman parameters
needed for key generation, and it may request the client authenticate itself by providing
a public key certificate.
In the optional third stage, the client responds with its public key certificate (if
requested) and a certificate_verify message to provide explicit verification for the
client’s certificate.
The client and server now use their shared secret based on the RSA or Diffie-Hellman
exchange to generate a pre_master_secret, which is used, along with the
ClientHello.random and ServerHello.random nonces, as input to a complicated hash
algorithm, to generate the master_secret. This, in turn, is reused, as input to the same
algorithm, to generate the various secret keys needed for the session.
Finally, in the fourth stage, the client sends the server the change_cipher_spec
message, and changes the pending state of the session to the current state; the client
then sends the server the finished message, encrypted with the current encryption
algorithm and keys. The server responds with its own change_cipher_spec and
finished messages, completing the handshake.
A5 A Note on Link-Level Security in the Home Network
The VHN Home Network is an internet in which the component networks may use a
wide variety of technologies. In addition to LAN technologies such as Ethernet or IEEE
1394, component networks may include systems that use power line or wireless
transport.
Some of these technologies have inherent security risks. For example, a wireless
system may leak significant signal power beyond the boundary of the home, allowing a
snooper to listen to traffic. Power line systems may also be vulnerable to
eavesdropping or intrusion if the power line itself is accessible outside the house, say
through a tap on the distribution transformer or through an outdoor outlet. In an
apartment building, where living units are closely packed and all use a common power
system, signals on wireless and power line technologies are particularly easy to
intercept.
Vendors of these systems are quite aware of these problems, and some of them have
taken steps to implement link-layer encryption to secure traffic on their systems. For
example, Bluetooth™ provides an elaborate security service at both the application
layer and at the link layer, which uses proprietary authentication and encryption
algorithms, with a key size of 128 bits for authentication, and from 8 to 128 bits for
encryption [44]. Home Plug and Play also provides link layer security that includes
several levels of password protection [42].
While it is clear that there is a need for security services on these vulnerable
technologies, the proliferation of link layer security technologies could become too
43
much of a good thing when they become components of a larger internet. If a signal
passes through three or four links, each of which implements its own authentication and
encryption, throughput may go down and costs may go up.
There is a need to control processor time and cost if the security provided by individual
network technologies is not to be a burden on the integrated home network. It is clear
that a single home network security policy would be preferable to multiple security
mechanisms applied sequentially to a signal as it traverses the home, and there may be
an impetus to coordinate these independent security services as home networks
evolve. In the meantime, the broadband home network will have to live with multiple
link layer security services provided by individual component networks.
44