Upcoming SlideShare
Loading in...5







Total Views
Views on SlideShare
Embed Views



0 Embeds 0

No embeds



Upload Details

Uploaded via as Microsoft Word

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
Post Comment
Edit your comment

SC25_WG1_N1137.doc.doc SC25_WG1_N1137.doc.doc Document Transcript

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