May 11, 2016 1
Modern Multi-factor and
Remote Access Technologies
ANDREW BRICKEY
Senior IT Engineer
Agenda
Problem and solution statements
Overview of multifactor requirements and potential technologies
Problem and solution statements
May 11, 2016 3
Traditional VPN paired with traditional multi-factor solutions are
inflexible and at times too costly (hardware, software, etc)
“Why can’t I have the same remote access for my Microsoft Surface that I get with my iPhone and iPad?”
Is the comparison fair and what can be done to achieve the same level?
Is traditional multi-factor used with remote access LOA3 ?
Is it assumed that “remote access” means full or partial network access? LOA2 x 2 = LOA3 ≤ LOA3 < LOA4 (Say what?)
LOA3 is fine for remote access transport but not authentication?
Multifactor Requirements and Solutions
Level of assurance (LOA) defined:
The level of assurance is measured by the strength and rigor of the identity
proofing process, the strength of the token used to authenticate the identity claim, and the management processes the identity provider applies to it.
LOA1: Provides “some” assurance that the Claimant who participated in previous transactions is accessing the protected transaction or data
LOA2: Provides “single factor” network authentication. Identity presentation is required during enrollment.
(Secret tokens, Knowledge Tokens, Look-up Secrets, Out of band tokens, OTP devices) LOA2(secret you know) + LOA2(OTP device you have) = LOA3
LOA3: Provides “multi-factor” network authentication. Identity proofing is required and verified during enrollment.
At least two authentication factors are required. (Know, Have, Are) Multi-factor software cryptographic tokens are allowed at LOA3
LOA4: Provides highest assurance. In-person identity proofing is required.
Multifactor Requirements and Solutions
Multifactor Requirements and Solutions
(Continued)Traditional/Proven Examples:
LOA1 = An email address or randomly generated PIN
LOA2 = An assigned/trusted username & complex password combination An x509 certificate issued from a trusted source
A single-factor OTP like RSA without PIN
LOA3 = RSA token + PIN, x509 Cert + PIN (LOA2 + LOA2) FIPS 140-2 Level 1 cryptographic solution
Multifactor Requirements and Solutions
(Continued)May 11, 2016 7
Modern/Future Examples:
LOA1 = Google, Facebook, Microsoft account…
LOA2 = A single-factor OTP like Google Authenticator FIDO U2F Security Key
And many more…
LOA3 = Microsoft Virtual Smart Card (VSC) protected by TPM Windows Hello (Facial, Biometric) ?
Mobile device with software certificate + device PIN
And many more FIPS 140-2 Level 1 cryptographic solutions LOA4 = USB based YubiKey, Gemalto, PIVKey cryptographic tokens
Multifactor Requirements and Solutions
(Continued)Thoughts on future multi-factor implementation(s):
Be compliant …
… but be feature and option rich for the end users Embrace multi-platform technologies …
… but don’t limit all devices to the least common of functionality Increase the overall security posture of the network …
… by making it more convenient for system admins to use MFA Embrace future multi-factor technologies …
Multifactor Requirements and Solutions
(Continued)Remote Access Requirements and Solutions..
In recent years traditional multi-factor based remote access has
evolved but hasn’t evolved at the same pace of mobile devices
Still using RSA tokens + PIN and Cisco AnyConnect
iOS and Android devices leveraged a certificate based solution paired
with a device PIN to provide limited access to network services
Limited access to the network because the devices are BYOD
Limited access to the network because device cert + device PIN on
BYOD can be “iffy” when a 5 year old is watching Netflix in the back seat
Remote Access Requirements and Solutions..
May 11, 2016 11
To find out where we can take newer technologies, we must first
define how we want the modern remote access solution to function
Requirement #1 – Convenient for consumers to use
Always connected or easily connected remote experience “Token-less” experience on many devices
Requirement #2 – A “net increase” in functionality for consumers
While traditional VPN gave 100% access to the network, maybe it’s time to reduce access to 95% of the network while decreasing frustration by 80%
Requirement #3 – A “net increase” in security for the network
Leverage “always on” connectivity to stream security telemetry data back to incident response personnel 24/7 rather than waiting for the device to come home
Requirement #4 – A “net increase” in supportability for IT support staff
Leverage “always on” connectivity to push updates, configuration changes and other “IT related” activities 24/7 rather than waiting for the device to come home
Requirement #5 – Be platform agnostic as much as possible
Remote Access Requirements and Solutions..
Requirements Summary
A remote access technology that provides the “device” access to a limited subset of the network to provide authentication, monitoring, management and other device functionality
This “tunnel” will leverage a device certificate at minimum with device password being a secondary “nice to have” requirement.
Assumption: Device requires a PIN to boot up, thus adding additional layers
A remote access technology that provides the “user” access to a large subset of the network to provide access to applications, email, files and other user focused services
This “tunnel” will leverage LOA3 or LOA4 (preferably) multi-factor technologies through a convenient “user friendly” experience
Assumption: Before the “user” tunnel is initiated, the “device” tunnel must be connected and secure
Remote Access Requirements and Solutions..
May 11, 2016 13
Solution : Microsoft DirectAccess
Fully functional and secure remote access solution built into Windows Server 2012 R2
DirectAccess client built into Windows 8 Enterprise and above
DirectAccess provides multiple independent tunnels for the device and the logged on users (Infrastructure and User)
Leverages IPv6 technologies but does not require external or internal IPv6 addressing for your enterprise network
Traffic is tunneled using IP-HTTPS over TCP port 443*
Can be configured to work with existing “smart card” authentication to provide a seamless single sign-on experience for end-user
Remote Access Requirements and Solutions..
DirectAccess : How does it work? …. and other “Magic”
DNS64 and NAT64 are used in conjunction with IP-HTTPS auto-assigned 2002::/16 global unicast address (GUA) or internally defined IPv6 prefix * Intranet IPv4 resources are translated via DNS64 into IPv6 addresses to be tunneled by DA server(s) and NAT’d via NAT64.
IPv6 unique local address (ULA) prefix + internal IPv4 in hex
fd86:9f51:a64b:7777 + a70:13 (10.112.0.19) = fd86:9f51:a64b:7777::a70:13
Client IPsec supplicant (aka Windows Advanced Firewall) is leveraged to create IPsec tunnels for intranet traffic going to DA server (gateway)
DNS client utilizes name resolution policy table (NRPT) to communicate with DNS64 and determines what traffic flows down the tunnel
IPsec connections security rules enforce multi-factor authentication (computer certificate, computer password, user Kerberos/smart card)
Multiple IPsec tunnels created
Remote Access Requirements and Solutions..
May 11, 2016 15
DirectAccess Infrastructure and User Tunnels
Remote Access Requirements and Solutions..
DirectAccess : How it looks to normal users ?
When a user takes their Windows 8/10 device on travel or home, as soon as their device connects to wireless the device infrastructure tunnel
immediately starts connecting to the DA server using the LOA2 device certificate and LOA2 password (LOA2+LOA2=LOA3)
When a user logs on or unlocks their session using their Microsoft Virtual Smart Card (LOA3) or their YubiKey USB token (LOA4), the user tunnel connects after a short delay without interaction. Access to email, file shares, applications seamlessly work*
Remote Access Requirements and Solutions..
May 11, 2016 17
DirectAccess : What are the concerns?
DirectAccess is enabled “per computer” so ANY smart card mapped to a user account can connect
Traditional internet proxy vs transparent proxy changes the world when tunneling is not “forced” (Good ol’ split tunnel discussions)
DirectAccess is really easy to setup but majority of the problems with it are not DirectAccess related
Smart card logon
Applications with hard-coded IPv4 addresses
Legacy client OS configurations that simply break DA
When DirectAccess works, it works great. When it doesn’t work, it’s very difficult at times to troubleshoot with no single “DirectAccess” client log to troubleshoot.
Bringing is all together..
Multi-factor authentication paired with future remote access
technologies..
What does it look like ?
DirectAccess is not the only solution available that can satisfy the previously defined requirements
Cisco AnyConnect currently has most of the features and/or is working to incorporate similar functionality
The future of remote access is less about the methodology of creating the transport layer and more about how convenient it is for users to consume the service while not reducing the level of assurance
An HSPD-12 PIV card is LOA4 but is just about the most inconvenient multi-factor solution available but is the most compliant
Windows Hello uses Biometric and Facial recognition to log into a Windows device BUT is not yet smart card authentication therefore does not satisfy “checking the box” on required smart card logon
May 11, 2016 19
