Healthcare PKI Workshop Session 2

Using Certificates Controlling Access to Servers

Ann Geyer - Bill Pankeytunitas @ earthlink.net

www.tunitas.com925-631-1244

Session Goals

Focus: Certificate based access control for web servers

Understand Secure Socket Layer (SSL) Protocol– What services SSL does and does not provide

– How SSL uses certificates for authentication

– How SSL interacts with application processes

Understand certificate mapping– Server specific communication of client certificate information

– How to relate client certificate information to directory data

Construct access control rules based on client certificate info– User and role based access control

– Multi-level access control

Session Take Away

Ability to design access control schemes using certificates– Evaluate the value of role information in a certificate

Ability to articulate technical requirements for– Application developers

– Vendors

Ability to construct a stronger PKI business case based on access control simplification – Reduced cost

– Greater scope and reach

– Greater user acceptance

Worksheet

Agenda

Overview of web security– Access control for healthcare situations

Secure Socket Layer (SSL) protocol and its use

Web server access control– “Layered” architecture of web servers

– Communicating certificate information to HTTP server

– Access control logic Internet Information Server (Microsoft) Enterprise Server (Netscape) SSLeay & Apache-SSL (Stronghold)

Multi-level access control – Communicating user information to legacy application

Costs and Risks

OverviewWeb Security

Components of Internet Security

Focus: Message security over open network– Confidentiality

Encryption

– Authenticity Digital signature

– Authorization Access control mechanisms

Server security is a matter of resource protection– Internet increases exposure

– some requirements are not Internet specific Intruder prot ection Availability Audit

– Sever security is beyond the scope of Workshop

Locus of Message Protection Protections can be applied at different protocols levels

– Different “objects” are encrypted

– Different “entities” are being authenticated

Hardware Interface

IP

TCP or UDP

Transport layer security (Eg: SSL )

HTTP SMTP IIOP...

Application layer security (Eg: sHTTP or S/mime)

FTP

Network layer security (Eg: IPSec)

End Users

POP3

Application Layer Security Application objects are encrypted

– Eg: MIME type: application/x- EDI-X12– Eg: MIME type: application/ x-pkcs7-signature– Eg: MIME type: text/ html

Direct authentication of end users

Advantage– Tight binding of application access control logic with end user action– End user interacts directly with security mechanism

Disadvantage– Requires application development to manage security of download applic

ation data Eg: S/mime mail clients or RACER-like application specific browser

– Higher cost to maintain security because of limited applicability All the risks of the Internet, but smaller user community to allocate security c

osts

Next Workshop session deals with Application Level Security

Network Layer Security

Typically implemented in hardware to support VPN– VPNs use public key crypto for authentication & key exchange

IP packet “payload” is encrypted

IP address authentication– Usually identifies a device such as router

Advantage– Transparent to end user and applications

– Potentially very fast with hardware based crypto

Disadvantage– Transparent to end user; cannot authenticate end user without binding end

user to specific device or IP address

– Products not well standardized which limits interoperability

– Requires hardware

Network Layer Security is beyond scope of Workshop

Transport Layer Security

Intended to encrypt messages between TCP/IP clients and servers – Eg: browser clients and HTTP servers

– Does not distinguish between application objects

Authenticates TCP/IP hosts – Application layer protocol server

– Machine at IP address

Advantage– Transparent to end users

– Application protocol transparency

– Simple software implementation keeps costs low

Disadvantage– Authentication of end user is not direct; special challenges in multi-user

environments

– Performance penalties

Transport Layer Security for Web Based Applications

Transport layer security implemented in Internet browsers

Provides transport security autonomy between client & server– For browser, server transparency

Lets browser be a “universal” client for any TCP/IP exchange

– For server, browser transparency Depending on application, minimizes user support requirements

Software only implementation reduces costs

High level of robustness– Multiple application protocol support optimizes the effort to maintain

security mechanism

– Deployment scale potential motivates vendor to support transport layer security

But ...Transport Layer Security is not a complete solution

Not sufficient to just authenticate the client (or server) – Disclosure must be authorized

Subject to diligence based on role

– Rules for authorization undefined by regulators and industry Potential for strict rules in forthcoming privacy legislation / regulation Generally limited to support of patient care or provisioning of care

– Access control implements the authorization processes

Failure to disclose can result in significant loss– Treatment delays

– Patient & trading partner aggravation

– Authorization processes extend to large user groups

Must maintain system of records– Authorization decisions & history of disclosure

Transport layer security has to be implemented as part of a broader access control solution

Secure Socket Layer(SSL / TLS)

Protocol

Secure Socket LayerStatus - SSL is a core technology for the web

SSL provides transport security for open networks– Privacy and authenticity

– Independent of application layer protocols

Major vendor support – SSL client support assumed for web applications (browsers)

– SSL server support also commonplace

– Toolkits available to embed SSL into applications

SSL does works– Most eCommerce sites use SSL

– Currently more than 35,000 SSL protected domains in US

SSL is secure– Any encryption weakness immediately addressed by core vendors a

nd researchers: RSA, Netscape, IBM, Microsoft

SSL /TLS Standards

SSL created by Netscape – SSL3.0 introduced client authentication

TLS protocol is an IETF standard track draft– Based on SSL 3.0

– Does not strictly interoperate with SSL TLS includes mechanism to “backdown” to SSL

– TLS streamlines the SSL handshake

– TLS provides more flexibility for encryption choices SSL 3.0 is RSA dependent TLS supports DSS and Diffie-Hellman

– TLS written as “standard”

TLS will ecome imppotant as browser manufactures implement it– IE5 purports to implement TLS

SSL is a Transport Layer Security Service Secures TCP/IP connections

– Protects HTTP, NNTP, POP3, SMTP, IIOP (Corba) data streams Telnet and FTP protection is less clear but implementations do exist

– Some unresolved issues with multiple data ports– There is a FTP/SSL IETF draft

SSL provides transport layer security & is independent of application layer protocol

Hardware Interface

IPTCP or UDP

SSL Security Services

HTTP SMTP IIOP

Link Layer

Network Layer

Transport Layer

Application LayerPOP3

End Users

SSL Software Implementation

SSL is generally implemented after transport layer interface ( ie. WinSock) – Use conventional unprotected socket connections

– Apply the SSL negotiated security services to data streams

SSL is not usually implemented as free standing code– However, toolkits are available from RSA, Netscape, IBM

On the client side, SSL is usually implemented as code in the browser– Logically it becomes part of the HTTPs or other application layer pro

tocol There is some clientside support for POP3/SSL

SSL is usually implemented in server code– HTTPs for webservers

– Separate code module allows plug & play replacement

SSL Negotiated Services

Handshake Phase– Server & client authentication

– Determination of cipher parameters Algorithms (bulk encryption, symmetric key) Symmetric keys State maintenance

– Often overlooked but may have security implications

Data Transfer Phase– Encryption

– Integrity checks

All SSL communications takes place over an SSL “Record Level Protocol”– Defines an SSL “Record” which includes a MAC

SSL Handshake

1. Client Hello

2. Server Hello

3. Client Master Key

4. Client Finished

5. Server Verify

6. Request Certificate

7. Client Certificate

8. Server Finished

} Optional components

SSL Handshake - 1. Client Hello

SSL is initiated by client– Triggered by an HTTPs request by browsers

– But is NOT part of HTTP

Client Hello is a cleartext message which includes– SSL version

– Client encryption capabilities Algorithms, key lengths, digests

– Session ID Allows for “reuse” of an existing secure channel Set to “Zero” if no session ID in client’s cache

– Client Challenge A randomly generated data stream

SSL Handshake - 2. Server Hello

Responds to Client Hello

If Server is establishing a new secure channel, Server Hello is a cleartext message which includes– Encryption capabilities

Which of the client options will server support Allows resource to enforce encryption policy (Eg: strong encryption)

– Server Connection ID Randomly generated

– Server Certificate Passed to client

If Server is re-using existing channel, then server only needs to generate new connection IDand can reuse encryption settings and server certificate

SSL Handshake - 3. Client Master Key

When a new session is being established, the Client sends

Client first validates server certificate– May check for revocation although not routinely supported by

browsers

– If certificate root is not installed in browser, then typically end user is presented with dialogs to explicitly accept certificate

Client sends final encryption parameters– Final Encryption Choice

Selected from among the server supported options

– Server can force choice of encryption parameters

– Encrypted Session Key Randomly generated by client Used for bulk encryption of application level data & messages Encrypted with server’s public key

SSL Handshake - 4. Client Finished

Indicates client’s readiness to activate channel and send or receive application data

Encrypted Server Session ID is sent to server– Encrypted using selected option and session key

SSL Handshake - 5. Server Verify

Server encrypts client challenge using negotiated encryption options and client generated session key– Authenticates server

Session key is only available to the legitimate server Requires private key corresponding to server certificate

to decrypt Client Master Secret and obtain session key

At this point, an encrypted session has been established

SSL Handshake - 6. Request Certificate

Server initiated phase to support client authentication– Server configuration option not usually implemented without PKI

– Requires SSL version 3.0

– Takes place after server authentication and does not affect stages 1-5

Server sends Request over encrypted session– Certificate Challenge Data

Randomly generated string

– Authentication Type Client procedure - typically MD5_WITH_RSA_ENCRYPTION Requires that client use its private key to digitally sign

– Session key

– Certificate Challenge Data

– Server Certificate

– List of acceptable CA (SSL 3.1)

SSL Handshake - 7. Client Certificate

Client response to Server authentication challenge

Sent encrypted with session cipher– Client certificate

– Challenge response data

Note: if client does not have a certificate issued by an acceptable CA, SSL session fails

SSL Handshake - 8. Server Finished

Encrypted message which includes– Session ID

Used to identify session ciphers and Client Master Key kept in cache by client and server

Allows session to be efficiently re-established by reducing the authentication steps

Message indicates Server’s readiness to proceed with transmission/reception of the application layer protocol data

SSL Data Transfer

ALL application layer protocol data is encrypted using the session key and the SSL negotiated encryption options

SSL data transfer implementation is integrated into server platforms– Netscape Enterprise Server, Microsoft IIS, Domino

– Netscape SSLeay reference implementation as freeware Integrated with Apache server in StrongHold

SSL Computation Costs

SSL costs are primarily silicon

Encryption costs for the data transfer are function of which encryption options are selected– Symmetric algorithms are generally linear in the message length

For RC5, the proportionality constant is less than 10

– If performance is an issue, typically upgrade to faster processor and more memory or special purpose accelerators

Healthcare resources are typically low volume compared to EC servers EC sites support millions of users with simple transactions (e.g credit card pu

rchase) Healthcare transactions involve larger application objects with simpler transa

ctions (getData)

Per HIPAA, encryption costs not optional – Architect web site to minimize encryption costs

– Factor in application complexity and meta data maintenance

SSL Computational Costs Authentication can be expensive

– RSA signature is computationally complex, but is required to Exchange of some CLIENT_MASTER_KEY data Perform client authentication

– There are reports of poor performance using SSL Transaction processing reduced by a factor of 100 Look at SSL overhead compared to amount of data transmitted Overhead can be relatively high if transactions involve small datasets

Use hardware accelerators for RSA signatures IBM card processes 800 RSA signatures a second

Server configuration controls when authentication is required– How long does session remain “alive” in cache?

Reauthentication required when session expires Independent of HTTP 1.1 “time to live” parameter

– Excessive re-authentication results from short-lived sessions Long-lived session creates potential security weakness

SSL Demo

Illustrate – Client Configuration

Required end user responses

– Server SSL Configuration

– Server Logs

What can go wrong?

Failure to negotiate common encryption options

– HCFA Internet Policy biases implementation toward exclusive use of strong encryption

– Browsers must be upgraded for strong encryption

– SSL error messages sent to browser are not user friendly HTTP process does not have access to failure status or the error messag

es

– SSL fails and so no HTTP request object created Resources may consider some sort of redirection with server plug-in to giv

e users better instructions

– Best defense is at the time certificate is installed by CA Ensure that suitable encryption options are installed to browser (or other c

lients) Require highgrade encryption keys before issuing certificate

SSL Risk ParametersIncomplete End User Authentication

SSL authenticates TCP/IP client and NOT the enduser– Server does not directly challenge enduser

Contrast with “basic” HTTP authentication where Server prompts for entry of login / pswd

– Browser code responds to certificate_request per browser config Server relies upon configuration which ensures enduser action

Validity of enduser authentication is subject to browser configuration of private key protection– Enduser authentication requires private key control appropriate to brow

ser setting, eg: Prompt for password with every use Prompt for password with first use in browser session No explicit control, rely upon physical access control to PC

– Server cannot confirm or manage private key configuration this would be an activity of an application level protocol (ie, manging end u

ser interactions). If build this into browser then limit reach of security solution.

SSL Risk ParametersIncomplete End User Authentication (cont) Authentication depends upon subscriber (enduser) diligence

– Subscriber will be identified as the “authenticated user”– Subscriber is held responsible under:

Subscriber agreement per Model Certificate Policy HIPAA required Certification and/or Chain of Trust Agreement Electronic trading partner agreement

– In some contexts, enterprise can manage browser configuration for enterprise intranet users

Programmatically: Netscape Mission Control, IE Administration Kit Personnel and user policy Desk audits

More reliable authentication available when private keys are installed to hardware tokens– Private key is not exportable, so token must be present– Model Policy supports use of tokens

For very sensitive applications, can restrict access to certificates installed in tokens ( having strong private key protection)

securityHardware extension used to indicate where private key is installed

SSL Risk ParametersIncomplete Server Authentication Enduser typically relies upon “Browser Trust” model

– Browsers come with many pre-installed certificate roots

– Users not educated about purpose or function of these roots Dialogs controlling acceptance of “Untrusted” certificates subject to browser de

sign and manufacture’s bias How does resource owner influence this decision? bootstrap problem

– in order to inlfuence enduser action, enduser must “trust” resource For better security management, enterprise will want to remove unwarranted r

oots and install approved CA roots

– Authenticating an unknown server is complicated by presence of intermediaries or arcane machine names on certificates

machine or domain name may not accurately reflect ownership

Currently browsers only support simple certificate chains

Currently browsers typically do not check revocation status of server certificates– Not particularly problematical, health info servers are maintained in secure

environment, revocation should rarely be required

SSL Risk ParametersExcessively long lived sessions Clients will generally attempt to re-use session parameters

stored in cache– Circumvents client authentication

– Little documentation about how browser cache maintains SSL session information

Is cached SSL session data routinely flushed with termination of browser session?

– Does not appear to be configurable by enduser

Some risk for misauthentication– Multi-user environments & particularly those with static IP address

SSL Server has some flexibility in cache configuration– Principally with respect to session life

– Little programmatic control of cache - no flush_SSL_cache() directive

Performance - security tradeoff – Excessive & unnecessary re-authentication versus inappropriate reus

e of session information

Controlling Access

Access Control Requirement

Access to health information requires Authorization– Privileges can be defined at different levels of granularity

Application level where the privilege is defined across data sets

– eg: data entry for a hospital billing application Data set level where the privilege is limited to specific fields or records

– eg: clinical record access

– Privileges can be assigned to specific users on a per user basis to classes of users in which case users inherit privileges assigned to the

classes of which they are members

Access control enforces Authorization by limiting access to applications or datasets only to users with appropriately assigned privileges

SSL handshake identifies users, but does not validate their authorizations

*

S S L H andshake

E nd U ser

U S E R C E R TIF IC A TE

H TTP S erverP rocess

H TTP / S S L

U ser D B(D irectory)

A pplica tion P rocess(cg i, A S P , S S JS , o ther)

P atien tD ata

U ser In fo

*

*

*

*A C I

U serIn fo

U ser In fo

v A ccess C ontro l P o in ts*

Access Control Components

1

2

34

5

Points of Access Control

SSL Handshake– Identify authenticated users with authorized users

Custom server plug-ins (filters) executed prior to HTTP process– Programatic control based on certificate contents

– More scalable & cost effective, but more difficult to implement

Standard access control mechanisms of HTTP server platforms– Simplest to implement, but greater administrative components

Programatic control within business application – Allows for fine grained control restricting access to particular record

s and data elements

Database Control– Controls implemented at data tier

5

4

3

2

1

Controls can be applied at multiple levels to reduce overall risk

Access Control Using SSL Handshake

SSL Handshake can be used to gate access– Restrict access to users successfully authenticated with

an appropriate digital certificate

Provides very coarse access control– May be complete a access control solution

When subscriber class is identified with class of authorized users And access audit log by user identity is maintained And subscriber class is subject to sanctions for inappropriate use of access p

rivilege can use coarser control

May be supplemented with added controls at the application level

This approach provides protection against dictionary attack on logon/password

Users are identified before being presented the logon/password challenge

– SSL client authentication effectively non-spoofable, so can identify a party responsible for the attack

Scenario: Access Control Using SSL Handshake

State of California CDR (Communicable Disease Reporting)– State requires that physicians report patient encounters that indicated cert

ain communicable diseases

– CMA creates a certificate class restricted to California licensed physicians

– SSL used as the access control solution for CDR Resource

– Access only if user can be authenticated by a CMA issued physician certificate

Advantage– Simple, inexpensive implementation

Disadvantage– There may be other user classes that need access but for which there is no

corresponding certificate class

– Eg: the state labs which also must report to CDR

Risk– Subject to the third part CA practices and integrity

HTTP Server Access Control Mechanisms All commercial HTTP servers support some type of access contr

ol– Best understood method and easiest to work with

– Access control is applied before using any scripts, cgi, or download of data objects

A Resource Access Control List (ACL) contains– A collection of ACE (access control entries), each describing

Account name (for user, group or system logon account)

– users inherit from group(s) to which user belongs Access privileges

– allow, deny, audit

– read, write, execute

– Resources can be described in terms of directories, files -- HTML or scripts -- and files can inherit privileges from directories

Client makes data request, Server validates ACE to determine access

ImplementingHTTP Server Access Control

First create user or group accounts – Each account is assigned a logon/password

– Microsoft IIS administration ~ user admin for an NT domain Use NT User Manager to manually establish accounts Win2000 will support account management w/ Active Directory (LDAP)

– Netscape supports multiple administration tools Manual entry with Netscape Administrator Console Inherit NT user accounts Manage with LDAP directory entries

Then use Certificate Mapping to associate a client certificate with an account– Client requests data, Server checks whether a mapping for the client

certificate exists

– If yes, Server impersonates the account linked to the certificate and executes the request on behalf of the account

Certificate MappingAssigning Certificates to Accounts

Certificate Mapping – Establishes a relationship between the certificate presented during t

he SSL Handshake and the application user account

Two types of Mapping Rules– 1-1 -- Assigns a certificate to a user account– N-1 -- Assigns multiple certificates to either a user or group account

Many users have a common set of privileges User has more than one certificate

Mapping rules can be based on:– The entire certificate (certificate hash)

If exact match, associate certificate with account Usually applicable for 1-1 Mapping

– Match specific certificate fields eg: match if issuer = AMS.org and Subject DN:CN =Bob Jones eg: match if Subject DN: OU=STAFF, O=SierraHospital eg: match if Subject DN: O=SierraHospital and Role=Billing Clerk

One to One Mapping Rules Certificate Mapping

– Establish the user accounts– User acquire an appropriate certificate– Server receives and stores client certificate– Server configured for certificate mapping

Manual certificate acquisition– Microsoft requires pkcs #7 to import certificate file– Netscape allows certificate to be imported to directory

Programatic certificate acquisition– User assigned account with login and password– User accesses site and authenticates over SSL with client certificate– If no client certificate in server store, Server prompts User for login/ ps

wd– Server action depends on particular platform

Microsoft: use CreateMapping method of CertMapper object to assign certificate to the login account (easily done with active server script)

Netscape: set cert2User directive in the obj.conf file

Case Study:Password Replacement Resource owners incur significant cost in maintaining pswds

– Estimated to be 40% of all help desk calls

Certificate Mapping lets users authenticate using certificate instead of password– Version of Direct Trust model

Certificate is accepted because logon/pswd is accepted

– Without Trusted CA, must require user to notify when certificate is revoked or reissued

Trusted CA increase the solution robustness

– User diligence for private key protection replaces diligence for password maintenance (“refreshing”, remembering & keeping secret)

Protecting single private key more palatable than maintaining lists of passwords

Risk– Authentication is no stronger than the procedure used to issue the user

account and password

– Certificate compromised without Resource being notified

Many to One Mappings (N-1)

Used for role based authorization– Where authentication credentials carry sufficient information to deter

mine authorization

First, establish a user account for group/role – Create a shared logon/ pswd for group/role

– Assign appropriate ACE to set privilege for account

Determine Mapping Rules – Using entire certificate

Implement the password replacement scenario where all members of the group/role share the same password

Once mapped, certificate uniquely identifies a group member Group password can be changed by group administrator

– Using certificate fields As previously defined

Case Study: Extending Access to Affiliated Provider Staff

Certificates provide a method to uniquely identify staff while linking access privileges to the provider – From a resource perspective, staff are interchangeable personnel ha

ving no direct association to the resource owner

Create a group account -- DrBobOfficeStaff– Assign logon/pswd to staff administrator

– Each staff acquires an individual certificate from a Trusted CA

– Use Password Replacement strategy Each staff authenticates to resources using common group account lo

gon/pswd All staff certificates become bound to the same account Administrator changes password after staff use

– Provider rescinds staff privilege by revoking individual certificate Resource removes certificate mapping

Case Study: Extending Access to Affiliated Provider Staff

Advantage– Shifting of administration for staff authentication to provider

– Provider has greater flexibility in managing staff access

– Much higher degree of user accountability Unique individual authentication Staff level authorizations Staff administrator manages account password and initiates the

certificate mapping

– Lowered support requirements Access managed by certificate mapping and certificate revocation Same certificate can be used for any number of trading partners

Risks– Staff administrator diligence

Accountability increases consequences of not being diligent Process must be simple to administer

Programmatic Controls Applied at the Application Level

If using scripts, active server pages, server side includes, then some additional access control may be appropriate

Often want multiple levels of access control– eg: Where an HTTP process controls access to billing application

Access to claims submission for provider A restricted to users whose certificate contains the same OU field as provider A

– eg: Where an HTTP process controls access to medical records application

Access privileges differ as a function of the user’s department, role, or license type

Application gets data from certificate fields– The implementation is server specific – Servers generally do not completely parse certificates

Usually just subject and issuer DN, validity dates There are shareware utilities that can be used to parse

Build appropriate access control using the application layer logic

How Application Layer Gets Certificate Content

Microsoft IIS – Creates a HTTP Request ActiveServerPage Object

– Request includes a request.clientCertificate field containing subject DN (parsed), issuer DN (parsed), validity dates, serial number BER encoded client certificate

– must parse the BER to get information in other fields

– IIS maps certificate data into COM objects which are then available to the MS tools

How Application Layer Gets Certificate Content

Netscape

– Exposes the certificate information to cgi process by setting environmental variables:

– CLIENT_CERT_SUBJECT_DN (subject DN) Parses into various DN fields, Eg:. CLIENT_CERT_SUBJECT_OU

– CLIENT_CERT_ISSUER_DN (issuer DN) Parses into various DN fields as above

– CLIENT_CERT (BER encoded certificate) Use C code utilities to obtain added certificate information

– Can use getRequestInfo for Netscape Server applications Serverside javascript or web application interface (WAI)

Certificate Access Control for DBMS

DBMS (Eg: Oracle, EPIC) provide very fine grained access control and extensive audits

Certificates can support the implementation of database access control– User is assigned logon/pswd credentials for the database

– Index the stored DB credentials using one of the certificate fieldseg. DN, issuer + cert serial number,certificate hash Access the user’s DB credentials using the appropriate certificate field

– Pass the user’s DB credentials as part of an application request from data tier

eg: as part of a SQL DatabaseOpen statement or LDAP bind

Advantage– Build applications using data from many sources – Leverage existing database security and audit logs– Simplifies the user credential requirements – Application can function as sort of single sign on (SSO) solution

Custom Access Control Modulesusing Server API

For situations where access control logic is complex and where the other mechanisms don’t provide the necessary logic– eg: access based on directory attributes (LDAP)– eg: access without a pre-existing user account

Commercial servers support server Plug-ins– Development tools and architecture are platform dependent

Netscape Enterprise Server API (NSAPI) & Access Control API Microsoft Internet Server API (ISAPI)

– Custom code modules execute “in-process” as part of server execution Requires very careful design and coding.

Faulty Plugin may crash server, not just terminate session Plugin offer the potential to optimal system performance

(complied c code)

Plugins generally execute prior to invocation of HTTP server session– Therefore if access is not authorized, the HTTP session isn’t started

Custom Access Control Modulesusing Server API (cont)

Expertise in the specific server architecture is required – NSAPI request and session variables are maintained in “block” hash table

of name-value pairs, API provides critical read/write functions

– ISAPI allows direct invocation of system COM objects

Server specific execution– NSAPI server application functions (SAF) execute in a fixed sequence dete

rmined by server configuration file ( obj.conf )

– ISAPI extensions or filters register to be notified of and are invoked by system events (HTTP request)

NSAPI Access Control API & Certificate Mapping API– Allows a high degree of customization

Read / manipulate access control lists (ACE) Customize how certificates are mapped onto ACL and how additional user inf

ormation is acquired

– Designed to optimize use of LDAP directories

Case Study:Supporting Access by PPO Providers

Scenario

– PPO generally include a large numbers of providers who only occasionally treat plan members

– PPO resources are infrequently used by the low volume providers

– Traditional account setup is unwarranted for these providers having taking up too much overhead

– Infrequent usage leads to provider confusion Each use is effectively a first time use. Providers generally call to find out access methods and userid/pswd

– Provider’s PPO status changes frequently

– PPO resources are effectively utilized by only the most prolific providers

– Overall PPO to provider connectivity remains unbalanced

Case StudySupporting Access by PPO Providers

Approach– Plan maintains provider directory including name, license info,

practice profile and contract details

– Provider requests access and authenticates with a trusted certificate containing medical license info

– Server plug-in parses certificate to obtain subject name & license info

– Plug-in queries the provider directory to check status (using LDAP or SQL with name & license info as key)

– Provider status is used by Plug-in to manipulate Server ACL If first time use by current provider, create new account and map

certificate IF provider status not active, can revoke existing account, and/or

redirect provider to information on status If certificate mapping already existing, apply the normal ACL procedure

Case StudySupporting Access by PPO Providers

Advantage– Simpler administration

– Eliminates unnecessary or unused user accounts

– Better security without passwords that float around

– Faster service for infrequent providers

Cost– Non-trivial development costs

– Finding developers with the right level of server expertise

Third Party Access Control Solutions Set of fairly new products

– Offer extranet security management

– Simplify access control for very larger extranets

– All distributed administration of persons, roles, groups, & resources

– Typically support SSL with client certificates

Registry Model – Maintain a set of access privileges for a number of different resources

– User authenticates to a site “Navigator” or “security server” over SSL with client certificate and makes a resource access request

– Navigator passes authorized user an “access token”

– User presents token to the resource to gain access

Products – getAccess (enCommerce)

– Keon (Security Dynamics)

– DomainGuard (HP)

Audit Logs Audit is component of access control solution

– audit capability necessary to evaluate ACL protections, investigate breaches, and /or improve processes

– HIPAA requirement for access control logs

Audit logs can be created at different levels– HTTP server events – Application processes– Legacy systems and databases

All web server platforms support event logging– There is a W3C standard for event logging

Date / time, operation (Eg: GET, POST), target (resource), parameters UserName & client IP address

– May be insufficient for some purposes eg: DrBobOfficeStaff account using n-1 certificate mapping will want to identify t

he individual certificate eg: Record of application level events such a query against medical records for

a particular patient’s data

Audit Logs

Server support for logging of certificate info– Netscape supports log customization with flex-init and AddLog serv

er directives Set directive with manual entry into server configuration file (obj.conf) Can include any server or request variable in log, in particular

– client.user_dn (CLIENT_CERT_SUBJECT_DN)

– client.issuer_dn (CLIENT_SERT_ISSUER_DN)

– Microsoft supports logging of certificate variables only programmatically

Implement IlogPlugin interface and set variables to be logged with QueryExtraLoggingFields method

– Eg: request.clientCertificate.subject for subject DN Register custom log module with server

Certificate Status Checking

Support for certificate status checking is currently limited– Reflects the maturity of PKI and availability of CRL, OCSP, etc

Ideally would like certificate status checking to be incorporated into certificate validation during SSL Handshake

Can indirectly support status checking with certificate mapping– Remove mapped certificate from directory or userDB when you receive

a revocation notice Make this routine part of account administration

– LDAP directories will probably support some sort of referral to check certificate status

– The problem is greatest when working with dynamic access authorization

If this is critical, then you will need to develop custom module using server plugin for certificate status checking

– Can expect improvement as Win2000 raises the stakes for certificate based access control

Certificate Based Access ControlCost / Benefit Summary

Benefits– Explicitly separate authentication from authorization process

Eliminates the need to have a User authorization procedure performed prior to allowing access

Increases User accountability Makes distribution or delegation of issuing authentication credentials fe

asible– More secure than login/ password based access control

Certificates are not subject to guessing, dictionary attack, or similar threats (very important for resources exposed to Internet)

– Reduced support requirement Passwords are either one-time or always under user control

(per private key protection) Single signon benefits and carry over usage for email

– Scalability With an appropriate PKI, can support very large user community

Certificate Based Access ControlCost / Benefit Summary

Costs– Some performance penalty

Certificate authentication vs login/ password

– Some development costs Need to understand how SSL servers are configured Development usually needed to support atypical capabilities such as p

arsing the certificate extensions Can cost justify these separately for funding purposes

– Client certificates More up-front support costs for user training on certificate use and priv

ate key protection Certificates are expected to have smaller maintenance costs than do p

asswords ( has to be tested) Certificate costs can be allocated across multiple applications and for i

nternal and external use

Certificate Based Access ControlRisks

Trusted CA – Certificates are inappropriately issued

– Minimize risk by inspecting the CPS and requiring audits to determine whether certificates conform to your Policy

– Minimize risk when certificates are issued by a healthcare organization who has equivalent requirements for authentication and authorization

Certificate revocation data is untimely – Collorary to above

Private Key Protection– User fails to understand the importance of or the mechanism for protec

ting the private key

– Risk decreases over time through experience and greater PKI deployment

– Lower risk by requiring smart cards or tokens

User resistance to increased accountability