Andrzej Chrząszcz, Janusz Janiszewski,
Franciszek Lewenda, Bogdan Motoszko, Maciej Siciarek
Naukowa i Akademicka Sieć Komputerowa NASK

Zastosowania bazy LDAP w procesie obsługi certyfikatów cyfrowych i kluczy publicznych PKI oraz DNSSEC

(opracowanie przygotowane w ramach realizacji zadań projektu KBN)
Data opracowania: 02.2003

Spis treści

1 Projekt metod współpracy usługi LDAP z infrastrukturą kluczy publicznych (PKI)

1.1 Wprowadzenie do technologii PKI

1.2 Certyfikat cyfrowy

1.3 Przykład zastosowania certyfikatów

1.4 Rola bazy LDAP w infrastrukturze klucza publicznego

1.5 Certyfikaty w bazie LDAP - zagadnienia techniczne

1.5.1 Certyfikat użytkownika końcowego
1.5.2 Lista unieważnionyhc certyfikatów

2 Wbudowanie elementów umożliwiających integracje z usługą DNS

2.1 Certyfikaty i klucze DNSSEC w bazie LDAP - aspekty techniczne

2.1.1 DNSSEC w bazie LDAP - testy laboratoryjne

3 LDAP - zastosowania

3.1 Wykorzystanie baz LDAP w NASK

3.1.1 Wewnętrzny serwer LDAP

3.1.1.1 Kierunki dalszego rozwoju i obecne prace nad systemem

3.1.2 Klienckie serwery LDAP

3.1.2.1 Opis działania systemu

1 Projekt metod współpracy usługi LDAP z infrastrukturą kluczy publicznych (PKI)

Wstęp

Nie ma wątpliwości co do tego, że świat inwestuje w infrastrukturę klucza publicznego. Należy także oczekiwać że wzrost globalnej inwestycji w PKI będzie coraz bardziej odczuwalny także w Polsce. Opublikowany przez Datamonitor raport potwierdza, że rozpoczyna się globalny proces inwestycyjny w ten właśnie sektor. W efekcie, jak przewiduje raport, technologia ta zostanie wybrana przez międzynarodową sferę biznesu dla zapewnienia zarówno uwierzytelnienia jak i szyfrowania w elektronicznej gospodarce. Badanie, przeprowadzone przez Datamonitor, zatytułowane "Tworząc zaufanie: PKI, uwierzytelnienie i metody szyfrowania" stwierdza, że upowszechnienie właśnie tego typu technologii będzie następowało nawet szybciej niż wzrost bezprzewodowej komunikacji. Datamonitor wnioskuje, że nie tylko dostarczyciele sieciowych usług telekomunikacyjnych, ale także operatorzy sieci komórkowych staną się jednym z najważniejszych segmentów użytkowników technologii PKI i ważnym kanałem dystrybucji certyfikatów cyfrowych. Autorzy raportu podkreślają także, że wiele istniejących sposobów uwierzytelniania i szyfrowania poszukuje rozwiązania następującej kwestii: komu można ufać dokonując transakcji na wielką skalę przez Internet i inne sieci publiczne ?

Badania rynku wskazują, że globalne inwestycje w technologie autoryzacji, uwierzytelnienia i administracji powinny osiągnąć 4,6 mld USD do końca 2006 roku.

(źródło: Secure Computing, czerwiec 2001)

1.1 Wprowadzenie do technologii PKI

Infrastruktura klucza publicznego (PKI) to architektura, organizacja, techniki, zasady oraz procedury, które wspólnie wspomagają implementację i działanie kryptograficznych systemów klucza publicznego, opartych na certyfikatach. PKI składa się z systemów, które dzięki współpracy realizują oraz udostępniają usługi certyfikacji. Jednym z głównych, można powiedzieć nomen omen, kluczowym elementem systemów infrastruktury klucza publicznego jest certyfikat cyfrowy.

1.2 Certyfikat cyfrowy

Certyfikat X.509 jest swego rodzaju gwarancją zgodności pomiędzy DN (rozumianym jako tożsamość użytkownika lub urządzenia), a jego kluczem publicznym podpisanym elektronicznie przez urząd certyfikacji (CA). Aby potwierdzić ważność certyfikatu należy zweryfikować całą ścieżkę certyfikacji. W tym celu potrzebne są certyfikaty: CA i wszystkich nadrzędnych urzędów certyfikacji aż do ROOT CA (główny - nadrzędny urząd certyfikacji).

1.3 Przykład zastosowania certyfikatów

Przykładowe zastosowanie certyfikatu X.509, to autoryzacja klienta SSL przy połączeniu do serwera SSL/TLS. Serwer SSL żądający certyfikatu klienta przedstawia listę urzędów certyfikacyjnych, które akceptuje. Zadaniem klienta jest wtedy przedstawienie łańcucha certyfikatów tworzących ścieżkę certyfikacji, która prowadzi od niego do jednego z akceptowanych CA.

Aby mogło dojść do weryfikacji całego łańcucha certyfikatów należy zgromadzić wszystkie brakujące certyfikaty. SSL/TLS nie definiuje sposobu na zgromadzenie wszystkich certyfikatów wynikających z łańcucha certyfikacji, przechowywania zaufanych certyfikatów czy kluczy prywatnych. Każda aplikacja, która wykorzystuje mechanizmy SSL/TLS musi to robić samodzielnie.

Najprostszy sposób, w jaki można osiągnąć ten cel, jest zdefiniowany w standardzie X.509: można pobrać odpowiednie certyfikaty z drzewa katalogowego (LDAP).

1.4 Rola bazy LDAP w infrastrukturze klucza publicznego

PKI, uwierzytelnienie, ochrona transakcji, szyfrowanie, autoryzacja.... za tymi nośnymi i coraz szerzej rozpoznawanymi hasłami stoją sprawdzone już, jak i nowe, stale udoskonalane technologie. Jednym z założeń wszystkich systemów opartych o certyfikaty jest konieczność przechowywania i udostępniania informacji o aktualnym statusie certyfikatu. Uniwersalność oraz cechy i parametry techniczne pozwoliły ugruntować pozycję LDAPa jako systemu pomocniczego powszechnie i niemalże obligatoryjnie wykorzystywanego w ramach wszelkich rozwiązań wymagających przechowywania certyfikatów cyfrowych. Wykorzystanie LDAPa jako części składowej trzyelementowego systemu PKI ( End Entities, Certification Authorities, Repository) wynikającego Z PKIX zakłada także RFC 2559.

1.5 Certyfikaty w bazie LDAP - zagadnienia techniczne

Aby zapisać certyfikat urzędu certyfikacji w strukturze drzewa katalogowego, należy użyć "object class pkiCA" zdefiniowanego w RFC2587:

pkiCA   OBJECT-CLASS   ::= {
   SUBCLASS OF   { top}
   KIND          auxiliary
   MAY CONTAIN   {cACertificate |
                  certificateRevocationList |
                  authorityRevocationList |
                  crossCertificatePair }
   ID    joint-iso-ccitt(2) ds(5) objectClass(6) pkiCA(22)}
 
CACer tificate    ATTRIBUTE  ::=  {
     WITH SYNTAX   Certificate
     EQUALITY MATCHING RULE   certificateExactMatch
     ID  joint-iso-ccitt(2) ds(5) attributeType(4) cACertificate(37) }

crossCertificatePairATTRIBUTE::={
   WITH SYNTAX   CertificatePair
   EQUALITY MATCHING RULE certificatePairExactMatch
 ID joint-iso-ccitt(2) ds(5) attributeType(4) crossCertificatePair(40)}

Wobec tego przykładowy wpis w LDIF może wyglądać tak:

dn: cn=EuroPKI CA, o=EuroPKI, c=PL
objectclass: top
objectclass: pkiCA
cACertificate;binary:: 
 MIIDlzCCAn+gAwIBAgIRAMKrpwMAABjYAAAABQAAAAgwDQYJKoZIhvcNAQEFBQAw
 gYQxCzAJBgNVBAYTAk5MMRAwDgYDVQQKEwdTVVJGbmV0MR4wHAYDVQQLExVodHRw
 Oi8vcGtpLnN1cmZuZXQubmwxHDAaBgNVBAMTE1NVUkZuZXQgUENBIFJvb3QgQ0Ex
 JTAjBgkqhkiG9w0BCQEWFlNVUkZuZXQtUENBQFNVUkZuZXQubmwwHhcNOTkxMTI1
 MTYyNTI4WhcNMDIxMTI0MTYyNTI4WjBXMQswCQYDVQQGEwJOTDEQMA4GA1UEChMH
 U1VSRm5ldDESMBAGA1UEAxMJT2ZmaWNlLUNBMSIwIAYJKoZIhvcNAQkBFhNjYS1h
 ZG1pbkBzdXJmbmV0Lm5sMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA
 s7Bw1lKk5DcFdDxxWUXNFHvUudlvqh8YiHt2slRVxj0/Kg+xXOwFjAEoZc4QQQfQ
 tY8JomuLpnNvk+YqdhEZORX/FFNfGHratsLxDLW3OEWpBWi45/7jBeAZRoeU5CPr
 EYlqe1GBaqz/I+1zKCFb9SuzyWGOdL/ouA8y1ZPOnfaJ9rg2nXyIXrxI4NK1h3hK
 oWQ1g8BZVIRr82pcbUYom3DGvJSw1IYTB6S7Tp80gXw6LJP7ajfcZ2vE6fv8mC93
 MGmMfXo8X2E/8vP5WPflNIOWTg2liF0YvLkslkhvsNAwCKYuMDGMhZ05XfxjdDq3
 tx82hiS76Yf/4FG6Pz49eQIDAQABozAwLjAMBgNVHRMEBTADAQH/MAsGA1UdDwQE
 AwIBhjARBglghkgBhvhCAQEEBAMCAAcwDQYJKoZIhvcNAQEFBQADggEBAF3BFvR+
 AYyY2r0RgF4rktGFRaECJvifFhrcJfzQab6vxv0edVcNBoRhLD3AJFoaqnHCmJM/
 pEi03qYoLrA5Jpryundx9xoyR/ICkYAiusRSUZcI2Y5sF8ecF8j1DDLDHC3L3QsK
 XRF3gDqPcFFLs5FJsH4v+GxQiAceCHrOYMb3YFSSo8/9hxyUjXsG2ymXKAOH6SIv
 hUsEkgBTX4AtkU1q3aM7l9kJcYhDZn3S07HxhPTh/Unk7yaQg9d5+wGRAEyI/dMG
 jpFSqToXE7lUkw0NDZKtaYfVo2W3e0bWWk7JXaFrIYLPx/xh3lyxTecBcLr5ztuM
 4sBxFfwLdT139cM=

Atrybut "cACertificate;binary" zawiera certyfikat CA w formacie PEM. Pamiętać należy o dodaniu podwójnego znaku dwukropka (::) po nazwie atrybutu oraz znaku spacji na początku każdej linii zawierającej certyfikat.

W konfiguracji OpenLDAP należy dodać schemę zawierającą wpis:

objectclass ( 2.5.6.22 NAME 'pkiCA' SUP top AUXILIARY
     DESC 'CA certificate object'
     MAY (cACertificate $ certificateRevocationList $ authorityRevocationList $ crossCertificatePair ))

1.5.1 Certyfikat końcowego użytkownika

Aby zapisać certyfikat użytkownika końcowego w strukturze drzewa katalogowego, należy użyć "object class pkiUser" zdefiniowanego w RFC2587:

pkiUser   OBJECT-CLASS   ::= {
   SUBCLASS OF   { top}
   KIND          auxiliary
   MAY CONTAIN   {userCertificate}
   ID    joint-iso-ccitt(2) ds(5) objectClass(6) pkiUser(21)}

userCertificate    ATTRIBUTE  ::=  {
     WITH SYNTAX   Certificate
     EQUALITY MATCHING RULE   certificateExactMatch
     ID  joint-iso-ccitt(2) ds(5) attributeType(4) userCertificate(36) }

Możliwe też jest użycie "object class strongAuthenticationUser" (2.5.6.15 - id-oc-strongAuthenticationUser, patrz http://www.alvestrand.no/objectid/2.5.6.15.html):

strongAuthenticationUser OBJECT-CLASS ::= {
     SUBCLASS OF { top }
     KIND auxilary
     MUST CONTAIN { userCertificate }
     ID id-oc-strongAuthenticationUser
}

Lub też "object class inetOrgPerson" zdefiniowanego w RFC2798:

( 2.16.840.1.113730.3.2.2
    NAME 'inetOrgPerson'
    SUP organizationalPerson
    STRUCTURAL
    MAY (
        audio $ businessCategory $ carLicense $ departmentNumber $
        displayName $ employeeNumber $ employeeType $ givenName $
        homePhone $ homePostalAddress $ initials $ jpegPhoto $
        labeledURI $ mail $ manager $ mobile $ o $ pager $
        photo $ roomNumber $ secretary $ uid $ userCertificate $
        x500uniqueIdentifier $ preferredLanguage $
        userSMIMECertificate $ userPKCS12
    )
)

Tak więc odpowiednia schema włączona do pliku konfiguracyjnego OpenLDAP musi zawierać wpis:

objectclass ( 2.5.6.21 NAME 'pkiUser' SUP top AUXILIARY
     DESC 'End Entity Certificate'
     MAY ( userCertificate ))

Przykładowy plik LDIF zawierający certyfikat użytkownika będzie wyglądał następująco:

 
dn: cn=Gal Anonim, ou=Kronikarze, o=Biblioteka Narodowa, c=PL
objectclass: top
objectclass: Person
objectclass: inetOrgPerson
cn: Gal Anonim
sn: Anonim
mail: Gal.Anonim@bn.pl
uid: gal
userPassword: {CRYPT}***********
labeleduri: http://www.bn.pl/personel/gal/ Strona domowa Gala
telephonenumber: 022-1111111
description: pasjonat kronikarz
userCertificate;binary:: 
 MIIDUzCCAxCgAwIBAgIRAMBXbjEAAAJ8AAAAAwAAADIwCwYHKoZIzjgEAwUAMIGO
 MQswCQYDVQQGEwJOTDEQMA4GA1UEChMHU1VSRm5ldDEfMB0GA1UECxMWRXhwZXJp
 bWVudGVsZSBEaWVuc3RlbjEeMBwGA1UEAxMVV2FhcmRlbG96ZSBDQTYgQ2xhc3Mx
 MSwwKgYJKoZIhvcNAQkBFh13YWFyZGVsb3plY2EtYWRtaW5Ac3VyZm5ldC5ubDAe
 Fw05OTExMDExNDIyMTRaFw05OTEyMzExNDIyMTRaMHQxCzAJBgNVBAYTAm5sMSQw
 IgYDVQQKExtTVVJGbmV0IEV4cGVydGlzZUNlbnRydW0gYnYxGDAWBgNVBAMTD0ph
 bnVzIExpZWJyZWd0czElMCMGCSqGSIb3DQEJARYWSmFudXMuTGllYnJlZ3RzQHNl
 Yy5ubDCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA5vBVYXtVqXLeESk5KPOM
 UBwtfxm8Ol6QmV1fYKcPmhqCD21PBGT6ITg6CMrlA4onO9V9kJEW7MxKzHvB7KwT
 FpVGBovW35akQECBw4T+NefMbztZrSrw+KU7cTJ/zw+qQ2JIwQyCWZxVuXY43Yir
 PKI9QPL2d+/tUHaaX8m9un0CAwEAAaOCAR4wggEaMAkGA1UdEwQCMAAwQwYJYIZI
 AYb4QgEIBDYWNGh0dHBzOi8vd2FhcmRlbG96ZWNhLndpbmQuc3VyZm5ldC5ubC9j
 bGFzczEtY3BzLmh0bWwwgccGCWCGSAGG+EIBDQSBuRaBtlRoaXMgaXMgYSB3b3J0
 aGxlc3MgYW5kIHVzZWxlc3MgQ2VydGlmaWNhdGUsIGFuZCBpcyB1c2VkIGZvciB0
 ZXN0aW5nIHB1cnBvc2VzIG9ubHkhIFRoaXMgY2VydGlmaWNhdGUgaGFzIG5vIHZh
 bHVlIGFuZCBicmluZyBubyBzZWN1cml0eS4gU2VlIGFsc28gaHR0cHM6Ly93YWFy
 ZGVsb3plQ0Eud2luZC5zdXJmbmV0Lm5sMAsGByqGSM44BAMFAAMwADAtAhQEBbHD
 LlQSo0T/FtdQb2e9nqUqHAIVALQT1YtDvlrM6Bp49N2UJF1klapM
userCertificate;binary:: 
 MIIEOTCCAyGgAwIBAgIBCjANBgkqhkiG9w0BAQUFADBXMQswCQYDVQQGEwJOTDEQ
 MA4GA1UEChMHU1VSRm5ldDESMBAGA1UEAxMJT2ZmaWNlLUNBMSIwIAYJKoZIhvcN
 AQkBFhNjYS1hZG1pbkBzdXJmbmV0Lm5sMB4XDTAwMDExNDEzNTczNFoXDTAwMDQw
 MTAwMDAwMFowfzELMAkGA1UEBhMCTkwxJDAiBgNVBAoTG1NVUkZuZXQgRXhwZXJ0
 aXNlQ2VudHJ1bSBidjEJMAcGA1UECxMAMRgwFgYDVQQDEw9KYW51cyBMaWVicmVn
 dHMxJTAjBgkqhkiG9w0BCQEWFkphbnVzLkxpZWJyZWd0c0BzZWMubmwwgZ8wDQYJ
 KoZIhvcNAQEBBQADgY0AMIGJAoGBAPKw491oaMNZNqz6Mlxa+NiS0j1vS+e7dlu4
 HS8LYx4z0E3zFMAathkTnRcRW9ZQjZCqzMCyATzw88Rtn0GtxZQaUaodjIP7KYC4
 UYGxmfKuk6RhIp+LTlrsrBYyZUggt4fvTibINUrXS2eHpRFhz7UVfibSTKQcuoZg 
 ZCeMsnPrAgMBAAGjggFqMIIBZjARBglghkgBhvhCAQEEBAMCBaAwCwYDVR0PBAQD
 AgXgMB0GA1UdDgQWBBR5JMonnfISg0oKItrjiVpMsaxhnTCBqwYDVR0jBIGjMIGg
 oYGKpIGHMIGEMQswCQYDVQQGEwJOTDEQMA4GA1UEChMHU1VSRm5ldDEeMBwGA1UE
 CxMVaHR0cDovL3BraS5zdXJmbmV0Lm5sMRwwGgYDVQQDExNTVVJGbmV0IFBDQSBS
 b290IENBMSUwIwYJKoZIhvcNAQkBFhZTVVJGbmV0LVBDQUBTVVJGbmV0Lm5sghEA
 wqunAwAAGNgAAAAFAAAACDA4BglghkgBhvhCAQIEKxYpaHR0cHM6Ly9jcmVjaGUu
 d2luZC5zdXJmbmV0Lm5sL29mZmljZS1jYS8wPQYJYIZIAYb4QgEIBDAWLmh0dHBz
 Oi8vY3JlY2hlLndpbmQuc3VyZm5ldC5ubC9vZmZpY2UtQ1BTLmh0bWwwDQYJKoZI
 hvcNAQEFBQADggEBAIZGukYBDO2zKL33BgLfj/r35tJzQoONplLXgLKodgRKOqgI
 L8EW3F8xEpIvOYWBxnLgllA4fIY1s3lKsjZ19c1hZjuOY/SiYPmkgtegPKUAs5YI
 QBPssSz9xa2mKUfuTXDlkA2cLr7D7BCHkX2DhLMAubkwROoELrLevjQSnW+b7xuL
 NA3H/fCIEaHfFMknkyQkrcCIK4N2oNuyF238i5VMzMnMR1TXf8rYKLEii2LW/nGO
 rsJP1JbQerTKA0STgRLBBh9GVtRcp1sVOHqL+9oWlOLYzO83paIdTtGlZSI5gMGp
 IvV8kHVsKQNDmnb2ucy6JJ0JsFiQvofsK1dpud4=

Atrybut "userCertificate" jest zdefiniowany już od początku istnienia standardu X.500.

Jak widać na powyższym przykładzie do jednego DN można przypisać wiele certyfikatów wystawionych przez różne urzędy certyfikacji. Zasady są takie same jak w przypadku certyfikatów CA: w polu "userCertificate;binary" należy umieścić (poprzedzony podwójnym znakiem dwukropka) certyfikat zakodowany w formacie PEM, a każda następna linia musi się zaczynać znakiem spacji.

1.5.2 Lista unieważnionych certyfikatów

Lista unieważnionych certyfikatów (CRL) w drzewie LDAP przechowywana jest w tej samej komórce (entry), co certyfikat właściwego CA (czyli tego, którego dotyczy). Czyli zastosowanie znajduje tu ten sam object class (pkiCA) a w nim atrybut typu "certificateRevocationList;binary". To właśnie w nim umieszczamy listę unieważnionych certyfikatów w formacie PEM (ponownie należy pamiętać o podwójnym znaku dwukropka i znaku spacji na początku każdej linii z listą).

Przykładowy plik LDIF zawierający certyfikat centrum oraz listę unieważnionych certyfikatów wygląda tak:

dn: cn=EuroPKI CA, o=EuroPKI, c=PL
objectclass: top
objectclass: pkiCA
cACertificate;binary:: 
 MIIDlzCCAn+gAwIBAgIRAMKrpwMAABjYAAAABQAAAAgwDQYJKoZIhvcNAQEFBQAw
 gYQxCzAJBgNVBAYTAk5MMRAwDgYDVQQKEwdTVVJGbmV0MR4wHAYDVQQLExVodHRw
 Oi8vcGtpLnN1cmZuZXQubmwxHDAaBgNVBAMTE1NVUkZuZXQgUENBIFJvb3QgQ0Ex
 JTAjBgkqhkiG9w0BCQEWFlNVUkZuZXQtUENBQFNVUkZuZXQubmwwHhcNOTkxMTI1
 MTYyNTI4WhcNMDIxMTI0MTYyNTI4WjBXMQswCQYDVQQGEwJOTDEQMA4GA1UEChMH
 U1VSRm5ldDESMBAGA1UEAxMJT2ZmaWNlLUNBMSIwIAYJKoZIhvcNAQkBFhNjYS1h
 ZG1pbkBzdXJmbmV0Lm5sMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA
 s7Bw1lKk5DcFdDxxWUXNFHvUudlvqh8YiHt2slRVxj0/Kg+xXOwFjAEoZc4QQQfQ
 tY8JomuLpnNvk+YqdhEZORX/FFNfGHratsLxDLW3OEWpBWi45/7jBeAZRoeU5CPr
 EYlqe1GBaqz/I+1zKCFb9SuzyWGOdL/ouA8y1ZPOnfaJ9rg2nXyIXrxI4NK1h3hK
 oWQ1g8BZVIRr82pcbUYom3DGvJSw1IYTB6S7Tp80gXw6LJP7ajfcZ2vE6fv8mC93
 MGmMfXo8X2E/8vP5WPflNIOWTg2liF0YvLkslkhvsNAwCKYuMDGMhZ05XfxjdDq3
 tx82hiS76Yf/4FG6Pz49eQIDAQABozAwLjAMBgNVHRMEBTADAQH/MAsGA1UdDwQE
 AwIBhjARBglghkgBhvhCAQEEBAMCAAcwDQYJKoZIhvcNAQEFBQADggEBAF3BFvR+
 AYyY2r0RgF4rktGFRaECJvifFhrcJfzQab6vxv0edVcNBoRhLD3AJFoaqnHCmJM/
 pEi03qYoLrA5Jpryundx9xoyR/ICkYAiusRSUZcI2Y5sF8ecF8j1DDLDHC3L3QsK
 XRF3gDqPcFFLs5FJsH4v+GxQiAceCHrOYMb3YFSSo8/9hxyUjXsG2ymXKAOH6SIv
 hUsEkgBTX4AtkU1q3aM7l9kJcYhDZn3S07HxhPTh/Unk7yaQg9d5+wGRAEyI/dMG
 jpFSqToXE7lUkw0NDZKtaYfVo2W3e0bWWk7JXaFrIYLPx/xh3lyxTecBcLr5ztuM
 4sBxFfwLdT139cM=
certificateRevocationList;binary::
 MIICbDCCAVQCAQEwDQYJKoZIhvcNAQEEBQAwVzELMAkGA1UEBhMCTkwxEDAOBgNV
 BAoTB1NVUkZuZXQxEjAQBgNVBAMTCU9mZmljZS1DQTEiMCAGCSqGSIb3DQEJARYT
 Y2EtYWRtaW5Ac3VyZm5ldC5ubBcNMDAxMTEzMTQ1OTE3WhcNMDEwMTEyMTQ1OTE3
 WjCByDASAgEFFw0wMDAzMTAxNTI5NDZaMBICAQoXDTAwMDMxMDE1Mjk1OFowEgIB
 DRcNMDAwNTE4MTYyNTQyWjASAgEOFw0wMDA1MTgxNjI1MzNaMBICAQ8XDTAwMDUx
 ODE5MTYzM1owEgIBEBcNMDAwNTE4MTkxNjIxWjASAgEXFw0wMDA4MzAxNTI1NTVa
 MBICASMXDTAwMTExMzE0NTY0MVowEgIBKRcNMDAwOTI2MTAzODQ2WjASAgE7Fw0w
 MDEwMjAxMDU3MzdaMA0GCSqGSIb3DQEBBAUAA4IBAQAtBi/pSBF8JZmzZt7p2xtq
 c6RtmFffAsF8F8aSY1CMQbb25Uk54AGryfHcrJelqwVuif5dz5GcDmXF19LnheV7
 tnUIzZue3RPLVPG+SL3TxNl9gtJbsE40q9KVPBQLxrjLTp+/Jt/8+E+CsKaPCCJI
 V/arYG8LCf+LASUtiOabfFX+LsjBq0jhKLoxM8DoI5whRLWGaTXcK40zMX4PF09p
 7cu5wq9hpogQMchf0ec54bK2UwKd18PUYqKd4HZZjpV7dc8FIEx8vgWvIoWV7OTT
 FDylvScmmyiLdmnv42OaUrWzQ0SUU/b23+U9taB5vPf7jynE9EwPNkLCwZznTHpw

2 Wbudowanie elementów umożliwiających integracje z usługą DNS

2.1 Certyfikaty i klucze DNSSEC w bazie LDAP - aspekty techniczne

Jak wspominaliśmy przy omawianiu wsparcia LDAPa dla DNS, dla umieszczenia w DIT LDAPa stref DNS, konieczne jest załadowanie zarówno cosine schema jak i DnsZone schema.

Wsparcie LDAPa dla przechowywania certyfikatów, kluczy i skrótów generowanych za pomocą funkcji jednokierunkowych, wykorzystywanych przez DNSSEC jest realizowane w ramach tych samych schematów co w przypadku DNS. Zaletę stanowi otwarty system numeracji atrybutów. Pozwala on, w miarę rozwoju lub zmian w standardzie DNSSEC, na zależne od potrzeb, rozbudowywanie schematów o nowe atrybuty niezdefiniowane w DnsZone schema.

W poniższej liście atrybutów wyróżniono te z nich które dotyczą rozszerzenia DNSSEC

2.1.1 Klucze DNSSEC w bazie LDAP - testy laboratryjne

Dla sprawdzenia poprawności przechowywania jak i możliwości importu kluczy stosowanych przez DNSSEC do zewnętrznej bazy LDAP wykorzystano przedstawione poniżej stanowisko testowe

Wszystkie informacje DNS zawarte w strefie certlab.nask.pl oraz rozszerzenia DNSSEC zostały poprawnie zaimportowane do zewnętrznej względem systemu DNS bazy LDAP.

Import zawierającej rozszerzenia DNSSEC zony certlab.nask.pl wykonano za programu zone2ldap, poprzez wydanie polecenia:

zone2ldap -D cn=Manager,dc=nask,dc=pl -b dc=nask,dc=pl -w secret -h 10.20.31.5 -
z certlab.nask.pl -f certlab.nask.pl -c -d

Następnie potwierdzono poprawność umieszczenia strefy certlab.nask.pl w LDAP.

W tym celu zastosowano następujące polecenie:

ldapsearch -u -x -b 'dc=nask,dc=pl' 'objectclass=*'

W poniższym fragmencie wyniku polecenia ldapsearch -u -x -b 'dc=nask,dc=pl' 'objectclass=*' czcionką italic bold zaznaczono interesujące nas rekordy.

version: 2 # # filter: objectclass=* # requesting: ALL # # nask, pl dn: dc=nask,dc=pl ufn: nask, pl dc: nask objectClass: dcObject objectClass: organization o: nask

# Manager, nask, pl dn: cn=Manager, dc=nask,dc=pl ufn: Manager, nask, pl uid: Manager objectClass: organizationalRole cn: Manager

# Bind, nask, pl dn: cn=Bind, dc=nask,dc=pl ufn: Bind, nask, pl userPassword:: e1NIQX01ZW42RzZNZXpScm9UM1hLcWtkUE9tWS9CZlE9 objectClass: top objectClass: person

# pl, nask, pl dn: dc=pl,dc=nask,dc=pl ufn: pl, nask, pl objectClass: top

# nask, pl, nask, pl dn: dc=nask,dc=pl,dc=nask,dc=pl ufn: nask, pl, nask, pl objectClass: top

# certlab, nask, pl, nask, pl dn: dc=certlab,dc=nask,dc=pl,dc=nask,dc=pl ufn: certlab, nask, pl, nask, pl objectClass: top

# sunu1-c, certlab, nask, pl, nask, pl dn: relativeDomainName=sunu1-c,dc=certlab,dc=nask,dc=pl,dc=nask,dc=pl ufn: sunu1-c, certlab, nask, pl, nask, pl objectClass: top objectClass: dNSZone relativeDomainName: sunu1-c aRecord: 10.20.31.204 dNSTTL: 3600 zoneName: certlab.nask.pl SigRecord: A 3 4 3600 20021030130453 20020930130453 12562 certlab.nask.pl. BIb /onqpGGR9cYpJqktDdysENri2v3VsKktRT4cyrpNn7G8I0dWAUdc= SigRecord: NXT 3 4 86400 20021030130453 20020930130453 12562 certlab.nask.pl. BM2EZZp0U6eJZm6Xce/FG6VqEaLXtuOEJi7+wf9cIZsIgneh3LofcQw= nXTRecord: certlab.nask.pl. A SIG NXT

# sunu1, certlab, nask, pl, nask, pl dn: relativeDomainName=sunu1,dc=certlab,dc=nask,dc=pl,dc=nask,dc=pl ufn: sunu1, certlab, nask, pl, nask, pl objectClass: top objectClass: dNSZone relativeDomainName: sunu1 aRecord: 10.20.31.5 dNSTTL: 3600 zoneName: certlab.nask.pl SigRecord: A 3 4 3600 20021030130453 20020930130453 12562 certlab.nask.pl. BBV FThi/0WYtpXqxCzp6yYvrSWDfuxTJT0xoQvsgFv0isMUqPRUDY64= SigRecord: NXT 3 4 86400 20021030130453 20020930130453 12562 certlab.nask.pl. BHx+DIPk0I8s6Aq7Uyu9ST5yh+buTwOejTjFZ1/u2WVcq304LDu4rb8= nXTRecord: sunu1-c.certlab.nask.pl. A SIG NXT

# pecet2-c, certlab, nask, pl, nask, pl dn: relativeDomainName=pecet2-c,dc=certlab,dc=nask,dc=pl,dc=nask,dc=pl ufn: pecet2-c, certlab, nask, pl, nask, pl SigRecord: NS 3 3 3600 20021030130453 20020930130453 12562 certlab.nask.pl. BK 3zgCXGKKWAb3hNg8Jp+LJoBfQYp/oYcyEmyP3IopuovcBsJwyAvp4= SigRecord: KEY 3 3 3600 20021027165850 20020927165850 12562 certlab.nask.pl. B FsjKK5H4qRdRZxmA07L+pABD2ttRdlWmzuKaqWFHoxYTbGNfS3FQ1Q= SigRecord: KEY 3 3 3600 20021027165850 20020927165850 31082 nask.pl. BCYzDAAI7 QNlM2I4bK5lKZs5qh4W2p+pC1mvvzHlyVYyJdDT0vq3RtI= KeyRecord: 256 3 3 BNOPezcH+WxxFwQs+zpEAD9+KWJHn2osssnP3TgSZHU/q2/r9SrIbM2r Dn VZQf6YNLwzOpsceGj57EOhznyZ80ZXmC926SnL+wDssvi4AIf3zODU JTE39XzfvbdIhNB5jmAtsr aQF/DXASh6Pz/3ms4PfPZ5dDQqHQwHXaCl P98OYFKhe7a6fSviSC/Fk8HQZKK0kJKJdqRHJVoS5d MXBvDWx3ZH4cYT LH1YRvBDVM02to1fKHzkhRLvNbz9rgefljFv6FGmllj/u39ZnQxsRCQx yraMD SEeE35Tzg9Ux4J1NYoxtKINnf2HknaVlFt9S5Sc4VlTAUUASrjn O/wuKNUB/ea6ecsPbZsYHx1lO V7rWC3F/0nvhBXd+wehnsy2PAyIlGBy RV0nF7d/Eraeo2t33TsU

# @ + 86400, certlab, nask, pl, nask, pl dn: relativeDomainName=@ + dNSTTL=86400,dc=certlab,dc=nask,dc=pl,dc=nask,dc=pl ufn: @ + 86400, certlab, nask, pl, nask, pl objectClass: top objectClass: dNSZone relativeDomainName: @ sOARecord: certlab.nask.pl. root.pecet1.certlab.nask.pl. 2002062000 28800 7200 3600000 86400 dNSTTL: 86400 zoneName: certlab.nask.pl SigRecord: SOA 3 3 86400 20021030130453 20020930130453 12562 certlab.nask.pl. BFP8sXKZdWJtv0QZ05jvdw81n3S5I5CozdLmlg6cvFTlV8uJdVV7kVc= SigRecord: NXT 3 3 86400 20021030130453 20020930130453 12562 certlab.nask.pl. BBmzXMbHAQXr0jAnds5Z4TlgfmL4U/1F/ggCxuIqRVEEqWAM1E6Oi/A= nXTRecord: bri.certlab.nask.pl. NS SOA SIG KEY NXT

Jak widać w powyższym listingu znajdują się SigRecord i KeyRecord, nie występuje CertRecord - co jednak nie jest błędem powstałym w procesie importu strefy do bazy LDAP, lecz wynika z faktu, że rekord ten jest przechowywany przez serwer domeny nadrzędnej.

W poprzedzedniej częsci testów współpracy LDAPa z DNSSEC nie udało się poprawnie zaimportować podpisanych rekordów strefy. Dla uzyskania obecnego efektu konieczne okazała się reinstalacja oporgramowania BINDa.

3 LDAP - Zastosowania

3.1 Wykorzystanie baz LDAP w NASK

3.1.1 Wewnętrzny serwer LDAP

Dla efektywnego obsłużenia różnorodnych potrzeb dotyczących przechowywania i dostępu do wewnętrznych danych teleadresowych naszej firmy został wykorzystany serwer LDAP. Głównym założeniem projektowym było stworzenie cetralnego i łatowdostępnego repozytorium którego dane będą mogły być dostępne zarówno poprzez ręczne wyszukiwanie, jak również być używane jako książka teleadresowa przez popularne programy pocztowe takie jak Netscape, Outlook czy Lotus. Baza służy wyłącznie do użytku wewnętrznego. Serwer wykorzytuje oprogramowanie OpenLDAP w wersji 2.

Stworzona struktura drzewa LDAP jest w obecnej chwili bardzo prosta.

Wszystkie obiekty w bazie LDAP są typu person(OID:2.5.6.6) z dołożonymi atrybutami.

Dodatkowo w ramach testów została zaimplementowana obsługa protokołu SSL oraz replikacja bazy LDAP na drugi serwer LDAP.

Podczas eksploatacji powstał problem łatwej aktualizacji bazy serwera LDAP za pomocą jakiegoś narzędzia graficznego. W ramach poszukiwań rozwiązania tego problemu udało się znaleźć i z sukcesem zainstalować programy:

LDAP Browser\Editor autorstwa Jarka Gawora
LDAP Administrator firmy Softerra.

Oba programy posiadają bardzo szeroką funkcjonalność dotycząca zarządzania zawartością bazy serwera LDAP natomiast oba programy nie posiadają możliwości dokonywania zmian w konfiguracji serwera OpenLDAP.

Wśród wielu zalet obu programów warto wymienić:

Wielowątkowość
Wsparcie kodowania czcionek w standardzie UTF-8
Pełne wsparcie dla protokołu LDAP v3
Operacje na obiektach typu "Kopiuj", "Usuń", "Drag&Drop", itp.
Tworzenie zakładek
Tworzenie obiektów opartych na "Schema"
Tworzenie obiektów opartych na wcześniej przygotowanych wzorach "Templates"
Wyszukiwanie
Export danych w różnych formatach np. Excel
Automatyczne znajdowanie DN
Wsparcie dla protokołu LDAP/SSL
Wsparcie dla atrybutów binarnych
Password managment
Referral search

Bardziej użyteczny, ale niestety komercyjny jest program LDAP Administrator firmy Softerra, dlatego w najbliższym czasie planujemy zakup licencji tego programu. Poniżej przykład kilku zrzutów ekranu programu LDAP Administrator firmy Softerra

Podstawowe okno aplikacji:

Schema Viewer

Dodawanie nowego obiektu za pomocą kreatora (w czterech krokach)

3.1.1.1 Kierunki dalszego rozwoju i obecne prace nad systemem

W ramach rozwoju infrastruktury PKI w NASK planujemy przechowywanie w bazie LDAP także certyfikatów wystawionych użytkownikom. Oprócz tego w trakcie przygotowania jest także struktura potrzebna dla przechowywania w bazie LDAP informacji o komputerach, serwerach i zainstalowanym na nich oprogramowaniu. Z uwagi na fakt, że usługa zaczęła powstawać przed pojawieniem się dokumentów:

"Definicja danych w gałęzi organizacyjnej jednostki bazy LDAP"
(http://ldap.uni.torun.pl/raporty/ftp/uci/dane.html)
"Propozycja schematu zasobów LDAP zalecanego w projekcie LDAP"
(http://ldap.uni.torun.pl/raporty/ftp/uci/schemat.html

w pracach nad kształtem całości bazy zalecenie i rekomendacje zawarte w dokumentach zostaną dopiero uwzględnione.

3.1.2 Klienckie serwery LDAP

W obecnej chwili trwają prace nad produkcyjnym uruchomieniem systemu wykorzystującego bazę LDAP do przechowywania danych uwierzytelniających i autoryzacyjnych użytkowników korzystających z usługi konta pocztowego.

System wykorzytuje parę serwerów LDAP pracującą w architekturze Master/Slave. Komponenty systemu:

Cisco Secure ACS (serwery protokołówTACACS+, Radius)
Serwery LDAP (Master/Slave)
Użytkowy serwer kliencki (SMTP, POP3, HTTP)

3.1.2.1 Opis działania systemu

Klient dialup po połączeniu z Access Serwerem podaje username i password, access serwer przekazuje zapytanie za pomocą protokołu TACACS+ (lub Radius) do Cisco Secure ACS. Access Control Server przeszukuje bazę użytkowników, jeśli znajdzie podanego użytkownika ze wskazaniem na zewnętrzna autoryzację (LDAP serwer) za pomocą protokołu LDAP przesyła zapytanie do wskazanego w swojej konfiguracji serwera (LDAP Master). Jeśli użytkownik podał prawidłowo username i password LDAP(Master) po porównaniu z przechowywanymi przez siebie wartościami zwraca odpowiedź (protokołem LDAP) do serwera ACS, ten zaś protokołem TACACS+ (lub Radius) przesyła tą informację do ACS. W przypadku gdy serwer ACS nie może skontaktować się z Master LDAP serwerem, po określonym w konfiguracji ACS czasie oczekiwania (domyślnie 10 sekund), ACS przekazuje zapytanie do zapasowego LDAP serwera (slave).

Znaczna część klientów komercyjnego serwera usługowego zgłaszała uwagi co do kłopotliwej, ich zdaniem konieczności pamiętania dwóch haseł, jednego do access serwera (dialup), drugiego do serwera usługowego.

Projektowany system zakłada możliwość wyboru przez użytkownika stosowania trzech wariantów identyfikacji.

Wariant "Jedno hasło"

Wariant ten wychodzi naprzeciw oczekiwaniom użytkowników. Zakłada on dostęp do systemu użytkowego poprzez zastosowanie autoryzacji korzystającej z tego samego serwer LDAP dla obu usług (dial-up i serwer usługowy), tak więc użytkownik podaje tylko jedno hasło.

Wariant "Dwa hasła"

W tym wariancie użytkownik używa dwóch różnych haseł przechowywanych w bazie LDAP

Wariant "Hasło jednorazowe"

Ten wariant zapewnia najwyższy poziom bezpieczeństwa i jest realizowany w oparciu o jedno hasło generowane przez sprzętowy generator haseł jednokrotnych współrpacujący z serwerem system haseł jednorotnych komunikującym się z ACS

Literatura

RFC 2587 Internet X.509 Public Key Infrastructure LDAPv2 Schema
RFC 2559 PKIX Operational Protocols - LDAPv2
RFC 2798 Definition of the inetOrgPerson LDAP Object Class
LDAP Softerra http://www.softerra.com/products/products.php
LDAP Browser/Editor http://www.iit.edu/~gawojar/ldap
LDAP-PKI cook book http://ldap.gigacorp.nl/pkildap.html