Method of identifying mobile devices Srinivas Tenneti

© 2009 Cisco Systems, Inc. All rights reserved.Cisco Public 2 TECHSEC _05_2008_c1 Mobile 3G/4G Wi-Fi At home At work EMPLOYEE CONTRACTOR GUEST Who? When? How? Where? Device? Device Where Who How Motivation for the problem  Enterprises want to deploy context aware access control method.  Context aware access control is to grant policy to different resources based on their type, location, identity, and the operating system or applications running on the endpoint devices.  Traditional network access control methods relied on giving access mainly based on whether the device complied with the policy or not.  Identifying the device and the user is very critical for deploying context aware access control method.

© 2009 Cisco Systems, Inc. All rights reserved.Cisco Public 3 TECHSEC _05_2008_c1 Network Access High Level Diagram 3560-X 3750-X 4500 AP 1142 Wireless End Points 6K or 7K 6K Wireless End points Linksys AP ISR 3945 Remote Worker 4K ACS Active Directory CA Server RSA Auth Mgr MSE 3300 Data Center/Service Block AP 1142 ACS MDM WAN ISE

© 2009 Cisco Systems, Inc. All rights reserved.Cisco Public 4 TECHSEC _05_2008_c1 Alice Bob I want to talk Ok, what is your username password Here is my user name Respond to the challenge K Here is response = MD5(K) Password based authentication

© 2009 Cisco Systems, Inc. All rights reserved.Cisco Public 5 TECHSEC _05_2008_c1 Alice Bob I want to talk, My Id is “Alice” Ok, This is my certificate Establish encrypted tunnel I_d request I_d response challenge request challenge response Challenge request Challenge response Certificate only on the server  The server Bob only presents its certificate.  The Secure tunnel is established by Bob without really knowing who Alice is.  An attacker can waste the resources on the Bob by challenging with different IDs.

© 2009 Cisco Systems, Inc. All rights reserved.Cisco Public 6 TECHSEC _05_2008_c1 Alice Bob I want to talk, Here is my certificate Ok, This is my certificate Authenticate each other  Both Alice and Bob authenticate each other using Digital Certificates.  Digital certificates once deployed can be used for wired variety of applications. For example, SSL, IPSec, 802.1x, DNSSec, and so on..  This provides high level of trust but Bob does not know with what device Alice is connecting with. Certificates deployed on both Alice and Bob

© 2009 Cisco Systems, Inc. All rights reserved.Cisco Public 7 TECHSEC _05_2008_c1  Biometrics – voice, facial. The constraint is mainly on deploying on large number of endpoints, and the user’s reluctance to use bio-metrics.  Software or hardware tokens : This is based on symmetric cryptography. The problem is with deploying on large number of endpoints and it is still not able to identify the device the user is connecting with.

© 2009 Cisco Systems, Inc. All rights reserved.Cisco Public 8 TECHSEC _05_2008_c1 Solution to the problem  Both the endpoints and the servers must use digital certificates.  The digital certificate must contain both the user information coupled with device specific information.  When the user presents the certificate the authentication server can authenticate the user, and also authorize based on the device specific information.  The device specific information used is UDID.

© 2009 Cisco Systems, Inc. All rights reserved.Cisco Public 9 TECHSEC _05_2008_c1 Properties of this solution  Mutual authentication.  Identification of the device and the user.  Provide different access scenarios based on the device type.  If a user leaves or if it is compromised then the user and the device can be removed from the group.

© 2009 Cisco Systems, Inc. All rights reserved.Cisco Public 10 TECHSEC _05_2008_c1 Components involved in this solution  PKI, digital certificates and enrollment of digital certificates.  802.1x protocol  EAP authentication methods.  Radius protocol.

© 2009 Cisco Systems, Inc. All rights reserved.Cisco Public 11 TECHSEC _05_2008_c1 Extensible Authentication Protocol (EAP)  Transports arbitrary authentication information in the form of EAP payloads –Establishes and manages connections; allows authentication by encapsulating various types of authentication exchanges  It is not an authentication mechanism itself –Actual authentication mechanisms are called EAP Methods  EAP provides a flexible link layer security framework –Simple encapsulation protocol -- no dependency on IP –Few link layer assumptions Can run over any link layer (PPP, 802, etc.) Assumes no reordering, can run over lossy or lossless media  Defined by RFC 3748

© 2009 Cisco Systems, Inc. All rights reserved.Cisco Public 12 TECHSEC _05_2008_c1 Protocol Version 1 Byte Packet Type 1 Byte Packet Length 2 Byte Packet Body N Byte DST MACSRC MACTypeDataFCS Packet TypePacket Description EAP Packet (0) Both the Supplicant and the Authenticator Send this Packet Used During Authentication and Contains EAP Method Information Required to Complete the Authentication Process EAPOL Start (1) Sent by Supplicant When It Starts Authentication Process EAPOL Logoff (2) Sent by Supplicant When It Wants to Terminate the 802.1X Session EAPOL Key (3) Sent by Switch to the Supplicant and Contains a Key Used During TLS Authentication EAPOL Frame Format

© 2009 Cisco Systems, Inc. All rights reserved.Cisco Public 13 TECHSEC _05_2008_c1 How Is RADIUS Used Here?  RADIUS acts as the transport for EAP, from the authenticator (switch) to the authentication server (RADIUS server)  RFC for how RADIUS should support EAP between authenticator and authentication server—RFC 3579  RADIUS is also used to carry policy instructions (authorization) back to the authenticator in the form of AV pairs  Usage guideline for 802.1X authenticators use of RADIUS - RFC 3580  AV Pairs : Attribute-Values Pairs. RADIUS Header EAP Payload UDP Header IP Header RADIUS Header EAP Payload UDP Header IP Header AV Pairs

© 2009 Cisco Systems, Inc. All rights reserved.Cisco Public 14 TECHSEC _05_2008_c1 CertificationRequestInfo ::= SEQUENCE { version INTEGER { v1(0) } (v1,...), subject Name, subjectPKInfo SubjectPublicKeyInfo{{ PKInfoAlgorithms }}, attributes [0] Attributes{{ CRIAttributes }} } SubjectPublicKeyInfo { ALGORITHM : IOSet} ::= SEQUENCE { algorithmAlgorithmIdentifier {{IOSet}}, subjectPublicKeyBIT STRING } PKInfoAlgorithms ALGORITHM ::= { add any locally defined algorithms here -- } Attributes { ATTRIBUTE:IOSet } ::= SET OF Attribute{{ IOSet }} CRIAttributes ATTRIBUTE ::= { add any locally defined attributes here -- } Attribute { ATTRIBUTE:IOSet } ::= SEQUENCE { type ATTRIBUTE.&id({IOSet}), values SET SIZE(1..MAX) OF } Subject name that could be name, IP address, mac-address CertificationRequest ::= SIGNED { EncodedCertificationRequestInfo } (CONSTRAINED BY { -- Verify or sign encoded CertificationRequestInfo - - }) EncodedCertificationRequestInfo ::= TYPE- IDENTIFIER.&Type(CertificationRequestInfo) SIGNED { ToBeSigned } ::= SEQUENCE { toBeSigned ToBeSigned, algorithm AlgorithmIdentifier { {SignatureAlgorithms} }, signature BIT STRING } Signs the request with private key

© 2009 Cisco Systems, Inc. All rights reserved.Cisco Public 15 TECHSEC _05_2008_c1 Generate private key x.509 request scep request pkcs#10 Generate cert x.509 cert send the certificate store the cert endpoint SCEP client SCEP Server CA server SCEP enrollment process

© 2009 Cisco Systems, Inc. All rights reserved.Cisco Public 16 TECHSEC _05_2008_c1 Internet Campus CA server Mobile device SCEP Proxy Enrolling Certs on Mobile devices

© 2009 Cisco Systems, Inc. All rights reserved.Cisco Public 17 TECHSEC _05_2008_c X Port Access Control Model Request for Service (Connectivity) Backend Authentication Support Identity Store Integration Authenticator Switch Router WLAN AP Identity Store/Management MS Active Directory LDAP NDS ODBC Authentication Server IAS / NPS ACS Any IETF RADIUS server Supplicant Desktop/laptop IP phone WLAN AP Switch Layer 2 Layer 3

© 2009 Cisco Systems, Inc. All rights reserved.Cisco Public 18 TECHSEC _05_2008_c X Protocols EAP RADIUS Store- Dependent Layer 2 Layer 3 EAP over LAN (EAPoL) EAP over WLAN (EAPoW) Supplicant Authenticator Authentication Server

© 2009 Cisco Systems, Inc. All rights reserved.Cisco Public 19 TECHSEC _05_2008_c1 High level exchange Actual authentication is between client and auth server using EAP. The switch is an EAP conduit, but aware of what’s going on 802.1XRADIUS EAP—Method Dependent Port Unauthorized Port Authorized EAPOL-Logoff EAP-Auth ExchangeAuth Exchange w/AAA Server Auth Success & Policy Instructions EAP-Success EAP-Identity-Request EAPOL-Start EAP-Identity-Response 802.1X Port Unauthorized

© 2009 Cisco Systems, Inc. All rights reserved.Cisco Public 20 TECHSEC _05_2008_c1 EAP-TLS AuthenticationAuthenticator Client RADIUS Server Certificate Authority Start Identity Request Identity Random Session Keys Generated Broadcast Key Key Length AP Sends Client Broadcast key, Encrypted with Session Key Encrypted Exchange Server Certificate Client Certificate Only for wireless today; wired in 802.1X-rev

© 2009 Cisco Systems, Inc. All rights reserved.Cisco Public 21 TECHSEC _05_2008_c1 campus CN=mike CN=UDID 1 Authentication server CA server 2 Check if both CNs’ match 3 The Mobile device joins the wireless network using EAP-TLS The Mobile device presents the certificate Authentication Server looks up the CN (eg mike) against the CA server. If successful authenticates The device. Authentication Server checks the UDID of the device against the authorization policy. If successful Then the device is authorized in the network.

© 2009 Cisco Systems, Inc. All rights reserved.Cisco Public 22 TECHSEC _05_2008_c1 Removing a user from the group  ISE periodically pulls the CRL information from the CA server.  When a user needs to be removed then certificate pertaining to the user is revoked.  ISE would check the CRL list and deny the access to the user if the user is found in the CRL list.

© 2009 Cisco Systems, Inc. All rights reserved.Cisco Public 23 TECHSEC _05_2008_c1 EAP request Start request from the device

© 2009 Cisco Systems, Inc. All rights reserved.Cisco Public 24 TECHSEC _05_2008_c1 Switch request identity from the device Request identity

© 2009 Cisco Systems, Inc. All rights reserved.Cisco Public 25 TECHSEC _05_2008_c1 Host responds with iden Username = toby1

© 2009 Cisco Systems, Inc. All rights reserved.Cisco Public 26 TECHSEC _05_2008_c1 Switch ask the client certificate Start EAP- TLS

© 2009 Cisco Systems, Inc. All rights reserved.Cisco Public 27 TECHSEC _05_2008_c1 Server initiates the SSL session ssl session starts

© 2009 Cisco Systems, Inc. All rights reserved.Cisco Public 28 TECHSEC _05_2008_c1 Server sends the certificate to the client Server sends the certificate

© 2009 Cisco Systems, Inc. All rights reserved.Cisco Public 29 TECHSEC _05_2008_c1 Endpoint sends certificate Client sends certificate

© 2009 Cisco Systems, Inc. All rights reserved.Cisco Public 30 TECHSEC _05_2008_c1 username access-req

© 2009 Cisco Systems, Inc. All rights reserved.Cisco Public 31 TECHSEC _05_2008_c1 radius accept

© 2009 Cisco Systems, Inc. All rights reserved.Cisco Public 32 TECHSEC _05_2008_c1 Encrypted handshake message

© 2009 Cisco Systems, Inc. All rights reserved.Cisco Public 33 TECHSEC _05_2008_c1  The remote endpoint is forced to reveal its identity without knowing the identity of the server.  The SSL Server Hello Done message is long 2546 bytes, in test scenario, which is delivered in 3 EAP fragments.  802.1x for wired users does not support encryption.

© 2009 Cisco Systems, Inc. All rights reserved.Cisco Public 34 TECHSEC _05_2008_c1 Pairing Based Handshake (PBH) can be used to prevent the identity of the client when initiating the request. The ID A of the user can be combination of ( UDID + MAC + Serial number of the device). The Wireless LAN controller or the access layer switch can directly authenticate the user instead of passing it to the radius server.

© 2009 Cisco Systems, Inc. All rights reserved.Cisco Public 35 TECHSEC _05_2008_c1  Identity of the device and the user is very critical in building a strong authentication.  The existing methods of bio-metrics or one time passwords are difficult to deploy for large number of end points.  Digital certificates with the device information can identify the device and the user.  Digital certificates can solve the problem today but in future different pairing based handshakes can make the authentication more efficient.