Security Considerations within the Corporate Network
The Windows Mobile security architecture provides components and tools that can utilize your existing corporate network infrastructure. You can build a security-enhanced communications environment using standard Internet protocols on any of a variety of network configurations, deploying firewalls and authentication protocols that fit your needs, whether your company is large or small.
Microsoft’s recommended network configuration places all Exchange servers within the corporate network; the Internet Security and Acceleration Server (ISA server) acts as the advanced firewall in the perimeter network that is exposed to Internet traffic. This helps provide an additional layer of protection to your network.
All incoming Internet traffic bound to your Exchange servers – for example, Microsoft Office Outlook Web Access (OWA) and remote procedure call (RPC) over HTTP communications from Microsoft Office Outlook 2003 clients – is processed through an ISA Web listener. When the ISA server receives a request from an Exchange server, the ISA server authenticates the connection and performs packet inspection to ensure that requests are real and then proxies the request to the appropriate Exchange servers on your internal network. The Exchange servers on your network then return the requested data to the ISA server, which sends the information to the client through the Internet.
During installation of the ISA server, Microsoft strongly recommends that you enable Secure Sockets Layer (SSL) encryption, and designate 443 as the SSL port. This leaves the 443 port open as the “Web listener” to receive Internet traffic. Microsoft also recommends that you set up basic authentication for Exchange ActiveSync, and that you require all clients to successfully negotiate an SSL link before connecting to Exchange ActiveSync site directories. If you follow these recommendations, the Internet traffic that flows into and out of the 443 port will be more protected.
When configured in Web-publishing mode, ISA Server 2006 will provide protocol filtering and hygiene, denial of service (DoS) and distributed denial of service (DDoS) protection, as well as pre-authentication.
The following illustration shows the recommended Exchange Server 2003 or 2007 deployment for mobile messaging with ISA Server 2004 or 2006.
For more information on alternative network configurations, see Step-by-Step Guide to Deploying Windows Mobile-based Devices with Microsoft Exchange Server 2003 SP2 at this location: http://go.microsoft.com/fwlink/?LinkId=81200
The Internet Security and Acceleration Server product family is Microsoft’s line of enterprise-grade firewalls. ISA Server provides edge network filtering and adds protection along with full compatibility with the complete set of Microsoft server products, including Exchange Server, SharePoint, and Windows Server. In mobile messaging deployments, ISA Server offers some specific benefits that make it a good fit for Windows Mobile and Exchange Server:
ISA Server helps protect against most unauthenticated denial-of-service attacks, safeguarding Outlook Web Access and Exchange ActiveSync servers from attack and intrusion
ISA Server 2004 can act as an endpoint to decrypt and inspect inbound traffic, passing only legitimate traffic to the destination endpoint. This capability, known as SSL bridging, adds valuable extra protection to OWA and Exchange ActiveSync deployments.
ISA Server 2006 adds a new feature that terminates the SSL connection from the mobile device at the ISA server and allows the mobile device to authenticate a client connection, using Kerberos-constrained delegation to the Exchange server. This feature helps provide extra protection because traffic is inspected at ISA Server and then passed to the Exchange server for processing.
ISA Server can pre-authenticate users of Web-based applications (including OWA) to ensure that unauthenticated users never make any kind of connection to the application server.
ISA Server includes easy-to-use wizards that allow administrators to easily publish access to select Exchange services, SharePoint servers, or other Web-based applications. The wizards ease the process of publishing these services, while at the same time reducing the chances of making a configuration mistake that might introduce vulnerability.
ISA Server works with familiar management tools like Microsoft Operations Manager, and it can be run on a Windows server or on appliances available from a variety of vendors.
Because of these benefits, many Windows Mobile customers choose to deploy ISA Server as their primary network firewall. However, it is important to note that ISA Server is not required to help securely deploy Windows Mobile powered devices. Any firewall that can pass HTTPS (TCP port 443) traffic from the firewall to the Exchange server can be used to help protect Exchange ActiveSync traffic.
The Secure Sockets Layer (SSL) protocol is a time-tested and mature security protocol that is widely used to help safeguard Internet communications against tampering and interception. The SSL protocol allows two endpoints to establish a connection with confidentiality (provided by encryption) and integrity protection (provided by digital signatures and the optional use of mutual client-server authentication). SSL must be applied to a communications protocol; for example, an SSL-protected Hypertext Transfer Protocol (HTTP) connection can be used to help secure communications between a user’s Web browser and a server on the Internet. This combination, known as HTTPS, is the primary security mechanism used to provide browser-based access to Web sites, including major banks, credit card companies, e-commerce sites, and a wide range of other services. However, SSL can also be used with other communications protocols, including SMTP, the Session Initiation Protocol (SIP) used by Microsoft Live Communications Server, and application-specific protocols.
In the Windows Mobile security architecture, SSL plays an important role in helping to shield device communications. The default method for establishing Exchange ActiveSync connections requires the use of SSL to encrypt the connection between the mobile device and the Exchange server. Because Exchange ActiveSync uses HTTP as its base communications method, this helps provide effective protection — as evidenced by the wide use of HTTPS to protect billions of high-value commercial transactions across the Internet — while requiring only one port to be opened on the enterprise firewall. Windows Mobile fully supports ordinary HTTPS connections, both through its application programming interfaces (APIs) and in the mobile version of Internet Explorer. This support is designed to allow line-of-business applications and user browsing to be protected using the same robust security mechanism as Exchange ActiveSync traffic.
SSL includes a method for a client and server to negotiate an encryption algorithm and strength; this is designed to allow an arbitrary client-server pair to find the strongest encryption that both endpoints support. Both Windows Mobile and the Windows Server Internet Information Services (IIS) application server can take advantage of a broad set of cryptographic algorithms for use with SSL. In Windows Mobile 6, this includes support for AES which is available for SSL channel encryption in 128- and 256-bit cipher strengths. You can gain additional protection by enabling the use of only FIPS 140-2 compliant algorithms with SSL.
|At present, AES cannot be used with Exchange ActiveSync because EAS is built on IIS which does not currently support AES.|
For more information about SSL on Windows Mobile powered devices, see Secure Sockets Layer (SSL) support in Security on the Device.
For more information, see Cryptographic Services and FIPS Compliance in Security Model for Windows Mobile 5.0 and Windows Mobile 6.
Using Firewalls: Exchange Server Minimizes the Need for Open Ports
From a security standpoint, one of the biggest advantages of using Exchange ActiveSync and Windows Mobile is the fact that all communications between the device and the Exchange server take place over a single TCP/IP port: TCP port 443, used for SSL-secured HTTP traffic. The following figure shows a typical configuration with the open ports and idle session time. This greatly simplifies enterprise firewall configuration, because only a single port needs to be opened from the Internet to the Exchange ActiveSync server, and that port will probably be open in any case because it’s the same port used for OWA.
Direct Push Firewall Timeouts and DoS threats to the Corporate Network
When using Direct Push Technology, the firewall session interval on the corporate network must be set to 30 minutes to allow the mobile device and the Exchange Server to communicate freely. If the firewall closes the session prematurely, mail would be undeliverable until the client reconnects, and the user could be unsynchronized for long periods of time. Setting the firewall session timeout equal to or greater than the idle timeout on the mobile operator's network ensures that the firewall will not close the session.
Firewall idle connection timeouts:
Operators need to set the idle connection timeouts on outgoing firewalls to 30 minutes.
Enterprises also need to set timeouts on their incoming firewalls to 30 minutes.
Web servers, network security appliances, and system network stacks have several time-based thresholds that are intended to insulate them from insufficiently tested or malicious clients. You should be able to increase the idle connection timeout setting without compromising the degree of security established on the network.
Increasing the idle connection timeout typically does not increase or decrease exposure to attacks. The following table shows examples of unauthenticated attacks and describes how other settings are used to mitigation exposure to them.
|DoS Threat||Mitigation of exposure to attacks|
A DoS attack is launched by failing to complete the handshake that is implicit in the creation of a TCP connection. The attacker attempts to create a large number of partially open TCP connections.
Increasing the idle connection timeouts is unrelated to this type of attack.
The time within which a TCP handshake must complete is a separate threshold that is governed by the Windows TCP/IP stack.
A DoS attack is launched against IIS by opening a large number of TCP connections but never issuing an HTTP request over any of them.
Increasing idle connection timeouts is unrelated to this type of attack.
IIS mitigates this threat by requiring that a client submit a fully formed HTTP request within a certain time before dropping the connection. The name of the Connection Timeout setting in the IIS management console is misleading; TCP connections are closed when the Connection Timeout value is exceeded. The default is 120 seconds.
An attacker establishes a large number of TCP connections, issues HTTP requests over all of them, but never consumes the responses.
Increasing idle connection timeouts is unrelated to this type of attack.
This threat is mitigated by the same timeout as the previous scenario. The Connection Timeout setting in IIS defines the time within which a client must issue either its first request after a TCP connection is established or a subsequent request in an HTTP keep-alive scenario.
For detailed information about the Direct Push Technology, see Mobile Operator Guide to Messaging and Security Feature Pack for Windows Mobile 5.0-based Devices, at http://go.microsoft.com/fwlink/?LinkId=83456.
Strong authentication not only helps protect the mobile device and the information stored on it, but it also helps safeguard network access credentials and methods the device may use to access corporate resources. Using the certificate management configuration service providers and the certificate management tools provided by Microsoft, you can select an authentication method that fits your corporate network configuration and security requirements.
Basic Authentication on the Exchange Server
Exchange 2003 and Exchange 2007 include Exchange ActiveSync, which relies on SSL to help secure the connection between the Windows Mobile powered device and the Exchange front-end or client access server. The client device provides the domain user’s credentials using the SSL basic authentication method. This authenticates the client to the server. The device must have the root certificate of the Exchange front-end or client access server in order to establish a connection.
Windows Mobile powered devices are shipped with a set of third-party trusted root and intermediate certificates. If you use one of these trusted certificates to help secure your Exchange Server, these devices will be able to access your corporate network by entering their domain, name, and password.
Windows Mobile 5.0 with MSFP and later devices can use SSL with Transport Layer Security (TLS) client authentication in place of SSL basic authentication. Certificate-based authentication offers a significant security advantage over the use of basic authentication. This advantage comes from two factors. First, the strength of the key is pre-determined by the administrator and can be very strong. Windows Mobile and Windows Server together support up to 2,048-bit keys. Second, requiring certificate-based authentication greatly reduces the risk that a user’s credentials will be compromised. If a user shares the password, the authentication process helps prevent an attacker from recovering usable credentials. The credentials are hashed and protected by SSL encryption during transport.
To use certificate-based authentication with Windows Mobile, the mobile device must contain the root certificate for the Exchange front-end or client access server it is communicating with; the mobile device must also have its own client user certificate with the associated private key. The user certificate enrollment process can only occur when the device is connected to a desktop in the same domain as the enrollment web site.
Certificate-based Authentication for Windows Mobile 5.0
The certificate enrollment process for Windows Mobile 5.0 MSFP devices uses ActiveSync desktop to connect to the corporate CA to receive the required user certificate and associated key. Once the user certificate and key are on the device, cradling with Desktop ActiveSync 4.1 or later is required only to renew the certificate when it expires.
Microsoft has created a tool for deploying Exchange ActiveSync certificate-based authentication; it can be downloaded from the following Microsoft Download center Web site. http://go.microsoft.com/fwlink/?LinkId=54738.
For an overview of setting up certificate-based authentication for use with Windows Mobile and Exchange ActiveSync, see Appendix A, Overview of Deploying Exchange ActiveSync with Certificate-Based Authentication, of the Step-by-Step Guide to Deploying Windows Mobile-based Devices with Microsoft Exchange Server 2003 SP2, available at http://go.microsoft.com/fwlink/?LinkID=81200.
Certificate-based Authentication for Windows Mobile 6
With Windows Mobile 6, the process for implementing Transport Layer Security (TLS) certificate-based authentication has been streamlined and made easier to maintain. The system administrator creates a certificate type and makes it available through Active Directory. The user then authenticates to the network, navigates to the designated location, and the client user certificate with the associated encrypted private key is passed to the user’s device.
|Wildcard certificates or certificates not supplied by a Microsoft Certificate Authority Server can be used with Windows Mobile powered devices that run Windows Mobile 6.|
For more information about using Desktop ActiveSync to set up certificate-based authentication on your network, see Adding Certificates to Windows Mobile Powered Devices running Windows Mobile 6 in Certificates for Windows Mobile 5.0 and Windows Mobile 6.
Enabling RSA SecurID Authentication
If you have an RSA SecurID infrastructure, you can use SecurID with your organization’s Windows Mobile powered devices and Exchange ActiveSync to gain the security benefits of two-factor authentication with direct push. To do this, you must install RSA’s ACE/Agent on the front-end Exchange server, and then configure it to help protect the Exchange ActiveSync virtual directory. The detailed steps for doing so are outside the scope of this paper; for complete details on how to configure SecurID, please see the section titled “How to Use RSA SecurID with Exchange ActiveSync” in the Exchange Server Client Access Guide at the following Microsoft Web site: http://technet.microsoft.com/en-us/library/cfecf499-32a9-4b9a-9d2a-88e393be0bd2.aspx.
Digital certificates afford a powerful tool in establishing device and user identities for authentication. In a corporate environment, securely distributing and renewing digital certificates on hundreds of mobile devices can be a daunting task. With Windows Mobile 6 and desktop ActiveSync, the management of device certificates has been simplified. The certificate enrollment tools enable the system administrator to manage device certificates to help create a more secure environment.
You can use Windows Mobile 6 and ActiveSync certificate enrollment tools for the following company-wide activities:
Deploying enterprise-wide Exchange ActiveSync or SSL TLS certificate-based authentication
Renewing existing certificates
Distributing 802.1x wireless certificates
Providing certificates for S/MIME digital signing
The process for adding certificates differs between Windows Mobile 5.0 and Windows Mobile 6.
Adding Certificates to Windows Mobile Powered Devices Running Windows Mobile 5.0
Network managers and device users can place additional certificates on devices if they have either Manager role permission on the device or have the ability to run trusted code. Another option is to contact your OEM or Mobile Operator for a signed certificate installation tool such as SPADDCERT.exe.
Confer with your device vendor or mobile operator to ensure that the devices you intend to purchase will either work with the certificates you currently have deployed, that you can add the necessary certificates, or that you can replace your certificates in a cost-effective fashion.
If you wish to install root certificates for certificate-based authentication, you can use the tool for deploying Exchange ActiveSync certificate-based authentication; it can be downloaded from the following Microsoft Download center Web site. http://go.microsoft.com/fwlink/?LinkId=54738.
For more information, see the Microsoft Knowledge Base article, How to install root certificates on a Windows Mobile-based device available at the following Microsoft Web site: http://support.microsoft.com/kb/915840.
Adding Certificates to Windows Mobile Powered Devices Running Windows Mobile 6
With Windows Mobile 6-powered devices, you can distribute the encrypted certificate/key pair required for certificate-based authentication or 802.1x wireless connection using Exchange ActiveSync Desktop enroll.
|Anyone with User role permissions can install a certificate on a Windows Mobile 6 device by copying the .cer file to the device and running it. However, in order to enroll for a certificate from a Certificate Authority (CA), your device users should use Desktop ActiveSync.|
Desktop ActiveSync enables device users to enroll for a certificate from the corporate server to their cradled Windows Mobile-powered device. Your users connect to your network using the existing corporate desktop logon procedure -- password, smartcard, or other means of user identification. The two levels of authentication control the certificate enrollment, streamlining the distribution of the certificates.
Desktop certificate enrollment can be used to query for and to renew certificates on mobile devices. You can also use the CertificateEnroller Configuration Service Provider to define certificate types and to create the provisioning XML that can be pushed to the mobile devices.
For more information on provisioning or configuring mobile devices, see Security Model for Windows Mobile 5.0 and Windows Mobile 6.
Desktop Certificate Enrollment Process
To prepare for using desktop certificate enrollment, the system administrator should do the following:
Set up or have access to a Windows 2000, 2003 or later Windows Certificate Server.
Create the certificate type or use an existing certificate published to Active Directory.
Inform users of the name and type of the certificate they should select.
Provide users with instructions for using the Get Device Certificate user interface.
Once the system administrator has published the certificate to Active Directory and directed the users to enroll for the certificate, the users will step through the following process:To enroll for a certificate with a Windows Mobile powered devices that run Windows Mobile 6
From Advanced Tools, the user chooses Get Device Certificate, navigates to Active Directory on the corporate network, selects the desired certificate, and clicks Add.
The desktop processes the enrollment while the user waits a short period of time. During this time, the device generates a public/private key set and proxies the enrollment to the Windows Certificate Server through the desktop.
The CA returns a signed certificate to the desktop which, in turn, delivers the certificate to the device.
The device stores the certificate and its chain of certificates to the root CA. If the root certificate is not already in the root certificate store of the device, the user is asked to accept the certificate.
The user sees a success dialog to denote the end of the enrollment process.
Once the certificate is in the user Root or CA store, the mobile device will be ready to authenticate with the desired protocol.
Mobile device users want to have the same rich feature set they have when using Outlook or OWA with their Exchange accounts. Using Exchange ActiveSync with Windows Mobile 5.0 with MSFP and later devices, mobile users can synchronize their devices with their Exchange mailbox; their communications are designed to be protected by SSL and the other security measures described in this paper. However, these solutions don’t protect the message once it reaches the Exchange server or the mobile device. You can help increase e-mail security by using Information Rights Management (IRM) or Secure / Multipurpose Internet Mail Extensions (S/MIME).
Support for Information Rights Management
Applies to Windows Mobile 6:
If your company is using Information Rights Management, your employees will have the same support extended to their mobile messaging experience. Windows Mobile powered devices that run Windows Mobile 6 support replying to, forwarding, and composing IRM-protected e-mail. IRM is a persistent file-level technology from Microsoft that allows the user to specify permission for who can access and use documents or e-mail messages, and it helps to prevent sensitive information from being printed, forwarded, or copied by unauthorized individuals
IRM protection is imposed on the e-mail or document itself – messages are IRM-protected before they leave a client's Outlook session and remain IRM-protected when stored on the Exchange server. IRM Client DLLs on the Windows Mobile powered device that runs Windows Mobile 6 communicate directly with the rights-management server to get user-specific licenses for accessing content and handle encryption and decryption of communications between client and server.
The IRM client on Windows Mobile 6 supports the following:
Complete support for IRM protected e-mail communications including
Downloading and decrypting messages and attachments
Forwarding and replying to messages while preserving the rights restrictions
Composing new “Do Not Forward” IRM protected messages
Support for reading and editing Microsoft Office Word, Excel and PowerPoint documents.
The following components are required for implementing IRM in your corporate environment:
Windows Mobile powered devices that run Windows Mobile 6
Desktop Outlook 2003 or later
Exchange Server 2003 or 2007
Windows Rights Management Server SP1 for Windows Server System 2003
Using S/MIME with Windows Mobile Powered Devices
Windows Mobile powered devices that run Windows Mobile 5.0 devices with MSFP and Windows Mobile powered devices that run Windows Mobile 6 support sending and receiving S/MIME messages. The S/MIME standard defines a format for message security that allows e-mail users to exchange signed and/or encrypted e-mail. Signed e-mail enables the recipient to confirm that a message really came from the sender and was not tampered with en route. Encryption helps maintain the confidentiality of e-mail messages at rest and in transit. In an organization where user certificates are stored on smartcards, Windows Mobile can use those certificates to read and send S/MIME messages.
|Windows Mobile powered devices that run Windows Mobile 5.0 devices with MSFP supports only physically separated Common Access Card (CAC)/smart card implementations. Windows Mobile powered devices that run Windows Mobile 6 support both smart card and soft certificate implementations by using PFX Import.|
Exchange 2003 SP2 provides support for S/MIME messages through Exchange ActiveSync. If your organization does not have S/MIME deployed with Exchange Server 2003 SP2, you can get more information in the Exchange Server Message Security Guide, available from http://go.microsoft.com/fwlink/?LinkId=34666.