ICSA Labs IPsec Product Certification Version 2.0

ICSA Labs started accepting IPsec products for testing against Version 2.0 Criteria on January 16th 2006.

ICSA Labs IPsec PRODUCT CERTIFICATION VERSION 2.0 TESTING

ICSA Labs will examine and test submitted products against other VERSION 2.0 Certified IPsec products to verify that they

  • are shipping products available for purchase by the general user community
  • are interoperable with other VERSION 2.0 ICSA Labs certified IPsec products
  • meet the baseline set of requirements for Internet Key Exchange (IKEv2) and IPsec protocols listed herein
  • meet the specified requirements of ICSA Labs cryptography certification criteria listed herein

Products meeting all VERSION 2.0 testing requirements using Pre-Shared Key (PSK) Authentication will be VERSION 2.0 Basic certified and may display the ICSA Labs IPsec 2.0 Basic Certified logo.

 

Products meeting all VERSION 2.0 testing requirements using Digital Certificate (CERT) Authentication AND Pre-Shared Key (PSK) Authentication will be VERSION 2.0 Enhanced certified and may display the ICSA Labs IPsec 2.0 Enhanced Certified logo.

 

 

                      

 

IPsec product users are encouraged to visit the Listing of ICSA Labs Certified IPsec Products to read specifics about the certified products and the criteria against which they were tested.

 

http://www.icsalabs.com/ipsec

 

Requirements Terminology

The key words MAY, MUST, MUST NOT and SHOULD, in this document, are to be interpreted as described in RFC 2119. [RFC2119]

 

NOTE: Only MUST requirements of this document need to be met for certification.

 

IKEv2 Implementation Testing

The IKEv2 protocol is used to securely negotiate and provide mutually authenticated keying material for security associations. [RFC 4306]

ICSA Labs will examine submitted products to verify support for the following IKE Version 2 features: 

 

IKE_SA_INIT and IKE_AUTH Exchanges

  • Products MUST send message types in the following order:
    • IKE_SA_INIT
    • IKE_AUTH
    • CREATE_CHILD_SA & Informational
  • Pre-shared secret key (PSK)  
    • DH Group 2 key exchange MUST be supported.
    • DH Group 14 (2048) SHOULD be used, and if supported will be tested and noted in the lab notes for certified products.
    • Mobile clients do not need to support pre-shared secret authentication.
  • MUST support ECN (Explicit Congestion Notification) in accordance with RFC’s 4306, 4301 and 3168
  • 3DES-CBC: IKE encryption MUST.  
  • AES: IKE encryption. AES 128-CBC MUST be supported for IKE Encryption. RFC3602
  • Vendor ID payload: The product MUST NOT reject a Parent SA negotiation because it has received a Vendor ID payload or an unfamiliar Vendor ID (MUST be ignored)
  • IKE SA lifetimes will be tested configured with both matched and mismatched values. Product MUST support lifetime values as low as 11 minutes.
  • Sending DELETE messages for deleted SA’s MUST be supported.  Upon receipt of a DELETE message, a product MUST delete appropriate Parent and Child SA’s.
  • Liveness Check MUST be supported in accordance with RFC 4306
  • Initial_Contact (IC) status message MUST be used within a protected packet when setting up an IKE SA with a peer for which no tunnels exist. Any non-cryptographically protected IC messages should be disregarded. The receiver of the IC notification message MUST delete any previously existing SA’s it has for the sending system.
  • An implementation MUST NOT send an IC to a peer for which 1 or more SA’s currently exist
     

CREATE_CHILD_SA:

  • Multiple Child SA’s (using dissimilar Cryptographic algorithms) between two IPsec peers MUST be supported.
  • SA’s  to multiple peers simultaneously MUST be supported.
  • Proposal requirement:
    • The following three protocol/transform/attribute combinations MUST be supported:

ESP/AES128-CBC/HMAC-SHA1

ESP/3DES-CBC/HMAC-SHA1

ESP/NULL/HMAC-SHA1

Certified Product Web-posted Lab Reports will reflect support of these criteria elements based upon Security Analyst review and Product Testing Guide (PTG) [Annex 1] documentation.

  • Traffic Selectors

o    Product MUST interoperate with responder that has traffic selectors configured as a subset of the initiators.

o    An Initiator MUST log information (Per Rejected IKE 2.0 Logging Requirements) where there is NOT a match between the Responder’s chosen subset and the IP datagram header information received by the Initiator which triggered the IKE initiation.

  • Perfect Forward Secrecy

o   Products MUST support PFS ON and PFS OFF. 

  • Sending DELETE messages for deleted Child SA’s MUST be supported.  Upon receipt of a DELETE message, a product MUST delete the appropriate Child SA.
  • Child SA lifetimes will be tested configured with both matched and mismatched values. Product MUST support lifetime values as low as 5 minutes.

Products MUST support the following cases:

  • Initiator makes an incorrect initial DH Group guess in the IKE_SA_INIT exchange (Initiator and Responder configured with at least one common DH Group).

  • Responder sends NOTIFY type cookie during IKE_SA_INIT exchange.

  • Acceptance of incoming requests whose source port is something other than 500 or 4500.

Certificate Enrollment and Validation Testing (2.0 Cert Testing) Ref draft-ietf-pki4ipsec-ikecert-profile-07.txt

  • ICSA Labs will examine and test submitted products to verify that the product can accomplish secure certificate enrollment and secure loading to the device or Management Station. Any of the following can be employed:
    • PKCS 10/7 with PKCS 9.14 extension [RFC 2985]
    • SCEP [SCEP]
    • CMP [RFC 2510, RFC 2511]
    • Management Station Controlled
  • Identity: MUST be configurable to send at least one and accept ALL of the following:
      • ID_IPV4_ADDR
      • ID_DER_ASN1_DN
      • ID_FQDN
      • ID_RFC822_ADDR

         
  • The product MUST support CRL requests using LDAPv2 [RFC 2587], LDAPv3 [RFC 2251] or HTTP [RFC 2585]
  • MUST complete IKE SA negotiation with a peer that sends an empty CERTREQ payload.

General Requirements:

  • ICSA Labs will test to verify support for dynamically addressed devices
     

  • send and accept any unicast IP address in SA (no policy decision on address) Exception: A client is not required to accept dynamic addressing from a peer.
     

  • Validate exchanged digital certificates, one root certificate, same Certification Authority
     

  • RSA Signature Mode for Authentication. ICSA Labs will create all certificates with the keyUsage bit set for digitalSignature.
     

  • ICSA Labs will test peer certificate validation

  • accept valid certificate

  • reject expired certificate

  • reject revoked certificate

Encapsulating Security Payload Implementation Testing
The Encapsulating Security Payload (ESP) is used to provide data source authentication, data integrity and confidentiality. RFC 4303

ICSA Labs will examine and test submitted products to verify the following algorithms are implemented properly.

  • ESP Null Mode: Authentication and data integrity only, Confidentiality not required
  • ESP Encrypted Mode: Authentication, data integrity and Confidentiality required
  • MUST NOT allow ESP NULL without Authentication/Data Integrity.
  • ICSA Labs Tests for ESP (NULL and Encrypted modes):
    • ESP MUST be supported in the tunnel mode for end-to-gateway and gateway-to-gateway communications.
    • Tests for Replay Protection:
      • Product MUST accept a late packet with an offset less than or equal to 32 packets
      • Product MUST reject a repeated packet.
      • Fragmentation Handling (unprotected side of IPsec boundary)

-         Products MUST support sending ESP traffic through a network with an intermediate hop with an MTU as low as 576. 

-         Products MUST support re-assembly of fragmented ESP packets

 

Cryptography Implementation Testing  

 

·          Cipher algorithms MUST be used without fatal or security-degrading mistakes.  In addition to the algorithms that must be supported as listed in this criteria document, ICSA Labs will statistically test all cipher algorithms that are supported by the product and recognized on the list of ICSA Labs approved algorithms.

 

·          Initialization Vectors will be examined and tested for appropriate randomness, statistical independence and non-predictability. 

 

·          The use of an HMAC MUST be implemented without errors and the product MUST verify incoming data is correct through HMAC verification.

 

·          The product MUST employ acceptable key management techniques that

include:

o         Generation of random, non-predictable keys

o         Secure distribution of keys - the product MUST NOT send accessible,

unencrypted keys or secrets across a network

o         Secure key storage - the product MUST NOT store unencrypted key(s) or secrets in memory or storage media accessible by processes outside the cryptographic boundary

o         Product MUST destroy keys following their useful lifetime to prevent recovery of keying material as a result of tampering, power failures, etc

 

·          The Vendor MUST complete the Random Number Generation section of the Product Testing Guide (PTG) in its entirety. Information on the following is required:

o         Number, type and algorithm of PRNG/RNG(s) employed in the product

o         The functions that use the random output for each PRNG/RNG(s) employed in the product

o         All machine states used in creating the entropy for the PRNG/RNG and how that data is

conditioned before inputting into the PRNG/RNG

o         Other Independent 3rd-party testing done

o         Input to the PRNG MUST NOT be limited to low quality entropy sources only.

(e.g. System Clock, MAC Addressing, etc…) Ref RFC 4086 and NIST Special Publication 800-90, Recommendation for Random Number Generation Using Deterministic Random Bit Generators

http://csrc.nist.gov/publications/drafts/sp800-90_draft_dec2005.pdf

 

·     Product Management Interfaces MUST have the ability to obscure plaintext PSK characters. This function MUST be enabled by DEFAULT.

 

·          Entry of PSK characters MUST allow for ASCII strings of at least 64 octets.

 

·          During IKE negotiation, a Product MUST only accept cryptographic algorithms that the administrator has configured.

 

If any tests conducted indicate possible problems, ICSA Labs reserves the right to perform supplementary testing which may require additional information from the Vendor as deemed necessary.

 

LOGGING REQUIREMENTS (VERSION 2.0)

An Implementation MUST have the capability to enable logging of rejected IKE messages. The log entries MUST contain the following data as appropriate.

1.        Date/Time

2.        Source and Destination addresses

3.        Cookie pair

4.        Payload responsible for rejection

5.        Reason for Rejection

An Implementation MUST have the capability to enable logging of discarded ESP packets. The log entries MUST contain the following data as appropriate.

1.        Date/Time

2.        SPI value

3.        Source and Destination addresses

4.        Sequence number

5.        Reason for discard 

 

 

Optional Functionality
Interoperability Workshops have underscored the importance of functions designated within the Standard as “Optional”. In order to accurately reflect the functional security of a product undergoing certification testing, a vendor wishing to enroll a product will have the option of selecting specific optional functions to be tested by ICSA Labs. This will be done by completing Section D within the Product Testing Guide.

 

Please Note!
All results of Optional Function testing will be reported in the final Certification Lab Report (PASS OR FAIL)

 

Optional Functions:

 

Configuration Payload

o         MUST support CP types CFG_REQUEST/CFG_REPLY

o         MUST support the request of an internal IP address as appropriate, IRAS or IRAC, in accordance with Sections 2.19 and 3.15 of RFC 4306.

o         IRAC MUST process INTERNAL_ADDRESS_EXPIRY if received and MUST limit the lifetime of the SA or renew the lease before it expires.

o         Requestors MUST ignore returned attributes that are not recognized.

Extensible Authentication

o         MUST support EAP authentication in accordance with RFC 4306 with support for at least one of the following methods

o         EAP MD5-Challenge (RFC 3748)

o         EAP-SIM (draft-haverinen-pppext-eap-sim-16.txt)

o         IRAS MUST support at least one of the following server authentication mechanisms:

o         Local database

o         RADIUS support for EAP (RFC 3579)

o         Shared key MUST be used by the initiator and Responder to only generate AUTH payloads and no other purpose.

IPv6 Support

o         IKE MUST function over IPv6 as it does with IPv4.

o         IPv6 capable implementations MUST be configurable to generate and accept all applicable IPv6 payloads.

NAT Traversal

 

o         MUST support the following scenarios:

o         Tested device is behind NAT/NAPT device

o         Peer is behind NAT/NAPT device

o         Both are behind NAT/NAPT device

o         SGW MUST support multiple clients, each behind a separate NAT/NAPT device, with the same IP address.

o         Proper port usage MUST be followed. IKE Packets MUST be accepted from any port and responses sent to the port from which it came.

o         MUST support NAT Traversal negotiation in accordance with RFC 4306

o         MUST support UDP encapsulation of ESP packets and NAT-keepalives in accordance with RFC 3948

 

ESN

o         Support for Extended Sequence Numbering (ESN) MUST be done in accordance with RFC 4306 and RFC 4303.

 

TFC

o         Support for Traffic Flow Confidentiality (TFC) MUST be done in accordance with with RFC 4306 and RFC 4303.

 

References:
(note: The RFCs are in http://info.internet.isi.edu/in-notes/rfc/files/rfcXXXX.txt, or http://www.ietf.org/rfc/rfcXXXX.txt, where the RFC number replaces the XXXX.)

[FIPS 46-3] Federal Information Processing Standard Publication 46-3, October 25, 1999

[Certified Products] List of Certified Products [PTG] Product Testing Guide, ANNEX 1 to the ICSA Labs PROGRAM FOR IPsec PRODUCT CERTIFICATION, downloadable in PDF.

[RFC 2119] S. Bradner, "Key Words for use in RFCs to Indicate Requirement Levels," March 1997

[RFC 2403] C. Madson and R. Glenn, "The Use of HMAC-MD5-96 within ESP and AH," November 1998

[RFC 2404] C. Madson and R. Glenn, "The Use of HMAC-SHA-1-96 within ESP and AH," November 1998

 [RFC 2410] R. Glenn and S. Kent, "The NULL Encryption Algorithm and Its Use With IPsec," November 1998

[RFC 2451] R. Pereira, R. Adams, "The ESP CBC-Mode Cipher Algorithms," November 1998

[RFC3602] S. Frankel,R. Glenn,S. Kelly, “The AES-CBC Cipher Algorithm and Its Use with IPsec”, September 2003

[RFC 4086] J. Schiller, S. Crocker, “Randomness Requirements for Security” June 2005

[RFC 4301] S. Kent, K. Seo, “Security Architecture for the Internet Protocol” December 2005

[RFC 4303] S. Kent, “IP Encapsulating Security Payload (ESP)” December 2005

[RFC 4304] S. Kent, “Extended Sequence Number (ESN) Addendum to IPsec Domain of Interpretation (DOI)

                   for Internet Security Association and Key Management Protocol (ISAKMP)” December 2005

[RFC 4305] D. Eastlake 3rd, “Cryptographic Algorithm Implementation Requirements for Encapsulating Security
        Payload (ESP) and Authentication Header (AH)”, December 2005

[RFC 4306] C. Kaufman, Ed., “Internet Key Exchange (IKEv2) Protocol”, December 2005

 

As a standard practice, ICSA Labs does not base criteria elements on draft documents unless dictated by Industry user requirements and reserves the right to update criteria information as it evolves and standards dictate.

(draft-haverinen-pppext-eap-sim-16.txt)
(draft-ietf-pki4ipsec-ikecert-profile-07.txt)

Draft Special Publication 800-90, Recommendation for Random Number Generation Using Deterministic Random Bit Generators – http://csrc.nist.gov/publications/drafts/sp800-90_draft_dec2005.pdf

                 

 

Updated:January , 2006