Minutes NameFLOW meeting 18 January 1999, Utrecht (NL) Attendees: David Chadwick (DC), University of Salford Dina Papayannakib (DP), GRNET Henny Bekker (HB), SURFnet Hans de Vries (HV), SURFnet Jean Marc Verbergt (JV), Belnet Kurt Spanier (KS), DFN Peter Gietz (PG), DANTE Peter Valkenburg (PV), SURFnet Ralf Schneider (RS), DFN Rodney Tillotson (RT), UKERNA Roland Hedberg (RH), SUNET and Catalogix Thomas Lenggenhager (TL), SWITCH Ton Vwerschuren (TV), SURFnet Vincent Berkhout (VB), DANTE 1. Opening VB did the introduction and bashed the agenda. 2. NameFLOW report (PG) Usage statistics The number of DSAs is decreasing and this is caused by the European DSAs. The decline is gradually and can be accounted to the fact that people are "purging" there directory removing obsolete or unmaintained data. There was an increase in organisations though, where the biggest increase was in Germany. The LDAP servers are not included, so the decrease of DSAs could be interpreted as a sign of transition to LDAP. Root DSA transfer DANTE was not unhappy about the service provided by ULCC but decided that it would be better to run the server in-house, Some delay was incurred because of holidays. Since 19-12- 98 the DSA at ULCC is read-only and at the end of January it will also refuse bind, however will be logged. The new root DSA (QUIPU flavoured) runs at DANTE on a low end workstation but will be run on a bigger machine shortly. At this moment only seven First Level DSAs have changed their presentation address for their root DSA reference. Other services were also transferred, including statistics scripts, directory probes, mailing lists, FTP information and the helpdesk function. PGP directory After a historical overview of all the PGP efforts related to directory the new initiatives were reported. In November 98 DANTE initiated a mailing list and discussions were held at the IETF. Ed Reed and Jeff Hodges wanted to write a draft about how to integrate PGP in LDAP. There are four different models for storing the key in discussion. Hybrid solution In May at the Heathrow meeting the first proposal for a Hybrid solution was introduced. It was made clear that a hybrid solution would be preferred over a pure X.500 or LDAP solution. In the hybrid solution it deals with both X.500 DSAs and LDAP servers. This would be based on a single vendor backbone where LDAP servers would be connected via LDAP gateways or directly to LDAP capable X.500 DSAs. There are two replication models to shadow information. The first model is based on pure DISP where FLDSAs shadow from shadow information acumulated by the root. TL and KS said that they would be prepared to test this model with real DSAs. The second proposal would use DISP for upwards replication and generate and LDIF files for distribution. It was proposed to even replace the DISP update with LDIF. This would be interesting and needs some mechanism to distribute the files. KS was interested to know if a "diff" on LDIF format is possible. This change file would need to be distributed. TL proposed that somebody should look at an LDIF generator and HB and HV proposed to have a look at a prototype. As part of the Hybrid solution a LDAP DIT is going to be set up, where knowledge references are going to be configured in the LDAP servers. Again the idea of distributing such information via LDIF files came up. DESIRE II PG introduced the project and the part where DANTE is participating, being a distributed directory indexing system. It will be based on a hierarchical architecture using LDAPv3 referral technology. It will be managed from the server side to make the load and needed knowledge for the clients to a minimum. LDAP crawlers will provide informnation stored in the Tagged Index Object (TIO) format as defined in the Common Indexing Protocol (CIP). Special LDAP index servers are connected to the TIO referral server and pass over a LDAPv3 referral to the client. The crawler will act according to a policy that is stored in the registered LDAP servers that take part in the indexing system. TISDAG project (RH) RH has his own company but works as a consultant for SUNET and Umea university. He presented the current status of the Swedish Directory Index project TISDAG. The architecture is based on different access points for clients (CAP) and server (SAP) for each protocol to be used (LDAPv2+3, Whois++, Ph). A query is launched from the user via the CAP. Between the CAP and SAP there is a proprietary DAG protocol that does protocol conversion to exchange information. There is a revised specification of the protocol. Currently there are two implementation, one commercial (by Ericson) and one public domain (by SUNET). There is a pilot service since 1-Dec-99 but is not yet publicly announced. RH lists four problems still to be solved. 1.) The distributed model has the penalty that the search time is long. 2.) There are still problems in translating queries between the structural different directory protocols. 3.) A problem of all directories is character translation and for this they are using Unicode. 4.) Error handling beyond protocol borders. The active interfaces can be found at: web (ht://semla.umdc.umu.se/cgi-bin/tisdag.cgi), PH (semla.umdc.umu.se:105), LDAPv3 (semla.umdc.umu.se:389), Whois++: (semla.umdc.umu.se:63). The TISDAG protocol specification can be found at http://tisdag.sunet.se/. The mailing list is tisdag@swip.net. PV asked about the amount of data. It is expected for large part of the 8 million entries which would be 5 million. For the server site it can be distributed over multiple servers to deal with a large search space. X.500(2001) (David Chadwick) The next version of the X.500 standard was planned for 2000 but it will most likely be 2001 before it will get published. The new key features include - Multi-master replication (in cooperation with the IETF LDUP group) - Multiple service providers (long of interest currently proposed to use overlaying tables and merging the attributes) - Mapping of all X.500 protocols directly onto TCP/IP (useful for replication/DISP) - X.509 update minor changes to v3 certificates. Major changes to attribute changes to attribute certificates. (The target will be to certify privileges on a system.) - Support for F.510 (ITU recommendation for Directory Enquiry): - Search rules to control to what the user can retrieve. It also does relax or tighten automatic search filters. - Hierarchical relation ships for operational information. - Compound attributes/ families of entries. For compound attributes the value of an attribute can be an attribute again up to n levels. The other solution is the Family of Entries, which DC presented in more detail. The family of entries has sub-entries to an entry. This concept needs two new object classes, parent and child and is intended to be supported by LDAP controls and DAP extensions. The normal naming rules and schema apply. Minor extensions to access controls will be needed. Family of entry sub-entries can be accessed in following groups: entryOnly, entry & parent, upToAncestor, nuclearFamily, entry&subtree, extendedFamily. These groups apply to compare, list, search (filter) and removeEntry. Read, add and modify still only apply to the single entries and sub-entries. The concept of Family of Entries is published as an internet draft which will be discussed in the IETF ldapext WG (draft-ietf-ldapext-families-00.txt); it could be a means to solve the problems of storing multiple PGP keys under one entry. KS How would this apply to the other models of the PGP. How would this fit in a key server. In the proposal the sub-entry is moved to a specific entry into a server. To reduce complexity no support of families distributed among several server will be postulated. KS was sceptical about the time it would take to get this implemented in the real X.500 and LDAP products. PV asked what other applications can use this. Multiple others, e.g. correlate phone numbers with its function for the F.520 people to know what it is for. PV suggest to talk to the XML people as the search principle is identical to the querying on XML as it also uses trees. TL mentioned that large part of the internet draft has ITU text referring to X.500 standards. At the IETF a lot of IDs are pending on other IDs to be promoted to proposed standards. The DFN project AMBIX (RS) The original aim of the DFN project AMBIX was to provide a email directory for the German academia. Starting position was an unclear situation in respect to privacy legislation. The legal issue is a conflict of interest to publish data versus protecting personal data. As a compromise, which is described in a privacy legislation expertise, only a minimal set of personal data are collected. The persons have to be informed about the data transfer and their rights. If there is no response for six weeks after this act of informing, the data are published in the Directory. The data are only retrievable from "allowed" countries (EC, USA and Canada), i.e. countries with comparable privacy legislation. This access control is fulfilled by the Tübingen implementation of the Web to LDAP gateway called TWEB by a reverse lookup of the IP address. The project recently took over the maintenance of the German root DSA, which was formerly done by the TU Chemnitz. Due to this move the presentation address changed to: '0101'H/Internet=134.2.217.132+17023 Recent activities of the project are to set-up a German index system and a certificate server. Another working field is evaluation of directory products. For more information see the German Website www.directory.dfn.de. The email directory is accessible at: http://ambix.directory.dfn.de:8889/, contact AMBIX-d@directory.dfn.de the country level is accessible at: http:/puma-realy.directory.dfn.de:8901/, contact puma- dsmanager@directory.dfn.de SURFnet update (TV) They are actively moving away from QUIPU which causes an interesting problem how to interconnect the X.500 DSAs in an LDAP national server. A solution would be to replicate the information into an X.500 DSA for the X.500 domain. The second option is to deploy the LDAP server and connect those into the national referral server. There is more information in Dutch available at www.surfnet.nl/projecten/surf-ace/service-enhancement/ldap, with an overview graphics at http://www.surfnet.nl/innovatie/surf-ace/service-enhancement/ldap/dsa- arch.html. SUNET (RH) SUNET has plans to abandon X.500 all together and go for pure LDAP and use the TISDAG technology. The idea is to use a web gateway (most likely using LDAPv3) which will also be used for updating information. There will be some kind of server to keep references for the country which could be in any format. One of the problems is the tree structure, e.g. one university has a complete flat structure which is very hard to browse. SWITCH (TL) Not much has changed, still same QUIPU software. It is expected that many people will move to LDAP. TL is not too worried about the millennium feature as it mainly hits the replication mechanism. One problem is again the privacy laws where Universities only publish data internally. VB suggested to introduce a specific attribute that defined the scope for usage of the data. UKERNA (RT) There are not many specific requirements for X.500 at this moment. The X.500 pilot will be officially discontinued due to millennium problem. The timing for starting to make changes in new directions is a delicate matter. The hybrid solution proposed by DANTE will be observed. Grnet (DP) The pilot project is ongoing in cooperation with the Greek Universities Network. The aim is the creation of a national directory, which is connected to the global Directory. The root entry c=GR holds only referrals to the servers holding the data. They use the Netscape Directory server version 3 and are looking at problems of internationalisation (Greek and English). Other used technology is LDAPv3 using several Software development kits and APIs under Solaris and Windows NT, X.500 products from Isode and Nexor as well as the Innosoft X.500 Connector (IXC). There are now about 12200 entries of 10 universities. There are problems with the IXC on country level. IETF 43 update (TL) There are several working groups on directory related topics. In the LDAPext WG the main topic is the authentication mechanism for LDAPv3 as it is now labeled Mandatory-to- implement before any other LDAP features are accepted. The authentication mechanisms draft (draft-ietf-ldapext-authmeth-03.txt) gives an overview on different technologies and will define the Digest Authentication via SASL as defined in draft-leach-digest-sasl-01.txt as mandatory. Together with the tls mechanism as described in draft-ietf-ldapext-ldapv3-tls-04.txt this will provide the base for interoperability. Also in the field of access controll the WG has moved on. It will be performed via controls and extended operations. Transfer and storage are open for competition, which gives problems for replication of access control information. In the field of Referrals two types are to be distinguished: referral to naming context and referrals used by mesh or indexing services. The LDUP WG is working hard on replication issues, proposing a very complex approach, defining following modes of replication: primary, updatable, read-only, sparse, fractional and partial. Profiles will become important since not everyone will need, e.g. multi-master replication. It is yet unclear what features should be mandatory to implement. The OpenPGP WG is working on RFC2440 interoperability testing together with IMC. New features for the new version could be: pictures and sounds in public keys, message integrity code, stealth mode (hidden recipient) and steganographic encoding. In the field of PGP keys in LDAP ED Reed and Jeff Hodges volunteered to right a draft, but there was no adoption in the charter. A BoF on LDAP schema for email routing took place, for routing within one organistaion, which could help as additional push for LDAP directories. Another BoF was about human friendly identifiers, for name spaces in real life coupled with context information. See draft-mealling-human-friendly-identifier-req-00.txt and –arch-00.txt and the mailinglist hfi[-request]@cs.utk.edu. Data-driven-x.500-web-gateway (KS) KS used for his webgateway TWEB as basis the Frank Richter web500gw and enhanced it with extensive configuration, access control and security features, multiple-language support, corporate identity, and a mechanism to point to another gateway called gateway switching which can be defined static in a configuration file or dynamic in the directory entries them self. Dynamic reconfiguration of display parameters is possible as well.. TWEB is now available via FTP: ftp://ftp-x500.uni-tuebingen.de/tweb/tweb* where you can also find the slides of the presentation. For support e-mail to: tweb-support@mail500.uni-tuebingen.de Actions PG, TL and RS are going to perform X.500(1993) tests for the hybrid solution, especially the root CONTEXT using DISP and/or LDIF replication. TV, HF, and PG are going to set up a LDAP-only infrastructure. DP and JV wanted to participate in the X.500-LDAP integration efforts. Next meeting 6 September in the UK at the DANTE premises or alternatively at something close to Heathrow, Brunel, Salford or Athens. Closed meeting. As there were only customers nobody had to leave. Summary of 1993 implementation review. Details of the summary can be requested by PG.