6 Appendix A: Product Behavior

The information in this specification is applicable to the following Microsoft products or supplemental software. References to product versions include updates to those products.

• Windows Vista operating system

• Windows Server 2008 operating system

• Windows 7 operating system

• Windows Server 2008 R2 operating system

• Windows 8 operating system

• Windows Server 2012 operating system

• Windows 8.1 operating system

• Windows Server 2012 R2 operating system

Exceptions, if any, are noted in this section. If an update version, service pack or Knowledge Base (KB) number appears with a product name, the behavior changed in that update. The new behavior also applies to subsequent updates unless otherwise specified. If a product edition appears with the product version, behavior is different in that product edition.

Unless otherwise specified, any statement of optional behavior in this specification that is prescribed using the terms "SHOULD" or "SHOULD NOT" implies product behavior in accordance with the SHOULD or SHOULD NOT prescription. Unless otherwise specified, the term "MAY" implies that the product does not follow the prescription.

<1> Section 1.5: The Windows implementation of the HCEA depends on the administrator to configure the URLs of the HRAs. The administrator usually configures this manually or by using Group Policy (as defined in [MS-GPNAP]); in both cases, the HRA URL can be any HTTP URL compliant with [RFC2616] section 3.2.2 or HTTPS URL as specified by [RFC2818] section 2.4. As an alternative, the administrator can configure "HRA Automatic Discovery" as specified in [MSFT-HRA].

<2> Section 1.5: The Windows implementation of HCEA supports the RSA algorithm with a minimum key length of 1,024 bits. Key lengths longer than 2,048 bits are supported if the supporting cryptographic service providers (CSPs) are added to the system. For more information about the default list of CSPs that are present in a Windows-based system, see [MSDN-CSP].

<3> Section 1.5: The Windows implementations of the HCEA and the HRA depend on the Cryptographic Application Programming Interface (CAPI) (for more information, see [MSDN-CAPI]) for the implementation of the algorithms previously specified. The CAPI has a pluggable model for cryptographic service providers (CSPs) to be added, removed, or replaced by the administrator. Hence the HCEA and the HRA support all the algorithms that are provided by CAPI through the pluggable CSPs. For more information about the default list of CSPs that are present on a Windows-based system, see [MSDN-CSP].

<4> Section 1.5: Windows implementations of the HCEA and the HRA use the OID "1.3.6.1.4.1.311.47.1.1" (napHealthyOid) (as specified in section 1.9) for the Statement of Health field (as specified in section 2.2.1.4), the OID "1.3.6.1.4.1.311.47.1.3" (napUnhealthyOid) (as specified in section 2.2.2.4), and the OID "1.3.6.1.4.1.311.13.2.2" (szOID_ENROLLMENT_CSP_PROVIDER) (as specified in section 2.2.1.4).

<5> Section 1.6: The Windows HCEA depends on general platform security. Strong security is possible by using a secure execution environment.

<6> Section 2.2.1.1: The Windows implementation of the HCEA specifies the value of the User-Agent field as "NAP IPSec Enforcement v1.0".

<7> Section 2.2.1.1: The Windows implementation of the HRA ignores the user-agent field by default, but can be configured to accept HCEP requests containing only one of a predefined set of user agents.

<8> Section 2.2.1.2: The Windows implementation uses the same Correlation Id value as provided in SoH, as specified in [TNC-IF-TNCCSPBSoH] section 3.8.

<9> Section 2.2.1.4: The Windows implementation of HCEA follows the behavior recommended in this section when assigning a value to the subject token.

<10> Section 2.2.1.4: The Windows implementation uses the EKU OID value of "1.3.6.1.4.1.311.47.1.1" (napHealthyOid).

<11> Section 2.2.1.4: The Windows implementation uses the EKU OID value of "id-kp-clientAuth", as specified in [RFC3280] section 4.2.1.13, if the ClientAuthenticationFlag ADM element as specified in section 3.1.1 is set to TRUE.

<12> Section 2.2.1.4: The Windows implementation uses OID "1.3.6.1.4.1.311.13.2.2" (szOID_ENROLLMENT_CSP_PROVIDER) as a certificate extension in the certificate request.

<13> Section 2.2.2.2: The Windows implementation uses the same Correlation Id value that is provided in SoH, as specified in [TNC-IF-TNCCSPBSoH] section 3.8.

<14> Section 2.2.2.2: The values of the HCEP-AFW-Protection-Level and HCEP-AFW-Zone fields are set as metadata on the health certificates received from the HRA. Windows Vista, Windows 7, Windows 8, and Windows 8.1 have a component that behaves as an IPsec (for more information, see [MSFT-IPSEC]) policy source. The hint provided by the value of HCEP-AFW-Zone is used to select one of the preconfigured IPsec policies on the computer. The value of the HCEP-AFW-Zone field is ignored if it is not "1", "2", or "3".

<15> Section 2.2.2.2: The Windows implementation of the HRA does not implement any response header fields other than the fields mentioned in this document.

<16> Section 2.2.2.3: Regarding the HTTP message body in the HCEP response in the Windows implementation: If the HCEP client is compliant with health policies, HRA receives an SoHR from the health policy server, and HRA receives a certificate response (PKCS #7) from CA, then the HRA returns the certificate response in the HTTP message body. Otherwise, if the Health Certificate Enrollment Protocol client is not compliant with health policies, no message body is present in the HCEP response.

<17> Section 2.2.2.4: For Windows Vista operating system with Service Pack 1 (SP1), Windows Server 2008 operating system, Windows 7, Windows Server 2008 R2, Windows 8, Windows Server 2012, Windows 8.1, and Windows Server 2012 R2:

Extended key usage: The health certificate response contains the OID "1.3.6.1.4.1.311.47.1.1" (napHealthyOid) if the client is compliant. If a server is configured to send a health certificate response when a client is noncompliant, the health certificate response contains the OID "1.3.6.1.4.1.311.47.1.3" (napUnhealthyOid).

MSApplicationPolicies: If present, this contains the following:

• The OID "1.3.6.1.4.1.311.47.1.10" (napPolicyInformationCompliantOid) if the client is compliant.

• The OID "1.3.6.1.4.1.311.47.1.11" (napPolicyInformationNotCompliantOid) if the client is noncompliant.

• The OID "1.3.6.1.4.1.311.47.1.12" (napPolicyInformationIsolationStateOid) for the compliance state with values:

  • 1: Compliant.

  • 2: Network connectivity is not being restricted but might be at a later time.

  • 3: Noncompliant.

• The OID "1.3.6.1.4.1.311.47.1.13" (napPolicyInformationExtendedStateOid) for the extended state with values:

  • 0: No additional data.

  • 1: Transition data.

  • 2: Infected data.

  • 3: Unknown data.

Compliance and extended state are specified in [TNC-IF-TNCCSPBSoH].

<18> Section 3: Windows Server 2008, Windows Server 2008 R2, Windows Server 2012, and Windows Server 2012 R2 can also act as "HCEP clients" to use HCEP to communicate with other servers running Windows Server 2008, Windows Server 2008 R2, Windows Server 2012, and Windows Server 2012 R2.

<19> Section 3.1.1: The Windows implementation of the HCEA determines the value of the ClientAuthenticationFlag ADM element to be TRUE if the client computer is a part of an Active Directory domain; otherwise, the value of this element is FALSE.

<20> Section 3.1.1: In the Windows implementation, the PersistedComputerCertificates ADM element is part of the persisted local certificate storage of the autoenrollment feature that is described in [MS-CERSOD] section 2.1.2.2.2.

<21> Section 3.1.4: The Windows implementation of the HCEA re-enrolls for a health certificate when it determines a configuration change has occurred with respect to HRA URLs.

<22> Section 3.1.4: The Windows implementation has an empty list by default.

<23> Section 3.1.5.2: The Windows implementation of the HCEA does not validate the values of the HCEP header fields.

<24> Section 3.1.5.2: The Windows implementation of the HCEA does not compare the value of the HCEP-correlation-Id header to the value stored in the CorrelationId ADM element.

<25> Section 3.1.5.2: The Windows implementation of the HCEA does not discard the response if the HCEP-Correlation-Id in the HCEP response does not match the one that was sent in the corresponding HCEP request (as stored in the CorrelationId ADM element).

<26> Section 3.1.5.2: Windows implementations of HCEA use Certificate Store Functions (see [MSDN-CERTCERTSTR] for details) for storing certificates. Certificate Store Functions support associating metadata with the certificate by means of Certificate Context Properties; values of AFW-Zone and AFW-Protection-Level are stored in Custom Properties with IDs 0x08000 and 0x8001 respectively.

<27> Section 3.1.7: The Windows implementation of the HCEA sends an HCEP request to the configured servers when an IP address change is detected on any machine interface and when a previously unreachable request is made to the servers.

<28> Section 3.2.1: The Windows implementation allows any of these settings; however, by default, it does not contain any predefined server settings.

<29> Section 3.2.1:  By default, the Windows implementation has an empty list. Example value: "NAP IPSec Enforcement v1.0".

<30> Section 3.2.1:  By default, the Windows implementation has an empty list. Only OIDs are configured in the list. The name is provided in the following table for ease of readability.

<31> Section 3.2.1:  By default, the Windows implementation has an empty list. Only OIDs are configured in the list. The name is provided in the following table for ease of readability.

<32> Section 3.2.1:  By default, the Windows implementation has an empty list.

Example CSPs are as follows:

• Microsoft Base Cryptographic Provider v1.0

• Microsoft Base DSS and Diffie-Hellman Cryptographic Provider

• Microsoft Base DSS Cryptographic Provider

• Microsoft Base Smart Card Crypto Provider

• Microsoft DH SChannel Cryptographic Provider

• Microsoft Enhanced Cryptographic Provider v1.0

• Microsoft Enhanced DSS and Diffie-Hellman Cryptographic Provider

• Microsoft Enhanced RSA and AES Cryptographic Provider

• Microsoft Exchange Cryptographic Provider v1.0

• Microsoft RSA SChannel Cryptographic Provider

• Microsoft Strong Cryptographic Provider

<33> Section 3.2.1:  By default, the Windows implementation restricts the maximum size to 64 KB.

<34> Section 3.2.1: The value set to the EvaluationTimeOut ADM in the windows implementation of HRA is 500 milliseconds. This value cannot be changed or configured.

<35> Section 3.2.5.1: The Windows implementation of the HRA has the following behavior for the optional requirements that are listed in this section:

• Maximum size: by default, 64 KB. This can be configured to a different value.

•  By default, accept all user agents. This behavior can be restricted to a configured list of user agents by specifying a substring of the user-agent values. Wildcards are not allowed in the list of user agents.

• By default, accept all public key algorithms. This behavior can be restricted to a configured list of public key algorithms.

• By default, accept all signature algorithms. This behavior can be restricted to a configured list of signature algorithms.

• By default, accept all CSPs. This behavior can be restricted to a configured list of CSPs.

<36> Section 3.2.5.3: This behavior is only available on a Server SKU implementation where HRA is installed, and was first released in Windows Server 2008.

<37> Section 3.2.5.3: The decision whether or not to request a health certificate for a presented SoH that is not compliant with the policy in the Windows implementation of the HRA is controlled by a setting in the HRA configuration located in the registry key: "Software\Microsoft\HCS\". The contents of the registry key are as follows:

Value: PolicyExtensionOn.

Type: REG_DWORD.

Data: A 32-bit unsigned integer.

If the HRA is set to request a health certificate for a non-compliant SoH, the HRA communicates with the CA using the [MS-WCCE] protocol and the exact processing steps are described in section 2.2.2.3 of the Health Certificate Enrollment Protocol.

<38> Section 3.2.5.3: This behavior is only available on a Server SKU implementation where HRA is installed, and was first released in Windows Server 2008.

<39> Section 3.2.5.4: Certificate Policies are added when a certificate has to be issued for noncompliant clients.

<40> Section 3.2.5.4: Windows Server 2008 behavior only.

<41> Section 3.2.5.4: Windows Server 2008 behavior only.

<42> Section 3.2.5.4: Windows Server 2008 behavior only.

<43> Section 3.2.5.4: This behavior was first released in Windows Server 2008 R2 operating system.

<44> Section 3.2.5.4: The attribute is added to the CMC request in the Server SKU implementation where HRA is installed.

<45> Section 3.2.5.4: This behavior was first released in Windows Server 2008 R2 SKU.

<46> Section 3.2.5.4: The attribute is added to the CMC request in the Server SKU implementation where HRA is installed.

<47> Section 3.2.5.4: The attribute is added to the CMC request in the Server SKU implementation where HRA is installed.