integrity of service URLs and attributes included in SLP messages.
The only systems which can generate digital signatures are those
which have been configured by administrators in advance. Agents
which verify signed data may assume it is 'trustworthy' inasmuch as
administrators have ensured the cryptographic keying of SAs and DAs
reflects 'trustworthiness.'
Service Location does not provide confidentiality. Because the
objective of this protocol is to advertise services to a community of
users, confidentiality might not generally be needed when this
protocol is used in non-sensitive environments. Specialized schemes
might be able to provide confidentiality, if needed in the future.
Sites requiring confidentiality should implement the IP Encapsulating
Security Payload (ESP) [3] to provide confidentiality for Service
Location messages.
If Agents are not configured to generate Authentication Blocks and
Agents are not configured to verify them, an adversary might easily
use this protocol to advertise services on servers controlled by the
adversary and thereby gain access to users' private information.
Further, an adversary using this protocol will find it much easier to
engage in selective denial of service attacks. Sites that are in
potentially hostile environments (e.g., are directly connected to the
Internet) should consider the advantages of distributing keys
associated with SLP SPIs prior to deploying the sensitive directory
agents or service agents.
SLP is useful as a bootstrap protocol. It may be used in
environments in which no preconfiguration is possible. In such
situations, a certain amount of "blind faith" is required: Without
any prior configuration it is impossible to use any of the security
mechanisms described above. SLP will make use of the mechanisms
provided by the Security Area of the IETF for key distribution as
they become available. At this point it would only be possible to
gain the benefits associated with the use of Authentication Blocks if
cryptographic information and SLP SPIs can be preconfigured with the
end systems before they use SLP.
SLPv2 enables a number of security policies with the mechanisms it
includes. A SLPv2 UA could, for instance, reject any SLP message
which did not carry an authentication block which it could verify.
This is not the only policy which is possible to implement.
A. Appendix: Changes to the Service Location Protocol from v1 to v2
SLP version 2 (SLPv2) corrects race conditions present in SLPv1 [22].
In addition, authentication has been reworked to provide more
flexibility and protection (especially for DA Advertisements). SLPv2
also changes the formats and definition of many flags and values and
reduces the number of 'required features.' SLPv2 clarifies and
changes the use of 'Scopes', eliminating support for 'unscoped
directory agents' and 'unscoped requests'. SLPv2 uses LDAPv3
compatible string encodings of attributes and search filters. Other
changes (such as Language and Character set handling) adopt practices
recommended by the Internet Engineering Steering Group.
Effort has been made to make SLPv2 operate the same whether DAs are
present or not. For this reason, a new message (the SAAdvert) has
been added. This allows UAs to discover scope information in the
absence of administrative configuration and DAs. This was not
possible in SLPv1.
SLPv2 is incompatible in some respects with SLPv1. If a DA which
supports both SLPv1 and SLPv2 with the same scope is present,
services advertised by SAs using either version of the protocol will
be available to both SLPv1 and SLPv2 UAs. SLPv1 DAs SHOULD be phased
out and replace with SLPv2 DAs which support both versions of the
protocol.
SLPv1 allows services to be advertised and requested without a scope.
Further, DAs can be configured without a scope. This is incompatible
with SLPv2 and presents scalability problems. To facilitate this
forward migration, SLPv1 agents MUST use scopes for all registrations
and requests. SLPv1 DAs MUST be configured with a scope list. This
constitutes a revision of RFC2165 [22].
B. Appendix: Service Discovery by Type: Minimal SLPv2 Features
Service Agents may advertise services without attributes. This will
enable only discovery of services by type. Service types discovered
this way will have a Service Template [13] defined which specifies
explicitly that no attributes are associated with the service
advertisement. Service types associated with Service Templates which
specify attributes MUST NOT be advertised by SAs which do not support
attributes.
While discovery of service by service type is a subset of the
features possible using SLPv2 this form of discovery is consistent
with the current generation of products that allow simple browsing of
all services in a 'zone' or 'workgroup' by type. In some cases,
attribute discovery, security and feature negotiation is handled by
application layer protocols - all that is required is the basic
discovery of services that support a certain service.
UAs requesting only service of that service type would only need to
support service type and scope fields of the Service Request. UAs
would still perform DA discovery and unicast SLPv2 SrvRqst messages
to DAs in their scope once they were discovered instead of
multicasting them.
SAs would also perform DA discovery and use a SLPv2 SrvReg to
register all their advertised services with SLPv2 DAs in their scope.
These advertisements would needless to say contain no attribute
string.
These minimal SAs could ignore the Language Tag in requests since
SrvRqst messages would contain no attributes, hence no strings would
be internationalized. Further, any non-null predicate string would
fail to match a service advertisement with no attributes, so these
SAs would not have to parse and interpret search filters. Overflow
will never occur in SrvRqst, SrvRply or SrvReg messages so TCP
message handling would not have to be implemented. Finally, all
AttrRqst messages could be dropped by the SA, since no attributes are
supported.
C. Appendix: DAAdverts with arbitrary URLs
Using Active DA Discovery, a SrvRqst with its service type field set
to "service:directory-agent". DAs will respond with a DAAdvert
containing a URL with the "service:directory-agent:" scheme. This is
the same DAAdvert that such a DA would multicast in unsolicited DA
advertisements.
A UA or SA which receives an unsolicited DAAdvert MUST examine the
URL to determine if it has a recognized scheme. If the UA or SA does
not recognize the DAAdvert's URL scheme, the DAAdvert is silently
discarded. This document specifies only how to use URLs with the
"service:directory-agent:" scheme.
This provides the possibility for forward compatibility with future
versions of SLP and enables other services to advertise their ability
to serve as a clearinghouse for service location information.
For example, if LDAPv3 [15] is used for service registration and
discovery by a set of end systems, they could interpret a LDAP URL
[16] to passively discover the LDAP server to use for this purpose.
This document does not specify how this is done: SLPv2 agents
without further support would simply discard this DAAdvert.
D. Appendix: SLP Protocol Extensions
D.1. Required Attribute Missing Option
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extension Type = 0x0001 | Extension Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Template IDVer Length | Template IDVer String \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Required Attr <tag-list> Length| Required Attr <tag-list> \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Required attributes and the format of the IDVer string are defined by
[13].
If a SA or DA receives a SrvRqst or a SrvReg which fails to include a
Required Attribute for the requested Service Type (according to the
Service Template), it MAY return the Required Attribute Extension in
addition to the reply corresponding to the message. The sender
SHOULD reissue the message with a search filter including the
attributes listed in the returned Required Attribute Extension.
Similarly, the Required Attribute Extension may be returned in
response to a SrvDereg message that contains a required attribute
tag.
The Template IDVer String is the name and version number string of
the Service Template which defines the given attribute as required.
It SHOULD be included, but can be omitted if a given SA or DA has
been individually configured to have 'required attributes.'
The Required Attribute <tag-list> MUST NOT include wild cards.
E. Acknowledgments
This document incorporates ideas from work on several discovery
protocols, including RDP by Perkins and Harjono, and PDS by Michael
Day. We are grateful for contributions by Ye Gu and Peter Ford.
John Veizades was instrumental in the standardization of the Service
Location Protocol. Implementors at Novell, Axis Communications and
Sun Microsystems have contributed significantly to make this a much
clearer and more consistent document.
F. References
[1] Port numbers, July 1997.
ftp://ftp.isi.edu/in-notes/iana/assignments/port-numbers.
[2] ISO/IEC JTC1/SC 21. Certificate Extensions. Draft Amendment
DAM 4 to ISO/IEC 9594-2, December 1996.
[3] ISO/IEC JTC1/SC 21. Certificate Extensions. Draft Amendment
DAM 2 to ISO/IEC 9594-6, December 1996.
[4] ISO/IEC JTC1/SC 21. Certificate Extensions. Draft Amendment
DAM 1 to ISO/IEC 9594-7, December 1996.
[5] ISO/IEC JTC1/SC 21. Certificate Extensions. Draft Amendment
DAM 1 to ISO/IEC 9594-8, December 1996.
[6] Unicode Technical Report #8. The Unicode Standard, version 2.1.
Technical report, The Unicode Consortium, 1998.
[7] Alvestrand, H., "Tags for the Identification of Languages",
RFC1766, March 1995.
[8] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform
Resource Identifiers (URI): Generic Syntax", RFC2396,
August 1998.
[9] Bradner, S., "Key Words for Use in RFCs to Indicate Requirement
Levels", BCP 14, RFC2119, March 1997.
[10] CCITT. The Directory Authentication Framework. Recommendation
X.509, 1988.
[11] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC2234, November 1997.
[12] S. Gursharan, R. Andrews, and A. Oppenheimer. Inside AppleTalk.
Addison-Wesley, 1990.
[13] Guttman, E., Perkins, C. and J. Kempf, "Service Templates and
service: Schemes", RFC2609, June 1999.
[14] Howes, T., "The String Representation of LDAP Search Filters",
RFC2254, December 1997.
[15] Wahl, M., Howes, T. and S. Kille, "Lightweight Directory
Access Protocol (v3)", RFC2251, December 1997.
[16] Howes, T. and M. Smith, "The LDAP URL Format", RFC2255,
December 1997.
[17] Meyer, D., "Administratively Scoped IP Multicast", RFC2365,
July 1998.
[18] Narten, T. and H. Alvestrand, "Guidelines for Writing
an IANA Considerations Section in RFCs, BCP 26, RFC2434,
October 1998.
[19] Microsoft Networks. SMB File Sharing Protocol Extensions 3.0,
Document Version 1.09, November 1989.
[20] National Institute of Standards and Technology. Digital
signature standard. Technical Report NIST FIPS PUB 186, U.S.
Department of Commerce, May 1994.
[21] Perkins, C. and E. Guttman, "DHCP Options for Service Location
Protocol", RFC2610, June 1999.
[22] Veizades, J., Guttman, E., Perkins, C. and S. Kaplan, "Service
Location Protocol", RFC2165, July 1997.
[23] Yergeau, F., "UTF-8, a transformation format of ISO 10646",
RFC2279, January 1998.
G. Authors' Addresses
Erik Guttman
Sun Microsystems
Bahnstr. 2
74915 Waibstadt
Germany
Phone: +49 7263 911 701
EMail: Erik.Guttman@sun.com
Charles Perkins
Sun Microsystems
901 San Antonio Road
Palo Alto, CA 94040
USA
Phone: +1 650 786 6464
EMail: cperkins@sun.com
John Veizades
@Home Network
425 Broadway
Redwood City, CA 94043
USA
Phone: +1 650 569 5243
EMail: veizades@home.net
Michael Day
Vinca Corporation.
1201 North 800 East
Orem, Utah 84097 USA
Phone: +1 801 376-5083
EMail: mday@vinca.com
H. Full Copyright Statement
Copyright (C) The Internet Society (1999). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."
Acknowledgement
Funding for the RFCEditor function is currently provided by the
Internet Society.