1、 CEA Standard Security Services for the Versatile Home Network CEA-851.2-A March 2011 NOTICE Consumer Electronics Association (CEA) Standards, Bulletins and other technical publications are designed to serve the public interest through eliminating misunderstandings between manufacturers and purchase
2、rs, facilitating interchangeability and improvement of products, and assisting the purchaser in selecting and obtaining with minimum delay the proper product for his particular need. Existence of such Standards, Bulletins and other technical publications shall not in any respect preclude any member
3、or nonmember of CEA from manufacturing or selling products not conforming to such Standards, Bulletins or other technical publications, nor shall the existence of such Standards, Bulletins and other technical publications preclude their voluntary use by those other than CEA members, whether the stan
4、dard is to be used either domestically or internationally. Standards, Bulletins and other technical publications are adopted by CEA in accordance with the American National Standards Institute (ANSI) patent policy. By such action, CEA does not assume any liability to any patent owner, nor does it as
5、sume any obligation whatever to parties adopting the Standard, Bulletin or other technical publication. This CEA Standard is considered to have International Standardization implication, but the International Electrotechnical Commission activity has not progressed to the point where a valid comparis
6、on between the CEA Standard and the IEC document can be made. This Standard does not purport to address all safety problems associated with its use or all applicable regulatory requirements. It is the responsibility of the user of this Standard to establish appropriate safety and health practices an
7、d to determine the applicability of regulatory limitations before its use. This document is copyrighted by the Consumer Electronics Association (CEA) and may not be reproduced, in whole or part, without written permission. Federal copyright law prohibits unauthorized reproduction of this document by
8、 any means. Organizations may obtain permission to reproduce a limited number of copies by entering into a license agreement with IHS (http:/). .Requests to reproduce text, data, charts, figures or other material should be made to the CEA. (Formulated under the cognizance of the CEAs R7 Home Network
9、 Committee.) Published by CONSUMER ELECTRONICS ASSOCIATION 2011 Technology furthermore, it uses web tools, such as HTTP, for device control. (Note that, while the CEA-851 also defines a network architecture and requires a backbone topology based on IEEE 1394b, the security services specified in this
10、 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.) This document specifies security services to defend against
11、threats coming from the outside the home into to the home. Security issues stemming from threats originating on devices within the home, or directed from devices within the home to an outside network, will be addressed in a future issue of this standard. 1Indeed, one of the persistent problems for m
12、anagers of enterprise security systems is the tendency of employees to use simplistic passwords; favorites are the users own name, the users street name, or a common dictionary word. CEA-851.2-A 72.2 Normative References The following standards contain provisions that, through reference in this text
13、, constitute normative provisions of this standard. At the time of publication, the editions indicated 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 standar
14、ds listed in Section 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. Ramsdell, B., Ed., Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.1 Certificate Handling, RFC 3850, Internet Engineering Task Force,
15、 July 2004. 2. Ramsdell, B., Ed., Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.1 Message Specification, RFC 3851, Internet Engineering Task Force, July 2004. 3. Schaad, J., Enhanced Security Services (EES) Update: Adding CertID Algorithm Agility, RFC 5035, Internet Engineering Tas
16、k Force, August 2007. 4. 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, http:/ 5. Kent, S., K. Seo, Security Architecture for the I
17、nternet Protocol, RFC 4301, Internet Engineering Task Force, December 2005. 6. Housley, R., W. Ford, W. Polk, and D. Solo, Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile, RFC 3280, Internet Engineering Task Force, April 2002. 7. Rivest, R., The MD5
18、 Message-Digest Algorithm, RFC 1321, Internet Engineering Task Force, April 1992 8. Secure Hash Standard, FIPS PUB 180-1, National Institute of Standards and Technology, April 17, 1995. 9. Advanced Encryption Standard (AES), Federal Information Processing Standards Publication 197, November 26, 2001
19、. 10. Brown, M., R. Housley, The Transport Layer Security (TLS) Authorization Extensions, RFC 5878, Internet Engineering Task Force, May 2010. 11. Karn, P., P. Metzger, and W. Simpson, The ESP Triple DES Transform, RFC 1851, Internet Engineering Task Force, September 1995. 12. Nottingham, M., E. Ham
20、mer-Lahav, Defining Well-Known Uniform Resource Identifiers (URIs), RFC 5785, Internet Engineering Task Force, April 2010. 13. Freed, N., Behavior of and Requirements for the Internet Firewalls, RFC 2979, Internet Engineering Task Force, October 2000. CEA-851.2-A 814. Baker, F., and P. Savola, Ingre
21、ss Filtering for Multihomed Networks, RFC 3704, Internet Engineering Task Force, March 2004 2.2.2 Normative Reference Acquisition IETF www.ietf.org AES http:/csrc.nist.gov/publications/fips/fips197/fips-197.pdf NIST www.nist.gov 2.3 Informative References The following documents contain information
22、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 Reference List 15. Dusse, S., P. Hoffman, B. Ramsdell, L. Lundblad, and L. Repka, S/MIME Version 2 Message Speci
23、fication, RFC 2311, Internet Engineering Task Force, March 1998. 16. Dusse, S., P. Hoffman, B. Ramsdell, and J. Weinstein, S/MIME Version 2 Certificate Handling, RFC 2312, Internet Engineering Task Force, March 1998. 17. Kaliski, B, and J. Jonsson, Public-Key Cryptography Standards (PKCS) #1: RSA Cr
24、yptography Specifications Version 2.1, RFC 3447, Internet Engineering Task Force, February 2003. 18. Cheng, P., and R. Glenn, Test Cases for HMAC-MD5 and HMAC-SHA-1, RFC 2202, Internet Engineering Task Force, September 1997. 19. Madson, C., and R. Glenn, The Use of HMAC-MD5-96 within ESP and AH, RFC
25、 2403, Internet Engineering Task Force, November 1998. 20. Madson, C. and R. Glenn, The Use of HMAC-SHA-1-96 within ESP and AH, RFC 2404, Internet Engineering Task Force, November 1998. 21. Madson, C., and N. Doraswamy, The ESP DES-CBC Cipher Algorithm With Explicit IV, RFC 2405, Internet Engineerin
26、g Task Force, November 1998. 22. Kent, S., IP Encapsulating Security Payload (ESP), RFC 4303, Internet Engineering Task Force, December 2005. CEA-851.2-A 923. Kaufman, C., Ed., Internet Key Exchange (IKEv2) Protocol, RFC 4306, Internet Engineering Task Force, December 2005. 24. Glenn, R., and S. Ken
27、t, The NULL Encryption Algorithm and its Use With IPsec, RFC 2410, Internet Engineering Task Force, November 1998. 25. Pereira, R., and R. Adams, The ESP CBC-Mode Cipher Algorithms, RFC 2451, Internet Engineering Task Force, November 1998. 26. Kent, S., IP Authentication Header, RFC 4302, Internet E
28、ngineering Task Force, December 2005. 27. Thayer, R., N. Doraswamy, and R. Glenn, IP Security Document Roadmap, RFC 2411, Internet Engineering Task Force, November 1998. 28. Orman, H., The OAKLEY Key Determination Protocol, RFC 2412, Internet Engineering Task Force, November 1998. 29. Case, J., R. M
29、undy, D. Partain, and B. Stewart, Introduction and Applicability Statements for Internet-Standard Management Framework, RFC 3410, Internet Engineering Task Force, December 2002. 30. Wijnen, B., D. Harrington, and R. Presuhn, An Architecture for Describing Simple Network Management Protocol (SNMP) Ma
30、nagement Frameworks, RFC 3411, Internet Engineering Task Force, December 2002. 31. Case, J., D. Harrington, R. Presuhn, and B. Wijnen, Message Processing and Dispatching for the Simple Network Management Protocol (SNMP), RFC 3412, Internet Engineering Task Force, December 2002. 32. Levi, D., P. Meye
31、r, and B. Stewart, Simple Network Management Protocol (SNMP) Applications, RFC 3413, Internet Engineering Task Force, December 2002. 33. Blumenthal, U., and B. Wijnen, User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3), RFC 3414, Internet Engineering Tas
32、k Force, December 2002. 34. Wijnen, B., R. Presuhn, and K. McCloghrie, View-based Access Control Model (VACM) for the Simple Network Management Protocol (SNMP), RFC 3415, Internet Engineering Task Force, December 2002. 35. Frye, R., D. Levi, S. Routhier, and B. Wijnen, Coexistence between Version 1,
33、 Version 2, and Version 3 of the Internet-standard Network Management Framework, RFC 3584, Internet Engineering Task Force, August 2003. 36. Zeilenga, K., Lightweight Directory Access Protocol version 2 (LDAPv2), RFC 3494, Internet Engineering Task Force, March 2003. 37. Hodges, J., R. Morgan, Light
34、weight Directory Access Protocol (v3), RFC 3377, Internet Engineering Task Force, September 2002. 38. Rescorla, E., Diffie-Hellman Key Agreement Method, RFC 2631, Internet Engineering Task Force, June 1999. CEA-851.2-A 1039. Dierks, T., and E. Rescorla, The Transport Layer Security (TLS) Protocol Ve
35、rsion 1.1, RFC 4346, Internet Engineering Task Force, April 2006. 40. Medvinsky, A., and M. Hur, Addition of Kerberos Cipher Suites to Transport Layer Security (TLS), RFC 2712, Internet Engineering Task Force, October 1999. 41. Khare, R., and S. Lawrence, Upgrading to TLS within HTTP/1.1, RFC 2817,
36、Internet Engineering Task Force, May 2000. 42. Hodges, J., R. Morgan, Lightweight Directory Access Protocol (v3), RFC 3377, Internet Engineering Task Force, September 2002. 43. Stallings, William, “Cryptography and Network Security: Principles and Practice,” Second Edition, Prentice Hall, 1999. 44.
37、Neuman, C., T. Yu, S. Hartman, and K. Raeburn, The Kerberos Network Authentication Service (V5), RFC 4120, Internet Engineering Task Force, July 2005. 45. Krawczyk, H., M. Bellare, and R. Canetti, HMAC: Keyed-Hashing for Message Authentication, RFC 2104, Internet Engineering Task Force, February 199
38、7. 46. Oehler, M., and R. Glenn, HMAC-MD5 IP Authentication with Replay Prevention, RFC 2085, Internet Engineering Task Force, February 1997. 47. Bluetooth, 2.3.2 Informative Reference Acquisition Bluetooth HAVi www.havi.org IETF www.ietf.org UPnP www.upnp.org 2.4 Symbols and Abbreviations AES Adv
39、anced Encryption Standard AH Authentication Header CAST Carlisle Adams Use S/MIME or PGP No Defense; Use S/MIME or PGP None CEA-851.2-A 14denial of service attacks2. IPSec and SSL/TLS do not explicitly provide protection to software; however, the authentication and integrity services at least ensure
40、 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 versi
41、on 3.1 protocol (RFCs 3850, 3851, and 5035) 1, 2, 3 and should be backward compatible with the S/MIME version 2.1 protocol (RFCs 2311, 2312, and 3447) 15, 16, 17. These services (IPSec and SSL/TLS) cannot provide complete security. Not all traffic to the home will be on IP (e.g., streaming MPEG-2 vi
42、deo), 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
43、 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 an
44、d 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 usu
45、ally 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 t
46、he proxy devices 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, o
47、r 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 4. We examine each of these configurations, for IPSec and for SSL/TLS, in the following sections. 2The current
48、ly 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
49、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. CEA-851.2-A 153.1.1 IPSec Configurations IPSec 11, 18, 5, 19, 20, 21, 22, 23, 24, 25, 26, 27, and 28 provides authentication or encryption for any IP packets that meet the SA selector criteria in the SPD (see Section A1.3.1). When security is applied betwee
