en.xenapp.ps sec node wrapper xa65

7/29/2019 En.xenapp.ps Sec Node Wrapper Xa65

1/53

XenApp 6.5 Security Standards andDeployment Scenarios

2011 Citrix Systems, Inc. All rights reserved. Terms of Use | Trademarks | Privacy Statement
http://www.citrix.com/legalhttp://www.citrix.com/trademarkhttp://www.citrix.com/legal


2/53

Contents

XenApp 6.5 Security Standards and Deployment Scenarios 4

XenApp 6.5 Security Standards and Deployment Scenarios 6

Security Considerations in a XenApp Deployment 8

Country-Specific Government Information 10

FIPS 140 and XenApp 11

SSL/TLS Protocols 14

Government Ciphersuites 16

IP Security 17

Citrix Single Sign-on 18

Smart Cards 19

Kerberos Authentication 21

Citrix Receiver and Plug-ins 22

Virtual Channels 25

Additional Security Features 26

Deployment Samples 27

Sample A Using the SSL Relay 28

How the Components in Sample Deployment A Interact 29

Security Considerations in Sample Deployment A 30

Sample B Using Secure Gateway (Single-Hop) 32

How the Components in Sample Deployment B Interact 34

Security Considerations for Sample Deployment B 36

Sample C Using Secure Gateway (Double-Hop) 38

How the Components in Sample Deployment C Interact 40

Security Considerations in Sample Deployment C 41

Sample D Using the SSL Relay and the Web Interface 43

How the Components in Sample Deployment D Interact 45

Security Considerations for Sample Deployment D 46

Sample E Using Citrix Single Sign-on and Secure Gateway (Single-Hop) 48

How the Components in Sample Deployment E Interact 50

2


3/53

Security Considerations for Deployment Sample E 52

3


4/53

4

XenApp 6.5 Security Standards and

Deployment Scenarios

Citrix products offer the security specialist a wide range of features for securing a XenApp

system according to officially recognized standards.

Security standards as they apply to Citrix XenApp 6.5 for Microsoft Windows Server 2008 R2

are discussed here. These topics provide an overview of the standards that apply to XenApp

deployments and describe the issues involved in securing communications across a set of

sample XenApp deployments. For more information about the details of the individual

security features, refer to the relevant product or component documentation.

When deploying XenApp within large organizations, particularly in government

environments, security standards are an important consideration. For example, manygovernment bodies in the United States and elsewhere specify a preference or requirement

for applications to be compliant with Federal Information Processing Standards (FIPS) 140.

These topics address common issues related to such environments.

These topics are designed for security specialists, systems integrators, and consultants,

particularly those working with government organizations worldwide.

What's New in XenApp 6.5 Security Standards

The 6.5 release modifies several XenApp features in order to comply with the new FIPS 140guidelines for 2010.

q SHA-256 hashing -

q The Citrix Streaming Profiler now creates SHA-256 hashes of each file in a profile.

When enabled for backwards compatibility with the legacy Offline Plug-in 6.0.x, the

Offline Plug-in can verify the integrity of profiles that contain SHA-256 and SHA-1

hashes. For more information, see To support legacy plug-ins.

q SmartAuditor now creates SHA-256 hashes of saved sessions. For backwards

compatibility, the SmartAuditor Player can verify the integrity of sessions whose

integrity checksum is computed using SHA-256 or SHA-1.q 2048-bit RSA keys -

q IMA Encryption now creates 2048-bit RSA keys.

q The keys contain both size and algorithm information, and can be imported by any

version of XenApp that supports IMA Encryption.

q IMA Encryption RSA keys are generated only during a new install or when manually

changed. If the key is replaced on one server, it must be replaced on all servers.

Therefore, there are no issues arising from mixed farms.
http://support.citrix.com/proddocs/index.jsp?lang=en&topic=/xenapp65-publishing/ps-stream-profile-task-legacy.html


5/53

q Application streaming supports certificates containing 2048-bit RSA keys.

In This Section

Security Considerations in a XenApp Deployment

Deployment Samples

Quick LinksApplication Streaming

SmartAuditor

IMA Encryption

Single Sign-On

XenApp 6.5 Security Standards and Deployment Scenarios

5
http://support.citrix.com/proddocs/index.jsp?lang=en&topic=/passwordmanager-5-0/pm-landing-page-version-50.htmlhttp://support.citrix.com/proddocs/index.jsp?lang=en&topic=/xenapp65-planning/ps-planning-config-log-ima-encrypt-v2.htmlhttp://support.citrix.com/proddocs/index.jsp?lang=en&topic=/xenapp65-w2k8/ps-sa-library-wrapper-v2.htmlhttp://support.citrix.com/proddocs/index.jsp?lang=en&topic=/xenapp65-planning/ps-planning-streaming-v2.html


6/53

6

Security Considerations in a XenApp

Deployment

Server FarmsA server farm is a collection of XenApp servers that you can manage (from the Delivery

Services Console) as a single entity. A server can belong to only one farm, but a farm can

include servers from more than one domain. The design of server farms must balance two

goals:

q Providing users with the fastest possible application access

q

Achieving the required degree of centralized administration and network security

Independent Computing Architecture (ICA)XenApp provides server-based computing to local and remote users through the

Independent Computing Architecture (ICA) protocol developed by Citrix. ICA is the

communication protocol by which servers and client devices exchange data in a XenApp

environment. ICA is optimized to enhance the delivery and performance of this exchange,

even on low bandwidth connections.

As an application runs on the server, XenApp intercepts the applications display data and

uses the ICA protocol to send this data (on standard network protocols) to the CitrixReceiver software running on the users client device. When the user types on the keyboard

or moves and clicks the mouse, the Citrix Receiver software sends the generated data to

the application running on the server for processing.

ICA requires minimal client workstation capabilities, and includes error detection and

recovery, encryption, and data compression.

Note:

q XenApp also supports sending audio via UDP in a real time protocol (RTP) stream. When

this feature is enabled, audio data not transmitted in the ICA protocol, but is instead

sent in a separate UDP stream. For more information, see Configuring Audio.

q The HDX Flash redirection technology may stream Flash content outside of the ICA

protocol in separate TCP connections. For more information, see Configuring HDX

MediaStream Flash Redirection.

Web InterfaceIn XenApp deployments that include the Web Interface, use HTTPS for communication

between the server running the Web Interface and the client devices running Web browsers

(and Citrix Receiver software).
http://support.citrix.com/proddocs/index.jsp?lang=en&topic=/xenapp65-admin/hd-flash-wrapper-ad.htmlhttp://support.citrix.com/proddocs/index.jsp?lang=en&topic=/xenapp65-admin/hd-flash-wrapper-ad.htmlhttp://support.citrix.com/proddocs/index.jsp?lang=en&topic=/xenapp65-admin/hd-audio-settings-ad.html


7/53

SSL Relay and Secure GatewayIn a XenApp deployment, administrators can configure encryption using:

q

SSL Relay, a component that is integrated into XenApp

q Secure Gateway, a separate component provided on the XenApp installation media

For more information, see SSL/TLS Protocols.

XenApp 6.5 Security Standards and Deployment Scenarios

7


8/53

8

Security Considerations in a XenApp

Deployment

Server FarmsA server farm is a collection of XenApp servers that you can manage (from the Delivery

Services Console) as a single entity. A server can belong to only one farm, but a farm can

include servers from more than one domain. The design of server farms must balance two

goals:

q Providing users with the fastest possible application access

q

Achieving the required degree of centralized administration and network security

Independent Computing Architecture (ICA)XenApp provides server-based computing to local and remote users through the

Independent Computing Architecture (ICA) protocol developed by Citrix. ICA is the

communication protocol by which servers and client devices exchange data in a XenApp

environment. ICA is optimized to enhance the delivery and performance of this exchange,

even on low bandwidth connections.

As an application runs on the server, XenApp intercepts the applications display data and

uses the ICA protocol to send this data (on standard network protocols) to the CitrixReceiver software running on the users client device. When the user types on the keyboard

or moves and clicks the mouse, the Citrix Receiver software sends the generated data to

the application running on the server for processing.

ICA requires minimal client workstation capabilities, and includes error detection and

recovery, encryption, and data compression.

Note:

q XenApp also supports sending audio via UDP in a real time protocol (RTP) stream. When

this feature is enabled, audio data not transmitted in the ICA protocol, but is instead

sent in a separate UDP stream. For more information, see Configuring Audio.

q The HDX Flash redirection technology may stream Flash content outside of the ICA

protocol in separate TCP connections. For more information, see Configuring HDX

MediaStream Flash Redirection.

Web InterfaceIn XenApp deployments that include the Web Interface, use HTTPS for communication

between the server running the Web Interface and the client devices running Web browsers

(and Citrix Receiver software).
http://support.citrix.com/proddocs/index.jsp?lang=en&topic=/xenapp65-admin/hd-flash-wrapper-ad.htmlhttp://support.citrix.com/proddocs/index.jsp?lang=en&topic=/xenapp65-admin/hd-flash-wrapper-ad.htmlhttp://support.citrix.com/proddocs/index.jsp?lang=en&topic=/xenapp65-admin/hd-audio-settings-ad.html


9/53

SSL Relay and Secure GatewayIn a XenApp deployment, administrators can configure encryption using:

q

SSL Relay, a component that is integrated into XenApp

q Secure Gateway, a separate component provided on the XenApp installation media

For more information, see SSL/TLS Protocols.

Security Considerations in a XenApp Deployment

9


10/53

10

Country-Specific Government Information

The following topics are of particular relevance to XenApp installations in Australia, theUnited Kingdom, and the United States:

q FIPS 140 and XenApp

q SSL/TLS Protocols

q Smart Cards - includes information on Common Access Cards (of particular relevance to

installations in the United States)

q Kerberos Authentication

For more information about issues specific to your country, contact your local Citrix

representative.


11/53

11

FIPS 140 and XenApp

Federal Information Processing Standard 140 (FIPS 140) is a U.S. Federal Governmentstandard that specifies a benchmark for implementing cryptographic software. It provides

best practices for using cryptographic algorithms, managing key elements and data buffers,

and interacting with the operating system. An evaluation process that is administered by

the National Institute of Standards and Technology (NIST) National Voluntary Laboratory

Accreditation Program (NVLAP) allows encryption product vendors to demonstrate the

extent to which they comply with the standard and, thus, the trustworthiness of their

implementation.

For more information about FIPS 140 and NIST, visit the NIST Web site at

http://csrc.nist.gov/cryptval.

FIPS 140 Versionsq FIPS 140-1, published in 1994, established requirements for cryptographic modules to

provide four security levels that allowed cost-effective solutions appropriate for

different degrees of data sensitivity and different application environments.

q FIPS 140-2, which superseded FIPS 140-1 in 2002, incorporated changes in standards and

technology since 1994.

q FIPS 140-3, which is still in draft, adds an additional security level and incorporates new

security features that reflect recent advances in technology.

When configured properly, XenApp 6.5 can use FIPS 140-validated cryptographic modules ina manner that is compliant with FIPS 140-2.

Market for FIPS 140-Validated ModulesThe security community at large values products that follow the guidelines detailed in FIPS

140 and the use of FIPS 140-validated cryptographic modules.

Some U.S. Government organizations restrict purchases of products that contain

cryptography to those that use FIPS 140-validated modules.

In the U.K., guidance published by the Communications-Electronics Security Group (CESG)recommends the use of FIPS 140-approved products where the required use for information

is below the RESTRICTED classification, but is still sensitive (that is, data classified

PROTECT).

For a list of currently validated FIPS 140 modules, see

http://csrc.nist.gov/cryptval/140-1/1401val.htm.
http://csrc.nist.gov/cryptval/140-1/1401val.htmhttp://csrc.nist.gov/cryptval/


12/53

XenApp and Cryptographic ModulesTo implement secure access to application servers and to meet the FIPS 140 requirements,

Citrix products can use cryptographic modules that are FIPS 140-validated in Windows

implementations of secure TLS or SSL connections. The following XenApp components can

use cryptographic modules that are FIPS 140-validated:

q XenApp

q Citrix Receiver and Citrix online plug-in

q Web Interface

q SSL Relay

q Secure Gateway for Windows

q Single Sign-on

q Offline applications (streaming)

q SmartAuditor

q Power and Capacity Management

q Configuration Logging

q ICA File Signing

Where these client and server components communicate with the TLS or SSL connection

enabled, the cryptographic modules that are used are provided by the Microsoft Windows

operating system. These modules use the Microsoft Cryptography Application ProgrammingInterface (CryptoAPI) and are FIPS 140-validated.

Note: On both Windows Vista with Service Pack 1 and Windows Server 2008, you must

apply Microsoft hotfix kb954059 (http://support.microsoft.com/kb/954059) to ensure

that the random number generator used within CryptoAPI and, therefore the underlying

operating system, is FIPS 140-compliant.

FIPS ComplianceFIPS compliance is achieved as follows:

q According to the Microsoft documentation

(http://technet.microsoft.com/en-us/library/cc750357.aspx), FIPS-compliant systems

that use FIPS 140-certified cryptomodules can be deployed by following a prescribed set

of steps. These steps include setting a particular FIPS local policy flag.

q As noted in the Microsoft documentation referenced above, not all Microsoft

components and products check the FIPS local policy flag. Refer to the Microsoft

documentation for instructions on how to configure these components and products to

behave in a FIPS-compliant manner.

FIPS 140 and XenApp

12
http://technet.microsoft.com/en-us/library/cc750357.aspxhttp://support.microsoft.com/kb/954059


13/53

q Similarly, Citrix components do not check the FIPS local policy flag. Instead, these

components must be configured to behave in a FIPS-compliant manner. Specifically,

Citrix components that use TLS must be configured to use Government Ciphersuites.

q RSA_WITH_3DES_EDE_CBC_SHA [RFC 2246]

q

RSA_WITH_AES_128_CBC_SHA [FIPS 197, RFC 3268]

q RSA_WITH_AES_256_CBC_SHA [FIPS 197, RFC 3268]

Given the accuracy of the above statements, and assuming that all these steps are

followed, the resulting XenApp configuration will use FIPS 140 cryptomodules in a

FIPS-compliant manner.

FIPS 140 and XenApp

13


14/53

14

SSL/TLS Protocols

If client devices in your environment communicate with your farm across the Internet,Citrix recommends enabling Secure Sockets Layer (SSL) 3.0 or Transport Layer Security

(TLS) 1.0 encryption when you publish a resource. These protocols are collectively referred

to SSL/TLS.

Both SSL and TLS are open protocols that provide data encryption, server authentication,

message integrity, and optional client authentication for a TCP/IP connection:

q SSL is an open, nonproprietary security protocol for TCP/IP connections.

q TLS, which is also an open standard, is the latest, standardized version of the SSL

protocol.

SSL 3.0 and TLS 1.0 are not interoperable. However, because there are only minordifferences between them, the server certificates in your installation can be used for both

SSL and TLS implementations.

SSL/TLS and FIPS ComplianceWhen configured properly, deployments using TLS 1.0 can use FIPS 140-validated

cryptographic modules in a manner that is compliant with FIPS 140-2; SSL 3.0 is not FIPS

compliant. For more information, refer to the Guidelines for the Selection and Use of the

Transport Layer Security (TLS) implementations at

http://csrc.nist.gov/publications/nistpubs/800-52/SP800-52.pdf.

Using SSL/TLS with SSL Relay or Secure GatewayIf you want to use SSL/TLS encryption, you must either use the SSL Relay feature or the

Secure Gateway or both to relay ICA traffic to the computer running XenApp. For more

information, see the SSL Relay or Secure Gateway documentation.

Deployment samples in the XenApp 6.5 Security Standards documentation include

implementations of each. The nature of your environment may determine the way in which

you enable SSL:

q For client devices communicating with your farm remotely, Citrix recommends that youuse the Secure Gateway to pass client communications to the computer running

XenApp. The Secure Gateway can be used with SSL Relay on the computer running

XenApp to secure the Secure Gateway to XenApp traffic, depending on your

requirements.

q For client devices communicating with your farm internally, you can do one of the

following to pass client communications to the computer running XenApp:

q Use the Secure Gateway with an internal firewall and place your farm behind the

firewall.
http://support.citrix.com/proddocs/index.jsp?lang=en&topic=/xenapp65-w2k8/sg-node-wrapper-v65.htmlhttp://support.citrix.com/proddocs/index.jsp?lang=en&topic=/xenapp65-admin/ps-securing-using-ctx-ssl-relay.htmlhttp://csrc.nist.gov/publications/nistpubs/800-52/SP800-52.pdf


15/53

q Use the SSL Relay feature to secure the traffic between client devices and servers

in your farm.

Note:

q If you use SSL Relay, you must install it on every server in the farm.

q Because SSL Relay requires you to store certificates on each server, it may be less

convenient for larger environments. If your farm has more than five servers and you are

concerned with internal threats, you may prefer to use the Secure Gateway with an

internal firewall.

q To use SSL with the Secure Gateway or SSL Relay, you must select the Enable SSL andTLS protocols setting when you publish an application.

q If you are using Web Interface with the Secure Gateway, see the information about SSL

in the Secure Gateway and Web Interface administrator documentation.

SSL/TLS Protocols

15


16/53

16

Government Ciphersuites

You can configure XenApp, the Web Interface, and Secure Gateway to usegovernment-approved cryptography to protect "sensitive but unclassified" data by using the

applicable ciphersuite:

q RSA_WITH_3DES_EDE_CBC_SHA supports RSA key exchange and TripleDES encryption, as

defined in Internet RFC 2246 (http://www.ietf.org/rfc/rfc2246.txt).

q RSA_WITH_AES_128_CBC_SHA supports RSA key exchange with Advanced Encryption

Standard (AES) and 128-bit keys for TLS connections, as defined in FIPS 197

http://csrc.nist.gov/publications/fips/fips197/fips-197.pdfand Internet RFC 3268

(http://www.ietf.org/rfc/rfc3268.txt). For more information about AES, see

http://csrc.nist.gov/cryptval/des.htm.

q RSA_WITH_AES_256_CBC_SHA supports RSA key exchange with AES and 256-bit keys forTLS connections, as defined in FIPS 197 and RFC 3268.
http://csrc.nist.gov/cryptval/des.htmhttp://www.ietf.org/rfc/rfc3268.txthttp://csrc.nist.gov/publications/fips/fips197/fips-197.pdfhttp://www.ietf.org/rfc/rfc2246.txt


17/53

17

IP Security

IP Security (IPSec) is a set of standard extensions to the Internet Protocol (IP) that providesauthenticated and encrypted communications with data integrity and replay protection.

IPSec is described in Internet RFC 2401.

IPSec is a network-layer protocol set, so higher level protocols such as Citrix Independent

Computing Architecture (ICA) can use it without modification. Microsoft Windows 7,

Windows Vista, Windows XP, Windows Server 2008 R2, Windows Server 2008, and Windows

Server 2003 have built-in support for IPSec.

Although not illustrated in the sample deployments, you can use IPSec to secure a XenApp

deployment within a virtual private network (VPN) environment.
http://www.apps.ietf.org/rfc/rfc2401.html


18/53

18

Citrix Single Sign-on

Citrix Single Sign-on increases application security for all XenApp applications, allowingorganizations to centralize password management while providing users with fast sign-on

access to Web, Windows, and host-based applications.

For more information, see the Citrix Single Sign-on documentation.
http://support.citrix.com/proddocs/index.jsp?lang=en&topic=/passwordmanager-5-0/pm-landing-page-version-50.html


19/53

19

Smart Cards

You can use smart cards with XenApp, supported XenApp plug-ins, the Web Interface, andSingle Sign-on to provide secure access to applications and data. Using smart cards

simplifies the authentication process while enhancing logon security. XenApp supports

smart card authentication to published applications, including smart card-enabled

applications such as Microsoft Outlook.

In a business network, smart cards are an effective implementation of public key

technology and can be used for the following purposes:

q Authenticating users to networks and computers

q Securing channel communications over a network

q Securing content using digital signatures

If you are using smart cards for secure network authentication, your users can authenticate

to applications and content published on your server farms. In addition, smart card

functionality within these published applications is also supported.

For example, a published Microsoft Outlook application can be configured to require that

users insert a smart card into a smart card reader attached to the client device in order to

log on to a XenApp server. After users are authenticated to the application, they can

digitally sign email using certificates stored on their smart cards.

Note: The availability of some smart card features depends on the smart card

cryptographic service provider (CSP).

Secure Use of Smart CardsYour organization may have specific security policies concerning the use of smart cards.

These policies may, for example, state how smart cards are issued and how users should

safeguard them. Some aspects of these policies may need to be reassessed in a XenApp

environment:

q Tasks performed by smart card administrators (for example smart card issuance) may

be inappropriate for carrying out through XenApp. Usually these functions are

performed at a dedicated smart card station, and may require two smart card readers.

q Infrequent and sensitive tasks, such as unblocking a smart card, may also be

inappropriate for carrying out through XenApp. Security policies often forbid users to

perform these functions; they are carried out by the smart card administrator.

Note: Citrix recommends that you carry out these tasks locally on the user device if

possible, rather than using XenApp.

q Highly sensitive applications that require strict separation of duties or tamper-resistant

audit trails may entail additional special-purpose security control measures. These

measures are outside the scope of XenApp.


20/53

You can reset PINs from the desktop using Microsoft Identity Lifecycle Manager (ILM) and

Certificate Lifecycle Manager (CLM) smart card management systems, or using any smart

card vendor's reset utilities that use the Windows smart card PC/SC (WinSCard) API.

Smart Card SupportCitrix supports the use of Personal Computer Smart Card (PC/SC)-based cryptographic smart

cards. These cards include support for cryptographic operations such as digital signatures

and encryption. Cryptographic cards are designed to allow secure storage of private keys

such as those used in Public Key Infrastructure (PKI) security systems. These cards perform

the actual cryptographic functions on the smart card itself, meaning that the private key

and digital certificates never leave the card. In addition, you can use two-factor

authentication for increased security. Instead of merely presenting the smart card (one

factor) to conduct a transaction, a user-defined PIN (a second factor) known only to the

user, is used to prove that the cardholder is the rightful owner of the smart card.

XenApp supports various smart cards, including the Common Access Card in a deploymentthat includes the Citrix Receiver for Windows. Contact your Common Access Card vendor or

Citrix representative for more information about supported versions of Common Access

Card hardware and software.

Citrix continues to test smart cards to address compatibility with XenApp, using certificates

from common certificate authorities such as those supported by Microsoft. If you have any

concerns regarding your certificate authority and compatibility with XenApp, contact your

local Citrix representative.

Smart Cards

20


21/53

21

Kerberos Authentication

Kerberos is an authentication protocol. Version 5 of this protocol was first standardized asInternet RFC 1510. Many operating systems, including Microsoft Windows 2000 and later,

support Kerberos as a standard feature.

XenApp extends the use of Kerberos. When users log on to a client device, they can connect

to XenApp without needing to authenticate again. The users password is not transmitted to

XenApp; instead, authentication tokens are exchanged using the Generic Security Services

API (GSSAPI), which was first standardized in Internet RFC 1509.

This authentication exchange is performed within a Citrix Independent Computing

Architecture (ICA) virtual channel and does not require any additional protocols or ports.

The authentication exchange is independent of the logon method, so it can be used with

passwords, smart cards, or biometrics.

To use Kerberos authentication with XenApp, both the client and server must be

appropriately configured. You can also use Microsoft Active Directory Group Policy to

selectively disable Kerberos authentication for specific users and servers.

For information on implementing Kerberos Authentication in a XenApp environment, see

Knowledge Center article CTX121918.
http://support.citrix.com/article/CTX121918http://www.ietf.org/rfc/rfc1509.txthttp://www.apps.ietf.org/rfc/rfc1510.html


22/53

22

Citrix Receiver and Plug-ins

With Citrix Receiver or the Citrix online plug-in installed on their client devices, users canwork with applications running on XenApp servers. Users can access these applications from

virtually any type of client device over many types of network connection, including LAN,

WAN, dial-up, and direct asynchronous connections. Because the applications are not

downloaded to the client devices (as is the case with the more traditional network

architecture), application performance is not limited by bandwidth or device performance.

Citrix Receiver is available for Windows, Windows CE, Macintosh, Linux, Solaris, Android,

Blackberry, and iOS operating systems, as well as the Java Runtime Environment.

Additionally, you can use the Citrix online plug-in Web with Web browsers that support

ActiveX controls or Netscape plug-ins.

Citrix Receiver for Windows and the Citrix online plug-in use cryptographic modules

provided by the operating system. Other plug-ins, including Citrix Receiver for Java,contain their own cryptographic modules. Citrix Receiver for Java can, therefore, be used

on older Windows operating systems that do not support strong encryption.

The Standards Summary table lists the latest versions of Citrix Receiver available on various

platforms and indicates whether each plug-in is FIPS 140 compliant, supports TLS, uses 3DES

or AES government ciphersuites, supports certificate revocation checking, includes smart

card support, or supports Kerberos authentication.

Standards SummaryThe following table summarizes the security standards relevant to Citrix Receiver and theCitrix online plug-in:

Platform and Version FIPS

140

TLS Triple

DES

AES CRL

check

Smart

card

Kerberos

Citrix Receiver for

Windows 3.0

*1

* * * *3

* *

Citrix Receiver for

Windows CE for

Windows-Based

Terminals 11.02

*2

* * *

Citrix Receiver for

Windows CE for

Handheld and Pocket

PCs 11.02

*2

* * *

Citrix Receiver for

Macintosh 11.3

* * * * *

Citrix Receiver for Linux

12.1

* * *


23/53

Citrix Receiver for Sun

Solaris 8.63

* * *

Citrix Receiver for Java

10.1

* * * *3

*4

Citrix Receiver for

Android 2.1

* * * *

Citrix Receiver for

BlackBerry 2.1

* * * *5

Citrix Receiver for

Playbook 1.0

* * *

Citrix Receiver for iOS

4.2.3

Citrix online plug-in 12.1 *1

* * * *3

* *

Citrix online plug-in Web

12.1

*1

* * * *3

* *

Notes:

1These plug-ins inherit FIPS 140 compliance from the base operating system, Windows.

2These plug-ins inherit FIPS 140 compliance from the base operating system, Windows

CE.

3Certificate revocation checking is only applicable to plug-ins running on Windows XP,

Windows Vista, or Windows 7.

4Kerberos authentication is not supported when the Citrix Receiver for Java is running

on Mac OS X client devices.

5 Certificate revocation checking is subject to device configuration.

Root Certificate SourceThe table below shows the root certificate source for each version of the Citrix Receiver or

Citrix online plug-in.

Plug-in type Root certificate source

Citrix Receiver for Windows 3.0 operating system certificate store

Citrix Receiver for Windows CE for

Windows-Based Terminals 11.02

operating system certificate store

Citrix Receiver for Windows CE for

Handheld and Pocket PCs 11.02

operating system certificate store

Citrix Receiver for Macintosh 11.3 operating system certificate store

Citrix Receiver for Linux 12.1 bundled with the plug-in

Citrix Receiver for Sun Solaris 8.63 bundled with the plug-in


23


24/53

Citrix Receiver for Java 10.1 Java keystore (Java 1.4.x)

Java keystore or operating system

certificate store (Java 1.5.xor later)

Citrix Receiver for Android 2.1 Android keystore

Citrix Receiver for BlackBerry 2.1 operating system certificate store

Citrix Receiver for Playbook 1.0 bundled with the plug-in

Citrix Receiver for iOS 4.2.3

Citrix online plug-in 12.1 operating system certificate store

Citrix online plug-in Web 12.1 operating system certificate store


24


25/53

25

Virtual Channels

The following table shows which Citrix Independent Computing Architecture (ICA) virtualchannels or combination of virtual channels can be used with XenApp for authentication, or

for and application signing and encryption methods.

Note: This table applies only to XenApp, not to Citrix Single Sign-on.

Core ICA protocol (no virtual

channel)

Smart card

virtual channel

Kerberos virtual

channel

Smart card

authentication

* *

Biometric1

authentication

*

Password

authentication

* *

Application

signing/encryption

*

1Third-party equipment is required for biometric authentication.


26/53

26

Additional Security Features

The following products can be used with XenApp to provide additional security. Theseadditional security measures are not included in the sample deployments.

ICA Encryption Using SecureICAICA encryption with SecureICA is integrated into XenApp. With SecureICA, you can use up to

128-bit encryption to protect the information sent between a XenApp server and users

client devices. However, it is important to note that SecureICA does not use FIPS

140-compliant algorithms. If this is an issue, configure XenApp servers and plug-ins to avoid

using SecureICA.

Authentication for the Web Interface Using RSASecurID

You can use the third-party product RSA SecurID as an authentication method for the Web

Interface running on Internet Information Services. If RSA SecurID is enabled, users must log

on using their credentials (user name, password, and domain) plus their SecurID PASSCODE.

The PASSCODE is made up of a PIN followed by a tokencode (the number displayed on the

users RSA SecurID token).

RSA SecurID supports authentication on both XenApp and Citrix Single Sign-on.

Authentication for the Web Interface Using SafeWordYou can use the third-party product Aladdin SafeWord as an authentication method for the

Web Interface running on Internet Information Services. If SafeWord is enabled, users must

log on using their credentials (user name, password, and domain) plus their SafeWord

passcode. The passcode is made up of the code displayed on the users SafeWord token,

optionally followed by a PIN.

SafeWord supports authentication on XenApp, but not on Single Sign-on.


27/53

27

Deployment Samples

To make a XenApp deployment FIPS 140-compliant, you need to consider eachcommunication channel within the installation. The following deployment samples show

how users can connect to XenApp servers with different configurations of components and

firewalls. In particular, the samples provide general guidance on how to make each

communication channel secure using SSL/TLS so that the system as a whole is FIPS

140-compliant.

q Sample A - Using the SSL Relay

q Sample B - Using Secure Gateway (Single-Hop)

q Sample C - Using Secure Gateway (Double-Hop)

q Sample D - Using the SSL Relay and the Web Interface

q Sample E - Using Citrix Single Sign-on and Secure Gateway (Single-Hop)

Note: Secure Gateway and the SSL Relay support both SSL- and TLS-based encryption.

Your choice of method is largely determined by which topology best meets the needs of

your organizations security policies. Refer to SSL/TLS Protocols for more information.


28/53

28

Sample A Using the SSL Relay

This deployment uses the SSL Relay to provide end-to-end SSL/TLS encryption between theXenApp server and Citrix Receiver running on the user devices.

This diagram shows sample deployment A, which uses the SSL Relay.

The following table lists the components of the deployment and the operating systems

required for the servers and client devices.

Components Operating systems

XenApp farm XenApp 6.5 for Microsoft WindowsServer 2008 R2

SSL Relay enabled

Secure Ticket Authority installed

on XenApp server

Windows Server 2008 R2

User devices Citrix Receiver for Windows 3.0

TLS-enabled Web browser

Windows 7

Windows Vista

Windows XP Professional


29/53

29

How the Components in Sample

Deployment A Interact

Use SSL/TLS to secure the connections between client devices and the XenApp servers. To

do this, deploy SSL/TLS-enabled plug-ins to users and configure the SSL Relay on the

XenApp servers.

This deployment provides end-to-end encryption of the communication between the client

device and the XenApp servers. Both the SSL Relay and the appropriate server certificate

must be installed and configured on each server in the farm.

The SSL Relay operates as an intermediary in communication between client devices and

the XML Service on each server. Each client device authenticates the SSL Relay by checking

the SSL Relays server certificate against a list of trusted certificate authorities. After thisauthentication, the client device and the SSL Relay negotiate requests in encrypted form.

The SSL Relay decrypts the requests and passes them to the XenApp servers. All information

sent from the servers to the client device passes through the SSL Relay, which encrypts the

data and forwards it to the client device to be decrypted. Message integrity checks verify

that each communication has not been tampered with.

This diagram shows a detailed view of sample deployment A.


30/53

30

Security Considerations in Sample

Deployment A

FIPS 140 Validation in Sample Deployment AIn this deployment, the SSL Relay uses the Microsoft cryptographic service providers (CSPs)

and associated cryptographic algorithms available in the Microsoft Windows CryptoAPI to

encrypt and decrypt communication between client devices and servers. For more

information about the FIPS 140 validation of the CSPs, see the Microsoft documentation.

SSL/TLS support and the supported ciphersuites can also be controlled using the Microsoft

security option System cryptography: Use FIPS compliant algorithms for encryption,

hashing, and signing for the following configurations:

XenApp farm Operating System

XenApp 6.5 Windows 7, Windows Vista, Windows XP, Windows Server 2008 R2


XenApp 5.0 Windows Server 2008, Windows Server 2003

For more information, see the documentation for your operating system.

SSL/TLS Support in Sample Deployment AYou can configure XenApp to use either the Secure Sockets Layer 3.0 protocol or the

Transport Layer Security 1.0 protocol. In sample deployment A, the components are

configured for TLS. When using the SSL Relay Configuration Tool, ensure that TLS isselected on the Connection tab.

Supported Ciphersuites for Sample Deployment AIn this deployment, XenApp can be configured to use government-approved cryptography,

such as the ciphersuite RSA_WITH_3DES_EDE_CBC_SHA, to protect sensitive but

unclassified data. When using the SSL Relay Configuration Tool, ensure that only GOV is

selected on the Ciphersuite tab.

For TLS connections, you can choose other Government Ciphersuites that employ RSA key

exchange and the Advanced Encryption Standard (AES).


31/53

Certificates and Certificate Authorities in SampleDeployment A

Citrix products use standard Public Key Infrastructure (PKI) as a framework and trust

infrastructure. In sample deployment A, a separate server certificate is configured for each

XenApp server on which the SSL Relay is used. A root certificate is required for each client

device. For information on the root certificate source for your client devices, see Citrix

Receiver and Plug-ins

Smart Card Support in Sample Deployment AIn this deployment, you can configure XenApp to provide smart card authentication. To do

this, you must configure authentication with Microsoft Active Directory and use the

Microsoft Certificate Authority.

Plug-ins Used in Sample Deployment AIn this deployment, users access their applications using Citrix Receiver. For more

information about the security features and capabilities of Citrix Receiver, see Citrix

Receiver and Plug-ins.

Security Considerations in Sample Deployment A

31


32/53

32

Sample B Using Secure Gateway

(Single-Hop)

This deployment uses the Secure Gateway in a single-hop configuration to provide SSL/TLS

encryption between a secure Internet gateway server and an SSL-enabled plugin. Encrypted

communication between the Web browser and the Web server is via HTTPS. Additionally,

you can secure ICA traffic within the internal network using IPSec.

This diagram shows sample deployment B, which uses the Secure Gateway in a single-hop

configuration.





SSL Relay enabled


on XenApp server



33/53

Web server Web Interface 5.4 for Internet

Information Services


Windows Server 2008

Windows Server 2003 with Service

Pack 2

.NET Framework 3.5 or 2.0 (IIS

6.0 only)

Visual J#.NET 2.0 Second Edition

Secure

Gatewayserver

Secure Gateway 3.3 for Windows Windows Server 2008 R2

Windows Server 2008


Pack 2



Windows 7

Windows Vista


Sample B Using Secure Gateway (Single-Hop)

33


34/53

34


Deployment B Interact

Use TLS to secure the connections between client devices and the Secure Gateway. To do

this, deploy SSL/TLS-enabled plugins and configure the Secure Gateway at the network

perimeter, typically in a demilitarized zone (DMZ).

Secure the connections between users Web browsers and the Web Interface using HTTPS.

Additionally, secure communication between the Web Interface and the XenApp servers

using TLS.

This diagram shows a detailed view of sample deployment B.1.

In this deployment, the Secure Gateway removes the need to publish the address of every

XenApp server in the farm and provides a single point of encryption and access to the farm.

The Secure Gateway does this by providing a gateway that is separate from the XenApp

servers and reduces the issues for firewall traversal to a widely-accepted port for ICA

traffic in and out of the firewalls.

While sample deployment B.1 is highly scalable, the trade-off is that ICA communication is

encrypted only between client devices and the Secure Gateway, not between the Secure

Gateway and the XenApp servers.

Note: The SSL Relay in sample deployment B.1 is used to encrypt communicationbetween the Web Interface and the XML Service running on the XenApp servers. The

Secure Gateway communicates with the XenApp servers directly, so the SSL Relay is not

used for communication between the Secure Gateway and the server farm.

You can secure the communication between the Secure Gateway and the server farm using

IPSec, as shown in sample deployment B.2.

This diagram shows a detailed view of sample deployment B.2, which includes IPSec.


35/53

How the Components in Sample Deployment B Interact

35


36/53

36

Security Considerations for Sample

Deployment B

IPSec in Sample Deployment BTo enable IPSec to secure communication between Secure Gateway and the XenApp server

farm, you must configure IPSec on each server, including the Secure Gateway server.

IPSec is configured using the local security settings (IP security policies) for each server. In

sample deployment B.2, IPSec is enabled on the requisite servers and the security method is

configured for Triple DES encryption and SHA-1 integrity to meet FIPS 140 requirements.

FIPS 140 Validation in Sample Deployment BIn this deployment, the SSL Relay uses the Microsoft cryptographic service providers (CSPs)












SSL/TLS Support in Sample Deployment BYou can configure Secure Gateway and the Web Interface to use either the Transport Layer

Security 1.0 protocol or the Secure Sockets Layer 3.0 protocol. In sample deployment B, thecomponents are configured for TLS.

Supported Ciphersuites for Sample Deployment BIn this deployment, Secure Gateway and the Web Interface can be configured to use

government-approved cryptography, such as the ciphersuite

RSA_WITH_3DES_EDE_CBC_SHA, to protect sensitive but unclassified data.


37/53



Certificates and Certificate Authorities in Sample

Deployment BCitrix products use standard Public Key Infrastructure (PKI) as a framework and trust

infrastructure. In sample deployment B, one server certificate is configured on Secure

Gateway and one on the Web Interface. A certificate is also configured on each XenApp

server. A root certificate is required for each client device. For information on the root

certificate source for your client devices, see Citrix Receiver and Plug-ins.

Smart Card Support in Sample Deployment BIn this deployment, you can configure XenApp to provide smart card authentication. To do

this, you must configure authentication with Microsoft Active Directory and use theMicrosoft Certificate Authority.

Plug-ins Used in Sample Deployment BIn this deployment, users access their applications using Citrix Receiver. For more



Security Considerations for Sample Deployment B

37


38/53

38

Sample C Using Secure Gateway

(Double-Hop)

This deployment uses the Secure Gateway in a double-hop configuration to provide SSL/TLS

encryption between a secure Internet gateway server and an SSL-enabled plugin. Encrypted

communication between the Secure Gateway and the Web browser, and between the

Secure Gateway and the Web interface, is via HTTPS. ICA traffic within the internal

network is secured using IPSec.

This diagram shows sample deployment C, which uses the Secure Gateway in a double-hop

configuration.




XenApp farm XenApp 6.5 for Microsoft Windows

Server 2008 R2

SSL Relay enabled


on XenApp server



39/53




Windows Server 2008


Pack 2


6.0 only)


Secure

GatewayService

Secure

Gateway Proxy


Windows Server 2008


Pack 2



Windows 7

Windows Vista


Sample C Using Secure Gateway (Double-Hop)

39


40/53

40


Deployment C Interact


this, deploy SSL/TLS-enabled plug-ins and configure the Secure Gateway at the network

perimeter, typically in a DMZ.

Here, the DMZ is divided into two sections by an additional firewall. The server running the

Secure Gateway Service is located in the first section of the DMZ; the Web Interface and

the Secure Gateway Proxy are located in the second section. Communication between the

Secure Gateway Proxy and the server farm is secured using IPSec.

This diagram shows a detailed view of sample deployment C.

In this deployment, the Secure Gateway removes the need to publish the address of every

XenApp server in the farm and provides a single point of encryption and access to the farm.





41/53

41

Security Considerations in Sample

Deployment C

IPSec in Sample Deployment CTo enable IPSec to secure communication between the Secure Gateway Proxy and the

XenApp server farm, you must configure IPSec on each server, including the Secure

Gateway Proxy.


sample deployment C, IPSec is enabled on the requisite servers and the security method is


FIPS 140 Validation in Sample Deployment CIn this deployment, the SSL Relay uses the Microsoft cryptographic service providers (CSPs)





security option System cryptography: Use FIPS compliant algorithms for encryption,hashing, and signing for the following configurations:






SSL/TLS Support in Sample Deployment C

You can configure Secure Gateway and the Web Interface to use either the Transport LayerSecurity 1.0 protocol or the Secure Sockets Layer 3.0 protocol. In sample deployment C, the

components are configured for TLS.

Supported Ciphersuites for Sample Deployment CIn this deployment, Secure Gateway, the Secure Gateway Proxy, and the Web Interface can

be configured to use government-approved cryptography, such as the ciphersuite



42/53



Certificates and Certificate Authorities in Sample

Deployment CCitrix products use standard Public Key Infrastructure (PKI) as a framework and trust

infrastructure. In sample deployment C, one server certificate is configured on Secure

Gateway, one on the Secure Gateway Proxy, and one on the Web Interface. A certificate is

also configured on each XenApp server. A root certificate is required for each client device.

For information on the root certificate source for your client devices, see Citrix Receiver

and Plug-ins.

Smart Card Support in Sample Deployment CSmart card authentication is not supported in sample deployment C. You cannot configuresmart card support when Secure Gateway is positioned between the client devices and the

Web Interface to provide a single point of access to the server farm.

Plug-ins Used in Sample Deployment CIn this deployment, users access their applications using Citrix Receiver. For more



Security Considerations in Sample Deployment C

42


43/53

43

Sample D Using the SSL Relay and the

Web Interface

This deployment uses the SSL Relay and the Web Interface to encrypt the ICA and HTTP

communication between the XenApp server and the Web server. Encrypted communication

between the Web browser and the Web server is via HTTPS.

This diagram shows sample deployment D, which uses the SSL Relay and the Web Interface.





SSL Relay enabled


on XenApp server



44/53




Windows Server 2008


Pack 2


6.0 only)




Windows 7

Windows Vista


Sample D Using the SSL Relay and the Web Interface

44


45/53

45


Deployment D Interact

Use HTTPS to secure the connections between users Web browsers and the Web Interface.

Secure the connection between the Web Interface and the SSL Relay using TLS.

Additionally, use TLS to secure the connections between client devices and the SSL Relay.

The SSL Relay operates as an intermediary in communication between client devices, the

Web Interface, and the XML Service on each server. Each client device authenticates the

SSL Relay by checking the SSL Relays server certificate against a list of trusted certificate

authorities. After this authentication, the client device and the SSL Relay negotiate

requests in encrypted form. The SSL Relay decrypts the requests and passes them to the

XenApp servers. All information sent from the servers to the client device passes through

the SSL Relay, which encrypts the data and forwards it to the client device to be decrypted.Message integrity checks verify that each communication has not been tampered with.

This diagram shows a detailed view of sample deployment D.


46/53

46

Security Considerations for Sample

Deployment D

FIPS 140 Validation in Sample Deployment DIn this deployment, the SSL Relay uses the Microsoft cryptographic service providers (CSPs)












SSL/TLS Support in Sample Deployment DYou can configure the SSL Relay and the Web Interface to use either the Secure Sockets

Layer 3.0 protocol or the Transport Layer Security 1.0 protocol. In sample deployment D,

the components are configured for TLS.

When using the SSL Relay Configuration Tool, ensure that TLS is selected on the

Connection tab.

Supported Ciphersuites for Sample Deployment DIn this deployment, the SSL Relay and the Web Interface can be configured to use

government-approved cryptography, such as the ciphersuiteRSA_WITH_3DES_EDE_CBC_SHA, to protect sensitive but unclassified data. When using

the SSL Relay Configuration Tool, ensure that only GOV is selected on the Ciphersuite tab.




47/53

Certificates and Certificate Authorities in SampleDeployment D


infrastructure. In sample deployment D, a separate server certificate is configured for each

XenApp server on which the SSL Relay is used. A root certificate is required for each client

device. For information on the root certificate source for your client devices, see Citrix


Smart Card Support in Sample Deployment DIn this deployment, you can configure XenApp to provide smart card authentication. To do



Plug-ins Used in Sample Deployment DIn this deployment, users access their applications using Citrix Receiver. For more



Security Considerations for Sample Deployment D

47


48/53

48

Sample E Using Citrix Single Sign-on

and Secure Gateway (Single-Hop)

This deployment uses Citrix Single Sign-on and the Secure Gateway in a single-hop

configuration to enable single sign-on and SSL/TLS encryption between a secure Internet

gateway server and an SSL-enabled plug-in. Encrypted communication between the Web

browser and the Web server is via HTTPS. ICA traffic within the internal network is secured

using IPSec.

See the Citrix Single Sign-on documentation for further information about the Citrix Single

Sign-on components in this deployment.

This diagram shows sample deployment E, which uses Citrix Single Sign-on and the Secure

Gateway.

Note: The Citrix Single Sign-on central store is hosted on two servers (primary and

secondary), both running Active Directory. The secondary server is only used to provide

failover for the primary server.



http://support.citrix.com/proddocs/index.jsp?lang=en&topic=/passwordmanager-5-0/pm-landing-page-version-50.html


49/53

XenApp farm XenApp 6.5 for Microsoft Windows

Server 2008

SSL Relay not enabled


on XenApp server

Citrix Single Sign-on 5.0 plug-in


Java 1.4.xor later

Citrix SingleSign-onService

Citrix Single Sign-on 5.0 Service Windows Server 2008 R2

Windows Server 2008 (32-bit)


Pack 2 (32-bit)

Windows Server 2003 R2 (32-bit)

.NET Framework 3.5 Service Pack1

Citrix SingleSign-on centralstore

Citrix Single Sign-on 5.0 central

store


Windows Server 2008


Pack 2

Web server Web Interface 5.4 for InternetInformation Services


Windows Server 2008

Windows Server 2003 with ServicePack 2


6.0 only)


Secure

Gatewayserver


Windows Server 2008


Pack 2User devices Citrix Receiver for Windows 3.0


Windows 7

Windows Vista


Sample E Using Citrix Single Sign-on and Secure Gateway (Single-Hop)

49


50/53

50


Deployment E Interact


this, deploy SSL/TLS-enabled plug-ins and configure the Secure Gateway at the network

perimeter, typically in a demilitarized zone (DMZ).

Secure the connections between users Web browsers and the Web Interface using HTTPS.

Additionally, use TLS to secure communication between the Web Interface and the XenApp

server farm, and between the farm and the Citrix Single Sign-on central store and Single

Sign-on service. Secure the communication between the Secure Gateway and the server

farm using IPSec.

In this deployment, the Secure Gateway removes the need to publish the address of everyXenApp server in the farm and provides a single point of encryption and access to the farm.




Sample deployment E is highly scalable. ICA communication is encrypted between client

devices and Secure Gateway, as well as between the Secure Gateway and the XenApp

servers.

This diagram shows a detailed view of sample deployment E.


51/53

How the Components in Sample Deployment E Interact

51


52/53

52

Security Considerations for Deployment

Sample E

IPSec in Sample Deployment ETo enable IPSec to secure communication between Secure Gateway and the XenApp server

farm, you must configure IPSec on each server, including the Secure Gateway server.


sample deployment E, IPSec is enabled on the requisite servers and the security method is


FIPS 140 Validation in Sample Deployment EIn this deployment, the SSL Relay uses the Microsoft cryptographic service providers (CSPs)












SSL/TLS Support in Sample Deployment EIn this deployment, you can configure Secure Gateway and the Web Interface to use the

Transport Layer Security 1.0 protocol.

Supported Ciphersuites for Sample Deployment EIn this deployment, Secure Gateway and the Web Interface can be configured to use

government-approved cryptography, such as the ciphersuite





53/53

Certificates and Certificate Authorities in SampleDeployment E


infrastructure. In sample deployment E, one server certificate is configured on Secure

Gateway and one on the Web Interface. A certificate is also configured on each XenApp

server and on the server running the Password Manager service. A root certificate is

required for each client device. For information on the root certificate source for your

client devices, see Citrix Receiver and Plug-ins.

Smart Card Support in Sample Deployment EIn this deployment, you can configure XenApp to provide smart card authentication. To do



Plug-ins Used in Sample Deployment EIn this deployment, users access their applications using Citrix Receiver. For more



Security Considerations for Deployment Sample E

en.xenapp.ps sec node wrapper xa65

Documents