Jeff Hodges [email protected] 11-Aug-1999 v0.95 LDAP Directory Services: Security.

Jeff [email protected]

http://www.oblix.com/11-Aug-1999 v0.95

LDAP Directory Services:

Security

11 Aug 1999 LDAP Directory Services: Security 2

Directory Security Syllabus

Brief Review of Directories and LDAP Brief Review of Security Basic Security Concepts Security as Applied to Directories

Threats LDAP Protocol Security Features Typically Implemented Security Features Futures References


Directory SecurityBrief Review of Directories & LDAP

DirectoryDatabase

Network

Directory Service

DirectoryInformation

Tree(DIT)

A

B C

F

D

E G

H I

Client

search “G,C,A”

LDAP



• What directories are…– Object repositories– Typically read more than written– Have explicit access protocols– Support relatively complex queries

• What directories are not…– RDBMSs– Lack notions of..

• Tabular views• JOIN operations• Stored Procedures



• Obligatory, overly-simplified, Protocol Stack Diagram

Directory-based Application

IPEthernet, Cable, Wireless, whatever.

TCP

LDAP


Directory SecurityBrief Review of Security

• Notion of Security for a network protocol is comprised of (at least) these axes..– Identity & Authentication

• “Who are you and who says so?”

– Confidentiality • “Tough petunias to eavesdroppers.”

– Integrity• “Did anyone muck with this data?”

– Authorization• “Yes, you can do that, but no, you can’t do that other

thing.”


Directory SecurityBasic Security Concepts

• Notions...– The notion of Identity– Of Names and Identifiers

• Authentication Identity• Authorization Identity

– Anonymity



Overall Namespace

Names Identifiers



• The applicable “science & technology of implementation”...– Ciphers– Encryption– Integrity

• AKA Cryptography [11]


Directory Security Basic Security Concepts, cont’d


Directory SecuritySecurity as Applied to Directories

• One needs to separately consider each of the four security axes in the context of anticipated threats.

• Also need to consider security from the perspectives of..– the info stored in the directory, and..– attributes of the requesters.

• E.g. how much you trust them.

• Note that..– data security != access security


Directory SecurityExample Deployment Scenarios

Anonymous Requesters? Identified Requesters?

Read/Write?

Read/Write?

1 N N Y RO N None2 N N N N/A Y RO Secure Authentication

3 N Y N/A N/A N/A N/A

Mutual authentication, Connection Integrity-Protection

4 N N Y RO Y RW Secure Authentication

5 Y Y N/A N/A N/A N/A

Mutual authentication, Connection Integrity- and Confidentiality- Protection

Required Directory-Specific Security Mechanisms or

Functions

Connection Hijacking or IP

Spoofing Threats?sc

enar

ios Contains

Sesitive Data?


Directory Security Threats

DirectoryDatabase

Network

LegitimateDirectory

Service

Client

search “G,C,A”

LDAP

1.

2, 3

, 5, 6.4

, 7.

7.

DirectoryDatabase

ImposterDirectory

Service

A

B C

F

D

E G

H I


Directory Security Threats, cont’d

DirectoryDatabase

Network

Directory Service Host(s)

8.

9.

10.


Directory Security LDAP Protocol Security Features

• Formal notions of..– Authentication Identifiers [7], and.. – Authorization Identifiers [7]

• Leverages several security mechanisms..– Simple passwords [2, 8]

– SASL [6]

• Kerberos [2]

• Digest [4]

– SSL/TLS [7]

• effectively is a session layer

• The above may be used in various combinations together.


Directory Security LDAP Protocol Security Features

• Integral-to-the-protocol data integrity and attribution are works-in-progress.


LDAP

Directory Security LDAP Security Features Illustrated

DirectoryDatabase

Network

LegitimateDirectory

Service

Client

search “G,C,A”

A

B C

F

D

E G

H I

Authenticated, plus Confidentiality- and Integrity-protected Channel

LDAP

ImposterDirectory

Service

DirectoryDatabase


Directory SecurityBrief Intro to Directories and LDAP


IP

Ethernet, Cable, Wireless,Etc.

TCP

TLS

LDAP


Directory SecurityBrief Intro to Directories and LDAP


IPEthernet, Cable, Wireless, Etc.

TCP

TLS SASLLDAP


Directory SecurityTypical Security Features of Impls

• Security Features typically found in LDAP Implementations• Simple password-based Authentication.• SSL on port 636 (aka “LDAPS”)• At least one impl does StartTLS on port 389.• Access control.• Configurability (e.g. Netscape’s DS Plug-ins).


Directory SecurityTypical Impl Security Features, cont’d

• Important Notice:– The LDAP protocol is NOT an authentication protocol in and

of itself (IMHO).– One MAY use LDAP itself as an authentication protocol, but

one needs to carefully consider what functionality it does and doesn’t bring to your deployment when used in this manner.

• Deployment configuration is critical • Many server-side knobs

– e.g. requiring client authentication


Directory SecurityExample Directory Service Deployment(s)

Desktop ClientsDesktop ClientsClients

LDAPLDAP-based

Directory Service

LDAP-based

Directory Service

Authentication Service

Authentication Service

Auth DB

Directory DB


Registry DB

Auth DB

Directory DB

Directory Security Behind the Scenes (simplified)

LDAP

TDS

Middleware Event Broker

Middleware Event Broker

RegistryRegistry

TDS

Subject’sDesktop(browser)

Web-based User Interface

for Data Maintenance

Web-based User Interface

for Data Maintenance

HTTP (effectively authenticated writes)

Directory Service

Directory ServiceLDAP (Reads)

Network-basedApplications



Desktops(Browsers)

SUNetIDSystem

SUNetIDSystem

TDS


Directory Security Security Case Study

• Case Studies of Application of Security– See..

• Access-Controlled White Pages at Stanford. RL “Bob” Morgan, University of Washington, March 1999.

– http://staff.washington.edu/rlmorgan/talk/dir.ac.nac.1999.03/top.html

– See also Refs [16..18].


Directory SecurityFutures

• Integral-to-the-protocol Data Integrity • Implementations of Start TLS protocol operation.• Implementations adhering to the Authentication

Methods for LDAP requirements and recommendations.

• Hopefully, implementations (in addition to Microsoft’s Active Directory) utilizing Kerberos out-of-the-box.

• Schema standardization and stabilization will continue.

• you too can participate in IETF process– I encourage deployers to invest in the process!


Directory SecurityAcknowledgements

• Harald Alvestrand, Gordon Good, Tim Howes, Paul Leach, RL “Bob” Morgan, Mark Smith, John Myers, Chris Newman, Mark Wahl, + host of others.


Directory Security References

• This talk will be available at..– http://www.stanford.edu/people/hodges/talks/

• Key References..– [1] Understanding and Deploying LDAP

Directory Services. Tim Howes, Mark Smith, and Gordon Good. MacMillan Technical Publications, ISBN: 1578700701.

• See especially Chapter 11: Privacy and Security Design

– [2] Authentication Methods for LDAP. M. Wahl, H. Alvestrand, J. Hodges, R. Morgan. INTERNET DRAFT, Work In Progress, June-1999. Available as: draft-ietf-ldapext-authmeth-04.txt


Directory Security References, cont’d

• Selected References..– [3]

Lightweight Directory Access Protocol (v3): Extension for Transport Layer Security. J. Hodges, R. Morgan, M. Wahl. INTERNET DRAFT, Work In Progress, June-1999.

– [4] Digest Authentication as a SASL Mechanism. P. Leach, C. Newman. INTERNET DRAFT, Work In Progress, March 31, 1999.

– [5] The Kerberos Network Authentication Service (V5). J. Kohl, C. Neuman. IETF Request For Comments RFC1510, September 1993.



• Selected References..– [6]

Simple Authentication and Security Layer (SASL). J. Myers. IETF Request For Comments RFC2222, October 1997.

– [7] The TLS Protocol Version 1.0. T. Dierks, C. Allen. IETF Request For Comments RFC2246, January 1999.



– [8] LDAP “Core RFCs”• Lightweight Directory Access Protocol (v3). M. Wahl, T.

Howes, S. Kille. IETF Request For Comments RFC2251, December 1997.

• Lightweight Directory Access Protocol (v3): Attribute Syntax Definitions. M. Wahl, A. Coulbeck, T. Howes, S. Kille. IETF Request For Comments RFC2252, December 1997.

• Lightweight Directory Access Protocol (v3): UTF-8 String Representation of Distinguished Names. M. Wahl, S. Kille, T. Howes. IETF Request For Comments RFC2253, December 1997.

• The String Representation of LDAP Search Filters. T. Howes. IETF Request For Comments RFC2254, December 1997.



– [8] LDAP “Core RFCs” cont’d• The LDAP URL Format. T. Howes, M. Smith. IETF

Request For Comments RFC2255, December 1997. • A Summary of the X.500(96) User Schema for use with

LDAPv3. M. Wahl. IETF Request For Comments RFC2256, December 1997.

– [9] IP Security: Document Roadmap. R. Thayer, N. Doraswany, R. Glenn. IETF Request For Comments RFC2411, November 1998.

– [10] Site Security Handbook. B. Fraser, Editor. IETF Request For Comments RFC2196, FYI8. September 1997.



– Security books, papers, etc.• [11]

Applied Cryptography - Protocols, Algorithms, and Source Code in C (Second Edition). Bruce Schneier, John Wiley & Sons, Inc., 1996. ISBN: 0471117099.

• [12] Practical UNIX & Internet Security, 2nd Edition. Simson Garfinkel and Gene Spafford, O’Reilly & Associates, April 1996, ISBN: 1-56592-148-8.

• [13] Risk Management is Where the Money Is Dan Geer, CertCo, November 1998.

• [14] Web Security & Commerce. Simson Garfinkel with Gene Spafford, O’Reilly & Associates, June 1997, ISBN 1-56592-269-7.

• [15] Why Cryptography Is Harder Than It Looks,Bruce Schneier, Counterpane Systems, 1996.



– [16] Stanford Registries & Directories pages..• http://www.stanford.edu/group/itss-ccs/project/registry/• http://www.stanford.edu/group/itss-ccs/project/registry/registries.html

• http://www.stanford.edu/group/itss-ccs/project/sunetid/

• http://www.stanford.edu/group/networking/directory/• http://www.stanford.edu/group/networking/directory/models/Word_Dir_Svcs_Model_10-29-98-edited-jdh/Word_Dir_Svcs

_Model_10-29-98-edited-jdh.htm

– [17] Project Horton• http://www.stanford.edu/group/itss-ccs/project/horton/

– [18] SUNet ID• http://www.stanford.edu/group/itss-ccs/project/sunetid/

Jeff Hodges [email protected] 11-Aug-1999 v0.95 LDAP Directory Services: Security.

Documents

Transcript of Jeff Hodges [email protected] 11-Aug-1999 v0.95 LDAP Directory Services: Security.