Deploying a Secure Network Access Infrastructure Part 2

1
Deploying a Secure Network Access Infrastructure
Part 2 Romano JerezSupport ProfessionalDirecto
ry ServicesMicrosoft Corporation
2
Objectives

• Provide information about Microsoft Windows
  .NET networking components that you must consider
  when deploying a secure network access
  infrastructure

3
Agenda

• Technologies and key concepts
• Before you start
• Directory and authentication models
• Securing wireless and wired links
• Securing against rogue systems
• VPN deployment
• Updating proprietary VPN deployments

4
Technologies and ConceptsThe Parts

• Making correct choices
• Interactions
• Dependencies
• Architecture
• Security

Goals Transparency Minimize complexity
5
Technologies and ConceptsTrust and Authorization

• Authentication types and methods
• Single versus multifactor
• Passwords (shared secrets) versus tokens versus
  certificates versus biometrics (users)
• Secure deployment models required
• Minimize trust models (simplicity)

6
Technologies and Concepts (2)Trust and
Authorization

• Examples of supported trusts
• RADIUS computer trust with shared secrets only
• IPSec computer trust with single certificate,
  Kerberos ticket, and shared secret
• PPTP, Dial single method user trust
• L2TP single method user trust and IPSec trust
• 802.1x user trust or computer trust

7
Technologies and ConceptsUsing and Protecting
Shared Secrets

• Strong channels versus offline attacks
• CHAP models alone are not encrypted
• Need mutual authentication to be part of model
• MS-CHAP inside PEAP or L2TP/IPSec is protected
  and includes mutual authentication
• Distribution
• Users think of their own secrets
• UserID provides clue to secret
• Computers require transfer and protection
• WEP, IPSec no user hints for multiple secrets
  without compromising security
• Refreshing is difficult to manage

8
Technologies and ConceptsUsing Certificates for
Secure Network Infrastructure

• Secure deployment models defined
• Auto-enrollment
• PKCS
• Users versus computers
• Use if possible stronger storage models
• Smart cards versus user store on computer
• Conceptual contents
• Identity who the user/computer is
• Purpose what this certificate is good for
• Not all systems treat purpose the same
• Interoperability issues

9
Infrastructure TechnologiesStrong Authentication
Protocols

• Extensible Authentication Protocol (EAP)
• Generalized authentication framework protocol
• Carrier for one or more authentication methods
• Can establish session keys
• Driven by authentication method
• Transport Layer Security (TLS) services can
  encrypt channel
• Driven by authentication method
• Standard bindings for PPP and 802 (802.1x)
• Protected EAP (PEAP)
• EAP authentication method
• Tunnel for EAP method(s) after that
• Establishes protected channel and keying

10
Infrastructure TechnologiesLink and Network
Layer Security

• Secure wireless
• 802.11 encrypted (WEP) wireless link
• Weak preshared key authentication
• Weak encryption model because of keying and model
• 802.1x EAP authentication to solve weaknesses
• IP Security Protocol
• Network layer authentication, integrity,
  encryption
• Computer trust (certificates, preshared key)
• Encryption keys using Diffie-Hellman
• End-to-end transport mode
• Gateway-to-gateway tunnel mode

11
Infrastructure TechnologiesSecure Remote Access
(VPN) Protocols

• Point-to-Point Tunneling Protocol
• Link layer (PPPGRE) tunneled connection with
  authentication and encryption
• User trust (passwords, smart cards, and so on)
• Encryption keys partially from authentication
  credential
• Client-to-gateway and gateway-to-gateway
• Layer 2 Tunneling Protocol
• Link layer (PPP) tunneled connection with
  authentication
• User trust (passwords, smart cards, and so on)
• Relies on network layer wrapper (IPSec) for
  integrity and encryption
• IPSec delivers computer trust
• Client-to-gateway and gateway-to-gateway

12
Before You Start

• Must start with clean infrastructurein corporate
  network
• Well-managed DHCP scopes
• Functional DNS
• Clean routing infrastructure
• No address conflicts between connected networks

13
Directory and Authentication ModelSingle Forest
Domain
Access Point to Directory
Access Point to RADIUS

• Use when
• Gateways are not Windows-based
• There are many gateways
• Gateway has no integrated access policies

• Use when
• Gateways are Windows-based
• There are few gateways
• Gateway has integratedaccess policies (example
  RRAS withIAS engine)

14
Directory and Authentication ModelSecuring
RADIUS Authentication

• RADIUS is an encrypted channel
• Requires shared secret to access points
• Trust
• Keying
• Establish management model for updates
• RADIUS can be protected by IPSec
• Do this where possible
• Proxies
• RADIUS server to Active Directory
• RADIUS server to RRAS

15
Directory and Authentication ModelMultidomain
Single Forest
Cross domain trust
AD
AD
IAS
IAS can run on DC

• Conditions
• Two-way cross domain trust within single forest
• What to do
• IAS member of one of the domains
• Enable IAS member of IAS servers group
• Scale out as required by access points

16
Directory and Authentication ModelMultiforest
Domain
IAS
IAS
AD
AD
IAS Proxy
IAS can run on DC

• Conditions
• Multiple forests
• Want geographic failover
• Outsourced network access
• Very high scaledistributed RADIUS trust
  management
• What to do
• IAS member in each forest
• Enable IAS member of IAS servers group
• IAS proxy need not be domain member
• Scale out as required by access points

17
Directory and Authentication ModelSelecting
Authentication Methods

• VPN and dial
• EAP if possible
• Smart cards, user certificates, third-party
  plug-in
• MS-CHAP if passwords are required
• Wireless
• PEAP if possible (supports all methods)
• EAP if PEAP is not possible
• Computer versus user trust
• User if no computer trust or user policy is
  required
• Use same credential as VPN and dial

18
Securing Wireless/Wired Links

• Never use 802.11 without 802.1x and WEP
• Try to use 802.1x in new wired deployments
• No WEP here
• Use PEAP if passwordsare required

AD
IAS

• 802.11 AP
• 802.1x
• WEP

802.1x Switch
AP vendorsSupport RADIUS/IPSec and help improve
authentication channel securitySwitch vendors
move to 802.1x
User versus computer authentication Certificate
versus password credential
19
Securing Against Rogue SystemsEavesdropping /
Unauthorized Access

• Rogue issues not everything is 802.1x today
• Undetected clear wireless AP
• Rogue computer on non-802.1x port
• Solution 1 IPSec transport mode
• Pros
• Can block all nonsecured communication
• Strong integrity and encryption
• Simple credential model (Kerberos or auto-enroll)
• User transparency
• Cons
• Limited to IPSec-capable systems
• Domain trust work in multiforest deployments
• Policy requires careful thought
• No firewall inspection with ESP unless on end
  system

AP VendorsDeprecate non-802.1xAPs and help end
rogues
20
Securing Against Rogue Systems (2)Eavesdropping
/ Unauthorized Access

• Solution 2 Secure critical systems with VPN
• Put critical systems in network secured by
  RAS-VPN gateway (with optional firewall)
• Pros
• Broader end-system support
• Firewall inspection possible in secure server
  zone
• Strong integrity and encryption
• Simple credential model (Kerberos or auto-enroll)
• Cons
• Significant network re-architecture
• Scalability consideration for very large
  deployments
• Concurrent peer-to-peer and secure server access
• Less transparent to user
• Can integrate using WinLogin

21
VPN DeploymentDeployment Models

• Site-to-site
• Recommend L2TP/IPSec if using RRAS
• IPSec tunnel mode for IP-unicast only traffic
• Computer trust is enough
• RAS VPN (client to gateway)
• Internet connectivity architectures
• Authentication architectures
• Multihoming and scaling models
• Address management
• VPN protocol selection
• Certificate deployment
• Client deployment model
• Split tunnels or not
• Updating earlier VPN deployments

22
RAS VPN DeploymentInternet Connectivity
Architectures

• Internet firewall before VPN is unnecessary
• Requires firewall port opening plan

23
RAS VPN DeploymentAuthentication Architectures
?
?
?
?
?
Options RADIUS or Active Directory (if no
central policy is required)
?
Options Active Directory? (exposes domain in
DMZ), RADIUS, RADIUS with IPSec protection (if
gateway can do this)
24
RAS VPN DeploymentMultihoming and Scaling Models
Single Home Gateway
Connections and throughput function of egress
performance
Sessions for 10 percent of authorized RAS users
Offload NICs watch limits on concurrent SAs
25
RAS VPN DeploymentMultihoming and Scaling Models
Single Home Gateway
RRAS snap-in considerations for scale up
Consolidate back-side NICs (routing
considerations)
Scale up and out for server area/client area
network partitioning
26
RAS VPN DeploymentAddress Management
Architectures

• Private network DHCP assigned - Best
• Offers more than IP addresses
• Pooled addresses from gateway - Okay
• Static using Active Directory user properties
  - Avoid
• Static configured on client - Never
• Make sure it is routable/consistent
• Look out for default private addressesat
  corporate and remote networks

27
RAS VPN DeploymentVPN Protocol Selection

• L2TP/IPSec
• First recommendation for best security
• Requires computer trust infrastructure(PKI or
  shared secrets)
• Use PKI instead of shared secrets
• PPTP
• Second recommendation understanding
• Use with strong user authentication
• Passwords may be workable if PEAP can be
  completed for VPN scenarios
• Least cost because trust model is based on user
  identity
• No computer trust infrastructure to deploy(PKI
  or share secrets)

28
RAS VPN DeploymentCertificate Deployment

• For computer authentication when L2TP/IPSec is
  used
• Gateway and client have common trusted root CA
• Gateway
• Auto-enroll if possible
• Domain accessible to perimeter network (also
  known as DMZ, demilitarized zone, and screened
  subnet) servers
• Gateway is RRAS instead of third party
• PKCS if gateway supports it
• SCEP if PKCS is not supported
• Client
• Auto-enroll if possible
• PKCS if client never connects to domain before
  requiring a VPN
• Certificate must be in local computer certificate
  store
• Must have administrative privileges to install

29
RAS VPN Deployment (2)Certificate Deployment

• For user authentication
• Certificate is recognized in Active Directory
• Use smart cards if possible
• Use local user certificates if not using smart
  cards
• Certificate must be in local USER certificate
  store
• Install using log on script bootstrap if possible
• Install using Web or PKCS if log on scripts are
  not possible

30
RAS VPN DeploymentClient Deployment Models

• Connection Manager Administration Kit
• Use where possible
• Sequenced connections
• Managed phonebooks
• Bootstrap certificates and tools
• Support for earlier platforms
• Client configuration setup
• New Connection Wizard
• Automatic protocol setup

31
RAS VPN DeploymentSplit Tunnels or Not

• Only deploy with ICF on client public interface
• Managing client routes
• Administrators should control them
• Use DHCP classless static routes
• Permits update at connection time
• Support in Windows XP
• Use Connection Manager for down-level only
• Updates only at client reprovisioning
• Consider Internet and private addresses
• Printing to home printer and Internet while
  connected

32
RAS VPN Deployment (2)Split Tunnels or Not

• Cannot split to home if corporate addresses
  conflict
• Resource address conflicts between home and
  corporate
• Default gateway conflicts between home NAT and
  corporate
• Non-split connections will still work

33
Updating Proprietary VPNs
Third-PartyDirectory
Active Directory orWindows NT 4.0 Domain
LDAP
E-mail
Web
File
Print
ERP
VPNGateway
Database

• Gateway Authentication/Encryption Models
• IPSec tunnel mode
• Requires gateway specific client
• Preshared IPSec trust (aggressive mode)
• Certificate-based IPSec trust
• L2TP/IPSec
• No EAP for PPP user authentication
• Passwords are best (if any user authentication)

Third-Party CA
34
Updating Proprietary VPNs (2)
Third-PartyDirectory
Active Directory orWindows NT 4.0 Domain
LDAP
E-mail
Web
File
Print
VPNGateway
ERP
Database

• IPSec authenticates with userID
• Trust user so trust computer
• If preshared key
• Separate distribution model
• If certificate-based authentication
• Certificate enrolled using Web
• Certificate contains LDAP userID
• Gateway verifies certificate revocationand
  presence of userID in LDAP
• Gateway local authorization

Third-Party CA
35
Updating Proprietary VPNs (3)
Third-PartyDirectory
Active Directory orWindows NT 4.0 Domain
LDAP
E-mail
Web
File
Print
ERP
VPNGateway
Database

• VPN userID is separate fromIT infrastructure
  userID, wireless, and dial
• DoS risk to gateway
• No central access policy
• Separate administrator for wireless and dial
• Group membership policiesrequire replicating
  Active Directory groups
• Blind computer trust if there is useridentity
  theft

Third-Party CA
36
Updating Proprietary VPNs (4)
Active Directory orWindows NT 4.0 Domain
Add IAS
E-mail
Web
File
Print
VPNGateway
ERP
Database

• Use Windows XP built-in L2TP/IPSec VPN client
• Move to AD for certificate deployment
• Integrate CA with AD for auto-enroll
• Issue computer certificates
• Microsoft CA can reduce certificate license cost
• Alternate out of computer certificate
• Ideally, use smart cards
• Alternate 1 user store certificates
• Alternate 2 user passwords
• Add IAS to Windows infrastructure
• Point gateway to IAS
• Requires EAP if certificates for user

Third-Party CA
ADAuto-enroll
37
Additional Resources

• http//www.microsoft.com/vpn/
• http//www.microsoft.com/security/
• http//www.microsoft.com/ipv6/
• http//www.microsoft.com/net/

38

• Thank you for joining todays Microsoft Support
• WebCast.
• For information about all upcoming Support
  WebCasts,
• and access to the archived content (streaming
  media
• files, PowerPoint slides, and transcripts),
  visit
• http//support.microsoft.com/webcasts/
• Your feedback is sincerely appreciated. Please
  send any
• comments or suggestions about the Support
• WebCasts to supweb_at_microsoft.com.