ETSI TS 102 558-2006 Methods for Testing and Specification (MTS) Internet Protocol Testing (IPT) IPv6 Security Requirements Catalogue《测试方法和规范(MTS) 互联网协议测试(IPT) IPv6安全 要求目录(版本1 1 1).pdf

《ETSI TS 102 558-2006 Methods for Testing and Specification (MTS) Internet Protocol Testing (IPT) IPv6 Security Requirements Catalogue《测试方法和规范(MTS) 互联网协议测试(IPT) IPv6安全 要求目录(版本1 1 1).pdf》由会员分享，可在线阅读，更多相关《ETSI TS 102 558-2006 Methods for Testing and Specification (MTS) Internet Protocol Testing (IPT) IPv6 Security Requirements Catalogue《测试方法和规范(MTS) 互联网协议测试(IPT) IPv6安全 要求目录(版本1 1 1).pdf（477页珍藏版）》请在麦多课文档分享上搜索。

1、 ETSI TS 102 558 V1.1.1 (2006-12)Technical Specification Methods for Testing and Specification (MTS);Internet Protocol Testing (IPT);IPv6 Security;Requirements CatalogueETSI ETSI TS 102 558 V1.1.1 (2006-12) 2 Reference DTS/MTS-IPT-008-IPV6-SecReq Keywords IP, IPv6, security, testing ETSI 650 Route d

2、es Lucioles F-06921 Sophia Antipolis Cedex - FRANCE Tel.: +33 4 92 94 42 00 Fax: +33 4 93 65 47 16 Siret N 348 623 562 00017 - NAF 742 C Association but non lucratif enregistre la Sous-Prfecture de Grasse (06) N 7803/88 Important notice Individual copies of the present document can be downloaded fro

3、m: http:/www.etsi.org The present document may be made available in more than one electronic version or in print. In any case of existing or perceived difference in contents between such versions, the reference version is the Portable Document Format (PDF). In case of dispute, the reference shall be

4、 the printing on ETSI printers of the PDF version kept on a specific network drive within ETSI Secretariat. Users of the present document should be aware that the document may be subject to revision or change of status. Information on the current status of this and other ETSI documents is available

5、at http:/portal.etsi.org/tb/status/status.asp If you find errors in the present document, please send your comment to one of the following services: http:/portal.etsi.org/chaircor/ETSI_support.asp Copyright Notification No part may be reproduced except as authorized by written permission. The copyri

6、ght and the foregoing restriction extend to reproduction in all media. European Telecommunications Standards Institute 2006. All rights reserved. DECTTM, PLUGTESTSTM and UMTSTM are Trade Marks of ETSI registered for the benefit of its Members. TIPHONTMand the TIPHON logo are Trade Marks currently be

7、ing registered by ETSI for the benefit of its Members. 3GPPTM is a Trade Mark of ETSI registered for the benefit of its Members and of the 3GPP Organizational Partners. ETSI ETSI TS 102 558 V1.1.1 (2006-12) 3 Contents Intellectual Property Rights4 Foreword.4 1 Scope 5 2 References 5 3 Abbreviations

8、.6 4 Requirements Catalogue.6 4.1 Requirements extracted from RFC 43017 4.2 Requirements extracted from RFC 43029 4.3 Requirements extracted from RFC 430342 4.4 Requirements extracted from RFC 430587 4.5 Requirements extracted from RFC 430698 4.6 Requirements extracted from RFC 2405476 History 477 E

9、TSI ETSI TS 102 558 V1.1.1 (2006-12) 4 Intellectual Property Rights IPRs essential or potentially essential to the present document may have been declared to ETSI. The information pertaining to these essential IPRs, if any, is publicly available for ETSI members and non-members, and can be found in

10、ETSI SR 000 314: “Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to ETSI in respect of ETSI standards“, which is available from the ETSI Secretariat. Latest updates are available on the ETSI Web server (http:/webapp.etsi.org/IPR/home.asp). Pursuant to the ETS

11、I IPR Policy, no investigation, including IPR searches, has been carried out by ETSI. No guarantee can be given as to the existence of other IPRs not referenced in ETSI SR 000 314 (or the updates on the ETSI Web server) which are, or may be, or may become, essential to the present document. Foreword

12、 This Technical Specification (TS) has been produced by ETSI Technical Committee Methods for Testing and Specification (MTS). ETSI ETSI TS 102 558 V1.1.1 (2006-12) 5 1 Scope The present document is a catalogue of all of the security-related IPv6 requirements extracted from the following IETF specifi

13、cations: RFC 4301 1: “Security Architecture for the Internet Protocol“. RFC 4302 2: “IP Authentication Header“. RFC 4303 3: “IP Encapsulating Security Payload (ESP)“. RFC 4305 4: “Cryptographic Algorithm Implementation Requirements for Encapsulating Security Payload (ESP) and Authentication Header (

14、AH)“. RFC 4306 5 “Internet Key Exchange (IKEv2) Protocol“. RFC 2405 6: “The ESP DES-CBC Cipher Algorithm With Explicit IV“. 2 References The following documents contain provisions which, through reference in this text, constitute provisions of the present document. References are either specific (id

15、entified by date of publication and/or edition number or version number) or non-specific. For a specific reference, subsequent revisions do not apply. For a non-specific reference, the latest version applies. Referenced documents which are not found to be publicly available in the expected location

16、might be found at http:/docbox.etsi.org/Reference. NOTE: While any hyperlinks included in this clause were valid at the time of publication ETSI cannot guarantee their long term validity. 1 IETF RFC 4301: “Security Architecture for the Internet Protocol“. 2 IETF RFC 4302: “IP Authentication Header“.

17、 3 IETF RFC 4303: “IP Encapsulating Security Payload (ESP)“. 4 IETF RFC 4305: “Cryptographic Algorithm Implementation Requirements for Encapsulating Security Payload (ESP) and Authentication Header (AH)“. 5 IETF RFC 4306 “Internet Key Exchange (IKEv2) Protocol“. 6 IETF RFC 2405: “The ESP DES-CBC Cip

18、her Algorithm With Explicit IV“. ETSI ETSI TS 102 558 V1.1.1 (2006-12) 6 3 Abbreviations For the purposes of the present document, the following abbreviations apply: AH Authentication Header CBC Cipher Block Chaining DES Data Encryption StandardDHCP Dynamic Host Configuration Protocol EAP Extensible

19、 Authentication Procedure ESN Extended Sequence Number ESP Encapsulated Security Payload IANA Internet Assigned Number Association ICMP Internet Control Message Protocol ICV Integrity Check Value IETF Internet Engineering Task Force IKEv2 Internet Key Exchange protocol version 2 IP Internet Protocol

20、 IPv4 Internet Protocol version 4 IPv6 Internet Protocol version 6 IV Initialization Vector MAC Message Authentication Code PMTU Path Maximum Transmission Unit RFC Request For Comments NOTE: IETF terminology for a draft standard. SA Security Association SAD Security Association Database SPD Security

21、 Policies Database SPI Security Parameters Index TCP Transport Control Protocol UDP User Datagram Protocol 4 Requirements Catalogue The security requirements related to Internet Protocol version 6 (IPv6) are specified in a number of IETF documents. These documents include requirements for the overal

22、l IPv6 security architecture 1, the use of the IP Authentication Header (AH) 2, IP Encapsulating Security Payload (ESP) 3, the use of cryptographic algorithms 4, 6 and the Internet Key Exchange (IKEv2) 5. The present document is a catalogue of all of the normative requirements from these security sp

23、ecifications. Each requirement is given a unique identifier (for example, RQ_002_1234) and the following information is included with each: the clause number in the RFC from which the requirement has been extracted; the type of requirement (Mandatory, Optional or Recommended); the type of device to

24、which the requirement applies (for example, Host or Router); the actual text from which the requirement was extracted. ETSI ETSI TS 102 558 V1.1.1 (2006-12) 7 4.1 Requirements extracted from RFC 4301 - Identifier: RQ_002_1004 RFC Clause: 3.2 Type: Mandatory Applies to: IPsec host Requirement: IPsec

25、implementations MUST support ESP RFC Text: IPsec implementations MUST support ESP and MAY support AH. - Identifier: RQ_002_1005 RFC Clause: 3.2 Type: Optional Applies to: IPsec host Requirement: IPsec implementations MAY support AH. RFC Text: IPsec implementations MUST support ESP and MAY support AH

26、. - Identifier: RQ_002_1010 RFC Clause: 3.2 Type: Mandatory Applies to: IPsec host Requirement: Manual distribution of keys MUST be supported RFC Text: Because most of the security services provided by IPsec require the use of cryptographic keys, IPsec relies on a separate set of mechanisms for putt

27、ing these keys in place. This document requires support for both manual and automated distribution of keys. It specifies a specific public-key based approach (IKEv2 Kau05) for automated key management, but other automated key distribution techniques MAY be used. - Identifier: RQ_002_1011 RFC Clause:

28、 3.2 Type: Mandatory Applies to: IPsec host Requirement: Automatic distribution of keys MUST be supported RFC Text: Because most of the security services provided by IPsec require the use of cryptographic keys, IPsec relies on a separate set of mechanisms for putting these keys in place. This docume

29、nt requires support for both manual and automated distribution of keys. It specifies a specific public-key based approach (IKEv2 Kau05) for automated key management, but other automated key distribution techniques MAY be used. - ETSI ETSI TS 102 558 V1.1.1 (2006-12) 8 Identifier: RQ_002_1014 RFC Cla

30、use: 4.1 Type: Mandatory Applies to: IPsec host Requirement: A Security Association MUST apply to exactly one of ESP or AH RFC Text: An SA is a simplex “connection“ that affords security services to the traffic carried by it. Security services are afforded to an SA by the use of AH, or ESP, but not

31、both. If both AH and ESP protection are applied to a traffic stream, then two SAs must be created and coordinated to effect protection through iterated application of the security protocols. To secure typical, bi-directional communication between two IPsec-enabled systems, a pair of SAs (one in each

32、 direction) is required. IKE explicitly creates SA pairs in recognition of this common usage requirement. - Identifier: RQ_002_1020 RFC Clause: 4.1 Type: Mandatory Applies to: IPsec host Requirement: A host implementation of IPsec MUST support transport mode RFC Text: In summary, a) A host implement

33、ation of IPsec MUST support both transport and tunnel mode. This is true for native, BITS, and BITW implementations for hosts. b) A security gateway MUST support tunnel mode and MAY support transport mode. If it supports transport mode, that should be used only when the security gateway is acting as

34、 a host, e.g., for network management, or to provide security between two intermediate systems along a path. - Identifier: RQ_002_1021 RFC Clause: 4.1 Type: Mandatory Applies to: IPsec host Requirement: A host implementation of IPsec MUST support tunnel mode RFC Text: In summary, a) A host implement

35、ation of IPsec MUST support both transport and tunnel mode. This is true for native, BITS, and BITW implementations for hosts. b) A security gateway MUST support tunnel mode and MAY support transport mode. If it supports transport mode, that should be used only when the security gateway is acting as

36、 a host, e.g., for network management, or to provide security between two intermediate systems along a path. - ETSI ETSI TS 102 558 V1.1.1 (2006-12) 9 Identifier: RQ_002_1022 RFC Clause: 4.1 Type: Mandatory Applies to: IPsec gateway Requirement: A gateway implementation of IPsec MUST support tunnel

37、mode RFC Text: In summary, a) A host implementation of IPsec MUST support both transport and tunnel mode. This is true for native, BITS, and BITW implementations for hosts. b) A security gateway MUST support tunnel mode and MAY support transport mode. If it supports transport mode, that should be us

38、ed only when the security gateway is acting as a host, e.g., for network management, or to provide security between two intermediate systems along a path. - Identifier: RQ_002_1023 RFC Clause: 4.1 Type: Optional Applies to: IPsec gateway Requirement: A gateway implementation of IPsec MAY support tra

39、nsport mode RFC Text: In summary, a) A host implementation of IPsec MUST support both transport and tunnel mode. This is true for native, BITS, and BITW implementations for hosts. b) A security gateway MUST support tunnel mode and MAY support transport mode. If it supports transport mode, that shoul

40、d be used only when the security gateway is acting as a host, e.g., for network management, or to provide security between two intermediate systems along a path. 4.2 Requirements extracted from RFC 4302 - Identifier: RQ_002_2000 RFC Clause: 2 Type: Mandatory Applies to: IPsec host Requirement: When

41、an IPsec Host sends an IP packet containing an Authentication Header (AH), it MUST set the appropriate Next Header field (either in the IPv6 Header or in the previous Extension Header) to the value fifty-one (51) RFC Text: The protocol header (IPv4, IPv6, or IPv6 Extension) immediately preceding the

42、 AH header SHALL contain the value 51 in its Protocol (IPv4) or Next Header (IPv6, Extension) fields DH98. Figure 1 illustrates the format for AH. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Next Header |

43、 Payload Len | RESERVED | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Security Parameters Index (SPI) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence Number Field | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Integrit

44、y Check Value-ICV (variable) | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ETSI ETSI TS 102 558 V1.1.1 (2006-12) 10Figure 1. AH Format - Identifier: RQ_002_2001 RFC Clause: 2 Type: Mandatory Applies to: IPsec host Requirement: When an IPsec Host sends an IP packet containin

45、g an Authentication Header (AH), it MUST construct the Authentication Header in the following format: Octet Field - 1 Next Header 2 Payload Length 3 a reserved SPI value will not normally be assigned by IANA unless the use of the assigned SPI value is specified in an RFC. The SPI value of zero (0) i

46、s reserved for local, implementation-specific use and MUST NOT be sent on the wire. (For example, a key management implementation might use the zero SPI value to mean “No Security Association Exists“ during the period when the IPsec implementation has requested that its key management entity establi

47、sh a new SA, but the SA has not yet been established.) - ETSI ETSI TS 102 558 V1.1.1 (2006-12) 15Identifier: RQ_002_2012 RFC Clause: 2.5 Type: Mandatory Applies to: IPsec host Requirement: When an IPsec Host sends an IP packet containing an Authentication Header (AH) on a unicast or single-sender mu

48、lticast Security Association (SA), it MUST set the value in the Sequence Number field to one more than the value set in the same field of the previous packet sent to the same SA RFC Text: This unsigned 32-bit field contains a counter value that increases by one for each packet sent, i.e., a per-SA packet sequence number. For a unicast SA or a single-sender multicast SA, the sender MUST increment this field for e