CESG IPSEC Guides (2013) & Juniper Appliances

cesg

About CESG

CESG protects the vital interests of the UK by providing policy and assistance on the security of communications and electronic data, working in partnership with industry and academia.

CESG IPSEC GUIDES

CESG have produced some guidance for IPSEC VPN’s – guidance adhered to by government departments & associated bodies.

  • Version2.1 CESG IPSEC Security Gateway Guide can be found on the CESG site
  • Version 2.3 CESG IPSEC VPN FOR REMOTE WORKING – SOFTWARE CLIENT Guide can be found on the CESG site

Juniper MAG Devices with Juniper Pulse Secure Access Service

The Juniper Pulse Secure Access Service running version 7.4+ software on a Juniper MAG device can be used for CESG IPSEC VPNs which supports ECDHE Ciphers & IKEv2

A caveat is that MAG devices don’t support FIPS level 3 compliant cryptographic modules – but FIPS is not referenced directly in the guide.

ECDHE Ciphers supported by SA

With Elliptic-Curve Cryptography (ECC) certificates:

TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384
TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256
TLS_ECDHE_ECDSA_WITH_RC4_128_SHA

With RSA Certificates:

TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
TLS_ECDHE_RSA_WITH_RC4_128_SHA
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256

IKEv2 Clients

Any IKEv2 Client can be used for CESG IPSEC eg:

About IKEv2

CESG IPSEC refers to use of IKEv2. More information can be found on the Juniper Website. Also please note the following:

  • On the Juniper SA/MAG Device – IKEv2 does not support automatic cluster failover. After cluster failover, IKEv2 users must reconnect to Secure Access Service.
  • On the Juniper SA/MAG Device -IKEv2 uses UDP port 500 with Juniper Pulse Secure Access Service.

Notes about use with Certificates

For IKEv2 with client certification authentication to work with Windows 7 IKEv2 client, the certificate imported in to Secure Access Service must have the enhanced key usage (EKU) value set to serverAuth(1.3.6.1.5.5.7.3.1)

Also ECC certificates are currently only supported on MAG and Virtual Appliance platforms, they are not usable on SAx500 devices.  See Chapter 32, Elliptic Curve Cryptography, in the 7.4 or later Admin Guide for more details on these certificates and setting custom cipher options.

FIPS level 1 Supported Platforms

  • The following platforms support FIPS level 1:
    • Junos Pulse Gateway MAG2600
    • Junos Pulse Gateway MAG4610
    • Junos Pulse Gateway MAG6610
    • Junos Pulse Gateway MAG6611
    • Junos Pulse Gateway MAG-SM160
    • Junos Pulse Gateway MAG-SM360
    • Secure Access Service and Access Control Service virtual appliances

More info here

FIPS  Level 3 Supported Platforms

  • Juniper SA4500 FIPS
  • Juniper SA6500 FIPS
Note
  • FIPS Level 3 refers to a Cryptographic Hardware Security Module
  • You cannot run FIPS level 1 support on a hardware FIPS platform such as the SA4500/6500 FIPS SSL VPN Appliance
  • SA4500/6500 FIPS SSL VPN Appliances do not support newer ECC certificates.

The last point leaves a conundrum – go with MAG and have a higher encrypted channel across the Internet or go with SA and have a weaker encrypted channel & a higher protected stored private key.

 

Template: RSA Authentication Manager 6.1 to 8.1 Consultancy

RSA Token

Scope of Work

4 Days RSA Authentication Manager Consultancy – Migration from version 6 to version 7.1 Appliance

Day 3 may require out of hours – so might be a Thur/Fri/Sat/Mon

  • Installation of Primary RSA Authentication Manager version 8.1 Appliance
  • Installation of Replica RSA Authentication Manager version 8.1 Appliance
  • Integrate RSA with Active Directory
    • Migrate Data from existing 6.1 Software to new version 8.1 Appliance
    • Confirm migration by testing access
    • Complete any other configuration changes for new system (based on similar features that were used in version 6 – Admin Roles etc)
    • Document the build of the solution
    • Provide Basic skills transfer

Caveats

Suggested Timeline

  1. Day 1 –
    1. Initial build of Primary & Replica RSA version 8.1 server – no configuration
    2. Start Build Documentation
    3. Configuration of Primary RSA version 8.1 Appliance with integration to Active Directory
    4. Continue Build Documentation – AD Integration
    5. Test Migration
    6. Day 2 –
      1. Configure Replication between RSA version 8.1 Servers
      2. Basic Skills Transfer to admin staff
      3. Continue Build Documentation – RSA Replica Integration
    7. Day 3 –
      1. Migrate Primary RSA – from version 6.1 to version 8.1
      2. Test
      3. Migrate Replica RSA – from version 6.1 to version 8.1
      4. Test
    8. Day 4 –
      1. Complete any other configuration changes for new system – Role Based Admin setup etc
      2. Finalize Build Documentation
      3. Final Skills Transfer

RSA Installation

  1. RSA version 8.1 will be installed on to new IP addresses initially and then changed to existing version 6 IP addresses once version 6 is powered off. Hostnames will remain unchanged.
  2. Customer to supply RSA version 8.1 Appliances, Tokens, token seed Files & licenses
  3. License file may need to be downloaded from RSA Download Central at https://download.rsasecurity.com if not already obtained
  4. Use the credentials and the license serial number that RSA e-mailed to you to log on to the site and download the license file. If you did not receive an e-mail with the logon credentials, contact the Exceptions Desk by sending an e-mail with your contact information and license serial number (provided in your order confirmation) to support@rsa.com
  5. The location of the license file is needed before running the appliance Quick Setup Process
  6. The License File must support the number of tokens & users with fixed passwords added/migrated to the system
  7. The network information for each appliance must be provided: the fully qualified domain name (FQDN), static IP address, subnet mask, default gateway, and DNS server IP addresses
  8. RSA Servers will need fully qualified Hostnames configured in DNS
  9. RSA servers will need to be synced to an NTP time source
  10. Any Firewalls must be configured to allow all RSA & other components to communicate with one another
  11. It is recommended that a test Agent is installed to Windows PC to test Authentication of system prior to migration of 6.1 Data
  12. Initial RSA Admin Password used on system to be specified by customer –Password provided will be used in super, operations console, radius & master password unless otherwise specified. If this needs to be changed at a later date – procedures are within the documentation.

Third Party Product integration

  1. Any Integration with 3rd party products will be configured based on supported configuration as determined by documentation at https://www.rsasecured.com
  2. With regard to above – existing products should migrate across to new system without any changes on existing systems – above procedures will only be applied where migration of a particular agent has not successfully migrated – yet all other agents have. In the case where no of agents migrate – system will be reverted back to existing version 6.1
  3. Customer is responsible for 3rd party products and other components.
  4. LDAP configuration details will be required to configure integration with Active Directory – a System Admin Account must be provided for communication.
  5. Current Active directory support is for Microsoft Active Directory 2008 R2
  6. As RSA servers will retain IP addresses of existing units – ARP tables may need to be cleared of surrounding equipment (if this doesn’t happen automatically) so that traffic can be redirected to new MAC addresses of new servers.

Migration of 6.1 Data

  1. Full connectivity to 6.1 Installed RSA systems (RDP or direct connection)
  2. Downtime to stop Primary RSA 6.1 Server to take database dump files
  3. 2 migrations to be performed –
    1. initial test migration on day 1 with dumped data taken from live 6.1 RSA primary server and imported to check for any issues with import. A Report can also be run that highlights any potential issues with migration – system will be reverted after this migration to a clean VMware snapshot to continue with build of server ready for final migration
    2. final migration – downtime needed of RSA 6.1 Primary Server after this stage initiated
    3. Once 6.1 primary server is stopped and data copied off during final migration – 6.1 server will be powered off. Version 8.1 Primary server will have IP Address changed to that of existing system.
    4. Ability to copy dump files & other required files between 6.1 & 8.1
    5. Migration of data is assumed to be migration of agents, user accounts, tokens, PINS and associated user data only – other configuration may require manual setup post migration.
    6. Confirmed testing to new version 8 server – will confirm successful migration of data and continuation of below steps.
    7. Downtime to stop Replica RSA 6.1 Server to take database dump delta records
    8. Once 6.1 primary server is stopped and data copied off – 6.1 server will be powered off. Version 8.1 Replica server will have IP Address changed to that of existing system.
    9. Ability to copy dump files & other required files between 6.1 & 8.1
    10. Confirmed testing to new version 8.1 replica server – will confirm successful migration of data

Outside Scope

  1. Self-Service Console is assumed to be for admin use only.
  2. On Demand Authentication is outside of scope
  3. Provisioning component of Self service is outside of scope
  4. Trusted Realm Deployments are outside of scope
  5. Any other RSA consultancy requirements and RSA features not discussed in scope of work & caveats are outside agreed scope of consultancy.

Documentation

  1. Documentation of build of system will be provided- other documentation is outside of scope

Skills Transfer

  1. Basic Skills transfer will be given as time allows to admin staff using system after initial build and prior to migration.
  2. Another basic skills transfer can be given post migration to admin staff using system
  3. Skills transfer will cover basic admin tasks and how system built.

 

 

 

Template: RSA Authentication Manager 7.1 to 8.1 Consultancy

RSA Token

Consultancy

2 Days RSA Authentication Manager Consultancy – Migration from version 7.1 to version 8.1

 Scope of Work

Installation of Primary RSA Authentication Manager version 8.1 Appliance on to an ESXi 4.x/5.x Environment

  • Installation of Replica RSA Authentication Manager version 8.1 Appliance on to an ESXi 4.x/5.x Environment
  • Integrate RSA with Active Directory
  • Integrate with Juniper SSL VPN Appliance
  • Integrate with VMware View
  • Migrate Data from existing 7.1 Primary Appliance to new version 8.1
  • Confirm migration by testing access
  • Provide skills transfer
 Timeline
  • Day 1 –
  1. Initial build of Primary & Replica RSA version 8 servers on VMWare
  2. Configure Replication between RSA version 8 Servers
  3. Integration to Active Directory
  4. Admin Console Configuration
  5. Basic Skills Transfer to admin staff
  • Day 2 –
  1. Migrate Primary RSA – from version 7.1 to version 8.1
  2. Change IP Addresses on Virtual Appliances
  3. Test Authentication through Juniper SSL VPN
  4. Test Authentication through VMware View
  5. Basic Skills Transfer to operations staff
 Caveats
 VMWare ESXi Requirements
  • Full access to VMware Vsphere client to access suitable ESXi 4.x/5.x host or VCenter Server Consoles in order to install setup RSA OVA File.
  • Installation of Primary RSA Authentication Manager version 8.1 already installed  by customer onto an ESXi 4.x/5.x Environment
  • Installation of Replica RSA Authentication Manager version 8.1 already installed  by customer onto an ESXi 4.x/5.x Environment
  • ESXi host to meet minimum requirements: 100 GB (Thick-provisioned storage when deploying the virtual appliance), 4 GB of memory (preferably 8GB RAM), At least one virtual CPU. Note: By default, each Authentication Manager instance is deployed with 8 GB of memory and two virtual CPUs.
  • Customer is responsible for VMware host environment and any tasks related to changes on VMware.
  • The virtual appliance only supports the E1000 virtual network adapter. Do not change the default network adapter or add a new virtual network adapter to the virtual appliance.
  • For additional hardware requirements for the physical server hosting the virtual appliances, see your VMware documentation.
  • VMware snapshots may be required at various stages in deployment – adequate disk space must be available to do this.
RSA Installation
  • Current Version must be RSA 7.1 SP4
  • Customer to supply RSA version 8.1 Software, Tokens, token seed Files & licenses
  • License file may need to be downloaded from RSA Download Central at https://download.rsasecurity.com if not already obtained
  • Use the credentials and the license serial number that RSA e-mailed to you to log on to the site and download the license file. If you did not receive an e-mail with the logon credentials, contact the RSA Exceptions (support) Desk by sending an e-mail with your contact information and license serial number (provided in your order confirmation) to support@rsa.com or contacting 01344 781100
  • Further details on the process are available in a 5 min youtube video here: http://www.youtube.com/watch?v=5e9tawZ8JfU
  • The location of the license file before running the appliance Quick Setup Process
  • The network information for each appliance must be provided: the fully qualified domain name (FQDN), static IP address, subnet mask, default gateway, and DNS server IP addresses
  • RSA Servers will need fully qualified Hostnames configured in DNS (forward & reverse lookups)
  • RSA servers will need to be synced to an NTP time source – it is assumed that this is the same time source as previous installation – differences in time can impact user authentications
  • Any Firewalls must be configured to allow all RSA & other components to communicate with one another
    • TCP 7004 & 7072 Ports required for Administration Consoles – these must be allowed through Firewalls from wherever administration performed on network
    • TCP 7002, 1812 & 1813 Ports are required for Replication  – these must be allowed through Firewalls for replication to work
  • A test Agent can be installed to Windows PC to test Authentication of system prior to migration of 7.1 Data if required – the agent is freely downloaded from the RSA website here: http://uk.emc.com/security/rsa-securid/rsa-authentication-agents/windows.htm
Third Party Product integration
  • Integration with Juniper SSL VPN will be configured based on supported configuration as determined by documentation at https://www.rsasecured.com
  • The versions of third party agents are assumed to be versions listed in the guides on the https://www.rsasecured.com site.
  • Number of 3rd party product testing post migration will be as time allows – unless exact number is determined before consultancy.
  • Customer is responsible for any integrated 3rd party products.
  • LDAP configuration details will be required to configure integration with Active Directory – a System Admin Account must be provided for communication.
  • Current Active directory support is for Microsoft Active Directory 2008 R2 (other versions may work but will be unsupported by RSA)
Migration of 7.1 Data
  • Full connectivity to 7.1 Installed RSA systems via Web pages & SSH/SCP client
  • Downtime to stop each RSA 7.1 Server to take database dump files
    • Migrating Log data is optional
    • Migrating replica Server data is optional
  • Ability to copy dump files & other required files between 7.1 & 8.1
  • A Secure Copy Protocol (SCP) client (eg WinSCP) will be needed to copy 8.1 migration Export Utility & Files to/from the RSA Appliance – SSH port must be open between PC & RSA Appliance through any firewalls. WinSCP Client is a suggestion for the  client
  • Migration of data is assumed to be migration of agents, user accounts, tokens, PINS and associated user data only – other configuration may require manual setup post migration.
  • Usernames used in 7.1 environment must match those in Active Directory in order for migration to succeed to 8.1
  • The following passwords will be needed from 7.1 environment: master password, Operations Console password (& User Account), Superdamin password (& User Account)
  • If the 7.1 installation is an appliance: The following passwords will also be needed: emcsrv user password, root password, rsaadmin password – normally the password for these is identical.
Juniper SSL & VMware View integration
Post Implementation
  • Basic Skills transfer as time allows to Admin staff
  • Basic Skills transfer as time allows to Admin staff
Outside Scope
  • New 8.1 Webtier components – for external published access to Self-Service Console, use of Risk Based Authentication, Dynamic Seed Provisioning of Software Tokens
    • Self-Service Console can be used for internal use only – use by external user connections should be through the RSA web tier component – which is outside of scope.
    • Self service Token Provisioning component is outside of scope
  • Trusted Realm Deployments are outside of scope
  • Any other RSA consultancy requirements and RSA features not discussed in scope of work & caveats are outside agreed scope of consultancy.
  • Documentation is Outside of scope – Basic screenshots of installation process can be done as time allows if required