PKI Network Authentication Dartmouth Applications Robert Brentrup Educause/Dartmouth PKI Summit July 27, 2005

Next Phase Applications Hardware Key Storage (USB Tokens) Application and OS Sign-on with Tokens Document Signatures –Acrobat, Office, XML (NIH) Secure Mail and List Server Wireless Network Authentication Grids

Network Auth Technologies Wireless and Wired 802.1x/EAP TLS and TTLS or LEAP, PEAP, MS-CHAP etc. WEP, WPA x VPN –IPSEC standard, using Cisco proprietary Cisco password authentication is vulnerable, use client certificates to be secure

VPN Objectives Secure network connections for distant office and travellers –some from home use too, local IP address Secure some legacy applications with closed subnets –server firewall rejects connections not from Private subnet addresses –Use PKI “High Assurance” certificate (token if possible) to authenticate –Assign IP address from protected space after Radius Authentication/Authorization

VPN Implementation Cisco 3000 VPN concentrators (3000 can only look at OU in DN, so added OU=PrivateGroupVPN to certs) ACL check implemented by Radius server Members of ACL maintained with “AuthAdmin” application Configure protected subnets on concentrator Two redundant Radius servers for reliability – running FreeRadius 0.9.2

AuthAdmin Each private VPN subnet intended for members of a specific group Existing examples –Human Resources –Dean of Students Office –International Students Office –Student Health Services Individual in the group authorized to maintain group membership, add and delete Group membership stored in LDAP directory –Web interface for group admin

AuthAdmin UI (screen shot)

Network Authentication Objectives Implement additional protection for campus network services Limit outside use of network Protect campus users from malicious behavior of others Eliminate possible eavesdropping

Network Authentication Implementation Deploy 802.1x/EAP-TLS on APs and switches Traffic is encrypted between user and AP/switch Clients are authenticated with PKI certificates –in our case locally issued No Passwords are exchanged (no credentials to steal)

EAP-TLS Implementation Configure Radius –AP clients, users, EAP-TLS module –Certificate for Radius server –Provide Root certificates of trusted CAs to EAP-TLS module Dartmouth self-signed certificates automatically accepted Tested APs from Cisco and Aruba

Client Software Supplicants built into Win 2000 SP4, XP SP1-2, MacOS –other supplicants available for these platforms Supplicants available for Linux, Win98 and MacOS 9 (some from vendors)

Issues Windows: –no password on Keys –no luck with tokens yet –set advanced options for server certificate validation –Certificates with UID in DN fail Win XP SP1 had some issues with SSID and cert selection, improved in SP2 Mac KeyChain: early versions confused by more than one key with same "name"

Greenpass Objectives System developed to support Guest Authorization in an 802.1x EAP-TLS environment –Also useful for insiders that forgot their token User only needs 802.1x capable machine and web browser, no additional software Guest Introduces Public Key to Greenpass Authorization System Host signs authorization for Guest Access using SPKI certificate delegation features Guest then has access to controlled internal network until time limit expires

Greenpass Implementation Use Router, AP and switch capable of VLANs to create limited use network Recently implemented automatic VLAN switching by Radius Modifications to FreeRadius needed Greenpass servers run on Linux Delegation tool is written in Java Available as Open Source –

Guest Unauthorized

Guest Introduction

Guest Fingerprint

Authorized Delegator

Select Guest

Guest Lookup

Delegation Tool

Delegation Complete

Guest Authorized

Authorized User