NIAP: View Technical Decision Details
NIAP/CCEVS
  NIAP  »»  Protection Profiles  »»  Technical Decisions  »»  View Details  
Archived TD0439:  EAP-TLS Revocation Checking

Publication Date
2019.08.29

Protection Profiles
PP_WLAN_CLI_EP_V1.0

Other References
FIA_X509_EXT.1, FAU_GEN.1

Issue Description

It is not clear if revocation checking is required for EAP-TLS connections. Also, for TOEs that connect to access points using EAP-TLS implemented in a WLAN client, it is not possible for the TOE to have access to a revocation server to check the EAP-TLS server certificate duting the initial connection.

Resolution

Updated 09/05/2019 to update Table 2: Auditable Events

 

FAU_GEN.1/WLAN is modified as follows:

FIA_X509_EXT.1/WLAN is added to Table 2: Auditable Events:

Requirement        Auditable Events                Additional Audit Record Contents
FIA_X509_EXT.1/WLAN     Failure to validate X.509v3 certificate.     Reason for failure of validation.

 

The following iteration of FIA_X509_EXT.1 is added to the WLAN Client EP v1.0.

FIA_X509_EXT.1/WLAN X.509 Certificate Validation

FIA_X509_EXT.1.1/WLAN The TSF shall validate certificates for EAP-TLS in accordance with the following rules:

  • RFC 5280 certificate validation and certificate path validation
  • The certificate path must terminate with a certificate in the Trust Anchor Database
  • The TSF shall validate a certificate path by ensuring the presence of the basicConstraints extension and that the CA flag is set to TRUE for all CA certificates
  • The TSF shall validate the extendedKeyUsage field according to the following rules:
    • Server certificates presented for TLS shall have the Server Authentication purpose (id-kp 1 with OID 1.3.6.1.5.5.7.3.1) in the extendedKeyUsage field
    • Client certificates presented for TLS shall have the Client Authentication purpose (id-kp 2 with OID 1.3.6.1.5.5.7.3.2) in the extendedKeyUsage field.

 

FIA_X509_EXT.1.2/WLAN The TSF shall only treat a certificate as a CA certificate if the basicConstraints extension is present and the CA flag is set to TRUE.

 

Application Note: FIA_X509_EXT.1/WLAN lists the rules for validating certificates for EAP-TLS. In contrast to FIA_X509_EXT.1 in the Base-PP, this iteration does not require revocation checking for the EAP-TLS connection used to establish a WiFi connection. The FIA_X509_EXT.1 requirements defined in each of the possible base PPs define requirements that the underlying platform is expected to implement in order to support compliance with RFC 5280.

 

Assurance Activity

 

TSS

The evaluator shall ensure the TSS describes where the check of validity of the EAP-TLS certificates takes place. The evaluator ensures the TSS also provides a description of the certificate path validation algorithm.

 

Tests

The tests described must be performed in conjunction with the other Certificate Services assurance activities. The tests for the extendedKeyUsage rules are performed in conjunction with the uses that require those rules. The evaluator shall create a chain of at least four certificates: the node certificate to be tested, two Intermediate CAs, and the self-signed Root CA.

  • Test 1: The evaluator shall then load a certificate or certificates to the Trust Anchor Database needed to validate the certificate to be used in the function (e.g. application validation), and demonstrate that the function succeeds. The evaluator then shall delete one of the certificates, and show that the function fails.
  • Test 2: The evaluator shall demonstrate that validating an expired certificate results in the function failing.
  • Test 3: The evaluator shall construct a certificate path, such that the certificate of the CA issuing the TOE’s certificate does not contain the basicConstraints extension. The validation of the certificate path fails.
  • Test 4: The evaluator shall construct a certificate path, such that the certificate of the CA issuing the TOE’s certificate has the cA flag in the basicConstraints extension not set. The validation of the certificate path fails.
  • Test 5: The evaluator shall modify any byte in the first eight bytes of the certificate and demonstrate that the certificate fails to validate (the certificate will fail to parse correctly).
  • Test 6: The evaluator shall modify any bit in the last byte of the signature algorithm of the certificate and demonstrate that the certificate fails to validate (the signature on the certificate will not validate).
  • Test 7: The evaluator shall modify any byte in the public key of the certificate and demonstrate that the certificate fails to validate (the signature on the certificate will not validate).
Justification

See issue description. It is likely that revocation checking will be required in future versions of WLAN Client EP and the TC is investigating the feasibility of alternative mechanisms.

 
 
Site Map              Contact Us              Home