Editor's Note: These minutes have not been edited. SVRLOC WG Meeting minutes 38'th IETF - Memphis, Tennessee Minutes taken by Charlie Perkins and by Erik Guttman. Agenda MINS TOPIC 5 Agenda 25 Service Location Protocol Last Call Changes in draft 15 to 16 - Authentication Support - Modification of String Search Semantics - Definition of Service Specific Multicast Address assignment from a string hash on the Service Type String - Dialect header field is reserved now. Changes in draft 16 to 17 - Rewording the portions on digital signatures and certificates (no longer dependent on RSA or X.509). 20 Discuss Ryan Moats' drafts - draft-ietf-svrloc-advertising-00.txt - draft-ietf-svrloc-discovery-00.txt - draft-ietf-svrloc-wpyp-00.txt 10 Discuss HOPS 10 Discuss WG Charter - Plans Discussion on changes to the SLP during the IESG WG Last Call The authentication mechanism for SLP was presented to those who were unfamiliar with the recent revisions to the draft. Service authentication is done by assigning a SLP Scope called a "Protected Scope". The SA signs the attributes and url of a service advertisement in a Protected Scope. The UA then checks the signature on the URL and/or attributes of a service in order to validate the service. The following illustration shows the relationship of SA, UA and DA in this process: Service Protected Scope operations require | +---< Signed URL Private Key for the Scope | +-< Signed Attributes | | | | | | (|*|) Directory Agent Public Key for the Scope | | | | | | Application | | | | +-> User Agent Public Key for the Scope +---> The DA does not *alter* the signed URL or its signature, or the attributes or their signature; it merely caches them. The DA uses the same algorithm as the UA to determine if the registration is valid. It will reject URLs or Attributes that are registered or deregistered if the signature does not check out using the signature checking algorithm. The UA obtains a signed URL by doing a Service Request in a Protected Scope. The UA may obtain a signed set of attributes by doing an attribute request in a Protected Scope. This attribute request supplies the URL of a service in the Protected Scope (as when it has already been obtained with a Service Request.) This is a way of obtaining all of the attributes of a particular service in such a way as to be able to be sure the attributes are authentic. Signatures are calculated over the registered string, its character type, a time-stamp, and the 'lifetime'. This will prevent their illegitimate use for replay attacks. Further, the UA and DA may only check the signature. They may not register the same or modified services elsewhere. The distribution of Keys is required to use generate signed service advertisements and to verify signed URLs or attributes. The mechanism for this key distribution is not specified by SLP. DHCP similarly does not define key distribution for its authentication mechanism. A Certificate format is provided to facilitate key distribution. This format is *not* required but may be useful. It provides a binding of Protected Scope string to a scopes public key, along with a duration of validity for the certificate. *** It was brought up in the meeting that we should/could use X.509 certificates. These have a lot of thought put into them, and include many important fields. Our response was that one *could* use them - we just wanted to propose something that was very simple and could be transcribed in a mail-safe format. It was emphasized that the SLP certificate format is only a *MAY*. *** In particular, there is no provision for the name of the Certificate Authority in the certificate. This may prove insufficiant and require revision in the future, if this certificate format is used. *** Question: Could SASL be used? This is a way of using a more general authentication mechanism. Answer: SASL is connection oriented. SLP is not connection oriented, so SASL is unsuitable. There are two bits in the header which indicate the presense of authenticated URL or ATTRs in the SLP message. Ryan Moats' Drafts - discussion (Ryan's slides are included - in postscript format) One draft, by Ryan Moats, Martin Hamilton from work by Russ Wright, has been split into 3. Finding Stuff "-discovery-00.txt" This draft describes a mechanism for discovery of services across the Internet. The first recourse should be to look for a SRV record in the DNS. The second, is to look for a 'common alias' for a service in the DNS. If these fail, look for Service URLs in the DNS. The last case may indicate a SLP Directory Agent. This DA may be used to locate services by attribute. This final bit of information is currently not in the draft and was requested in the next version. To "Best Current Practice"? Advertising Services "-advertising-00.txt" This draft describes how to bind service urls into DNS RRs. A service type in a domain may return a URL. It may be possible that SINK or NAPTR RRs will be sufficient. For now, the proposal is to use TEXT RRs as netfind did. Note that SRV RRs do not have the right structure to allow this. To Experimental. Service Scheme for WP and YP services "-wpyp-00.txt" These service types define mechanisms for obtaining wp or yp services. Maybe HTTP should be added? A clarification was made in the meeting: The title and language field are used to define the language of the template. It should be mentioned in the service: URL document that there may be a 'default' language. To join other service type definitions. Can these documents be advanced to last call? Yes: we think we should go to WG last call in May. HOPS presentation This is a suggested protocol for determining Host Proximity. It is presently exploratory - there have been no decisions made yet. There is a white paper at http://www.ingrid.org/hops/wp.html. There was a HOPS BOF held at the 38'th IETF - please refer to its minutes for the results. It was plugged at the SLP meeting. The idea which distinguishes it from SONAR and traceroute based schemes is that it allows a third party to do the work - the distance may be measured from the source or the target. A HOPS server does the work using routing information and/or traceroute somehow. The metrics are 'proximity' but not necessarily only number of traversed routers... It seemed other metrics might enter in. The relation to SLP is that one might find services by 'hops groups' (essentially a service type enumeration) - which will presumably return a list of services ordered by hops distance. Note that this is a service by type, not by attribute, so the semantics are much weaker than SLP provides. It might be useful to use HOPS to locate SLP DAs so that 'local' services may be discovered by using SLP after determining what 'local' is, using HOPS. Charter discussion Todd Rupper will look into defining IPX address specifications. If he does, this can be added to the service: URL specification. We anticipate we will have SLP promoted to Proposed Standard in the month of May. There are some additional work items that are well under way in the WG. This work will be completed by the 39'th IETF, hopefully, so that all drafts can be submitted to the IESG for review and possible publication as RFCs. Ryan's drafts: 6/97 We recommend that 'finding stuff' go to BCP, and 'discovery' go to Experimental. API spec: 6/97 This needs a little more work and can go to Informational. service: URL Scheme: 8/97 This needs some more work, and should be considered as a proposed standard. Some of the work done here will be to assess the URL scheme given the criteria in the URL scheme acceptance process document (now in draft form.) A formal process for registration of new service type templates will be provided. service types catalog: 8/97 The examples from the service URL draft will be removed and all the known types will be bundled here. This draft will be published as an informational RFC and be used to 'seed' the IANA registry of service types. SLP IPv6 draft: 6/97 This will go to WG last call in May (with solicitations for comments on the IPv6 list.) If there are no objections and SLP has gone to PS, we will submit this draft to the IESG to go to PS. Additional work to do: SLP used to populate LDAP dynamicly: SLP could be used to dynamicly populate an LDAP directory with network service information. This possibility needs to be considered and worked out. This may or may not need to be done by the SVRLOC WG. SLP deployment and implementation experience: As there is practical experience using SLP, and we are ready to move from Proposed to Draft Standard, additional work will need to be done refining the RFCs produced above. After there is deployment experience there are two interesting enhancements to the protocol we would like to possibly embark upon, if there is sufficient interest: - Hierarchical scopes and DA to DA coordination for scalability and managed redundancy - Discovery of 'local' and 'remote' resources for mobile hosts Erik Guttman SVRLOC WG Chair eguttman@eng.sun.com